Guidelines and Limitations
This is a list of guidelines and limitations to keep in mind when configuring bridge domains:
- Currently on bridge domain ports in auto mode the QoS default behavior is as follows:
- Incoming 802.1Q frames’ CoS value (a.k.a. PCP) is preserved along with the VLAN tag when transported in the VXLAN payload
- Incoming 802.1ad frames’ CoS value from the inner tag is preserved along with the inner VLAN tag when transported in the VXLAN payload
- For outgoing 802.1Q frames after VXLAN decapsulation CoS is set to value 0
- For outgoing 802.1ad frames after VXLAN decapsulation the CoS value carried in the VXLAN packet is preserved and becomes the CoS value of the inner tag. The outer tag instead carries a CoS value of 0.
- Before NetVisor OS release 6.0.0 on the Dell S5232-ON and Dell S5248-ON switch models the QinQ and untagged modes were not supported, while the 802.1Q mode is allowed. Starting from release 6.0.0 support for QinQ and untagged mode was added (however, an untagged host can only communicate to another untagged host in a bridge domain).
- On ports added to a BD, the STP protocol and the IGMP snooping features are not supported.
- Routing on BDs is not supported.
- Before NetVisor OS release 6.1.0 vNETs were not supported with BDs.
- The LLDP and LACP protocols are supported on BD ports configured in QinQ mode. The trunking and vLAG functionalities are supported too.
- The optimized ARP and optimized ND features cannot coexist with BDs. They should be set to off in the system-setting-show output. If the user attempts to enable the feature, a conflict message is printed as below:
CLI (network-admin@switch) > system-settings-modify optimize-arps
system-settings-modify: Cannot turn on optimized ARP as bridge-domain Q-in-Q is configured
When optimized ARP/ND is already configured before a port is added to a BD, a similar conflict message is printed:
CLI (network-admin@switch) > bridge-domain-port-add name bd1000 port 18 outer-vlan 18 inner-vlan 100
bridge-domain-port-add: Cannot add port in Q-in-Q mode to bridge-domain as optimized ARP or ND configured
- The flowtrace function is not supported with VXLAN and BDs.
- The VLAN ID is not shown in the l2-table-show output when a L2 entry is associated to a cluster tunnel:
CLI (network-admin@leaf1) > l2-table-show bd bd1 format switch,mac,bd,vlan,vxlan,inrf,ports,tunnel
switch mac bd vlan vxlan intf ports tunnel
---------------- ----------------- --- ---- ------ ---- ----- ---------------------------------
leaf1 00:12:c0:80:1c:09 bd1 100 101001 274 82
ursa-scale-leaf2 00:12:c0:80:1c:09 bd1 100 101001 274 82
ursa-scale-leaf1 00:12:c0:80:40:52 bd1 101001 auto-tunnel-10.40.40.1_10.30.40.1
ursa-scale-leaf2 00:12:c0:80:40:52 bd1 101001 auto-tunnel-10.40.40.1_10.30.40.1
ursa-scale-leaf4 00:12:c0:80:40:52 bd1 100 101001 81 81
- When configuring vLE redundancy, if LACP is used for end-to-end connectivity checks (which is usually preferable), a vLE trunk can be set up only with multiple individual virtual pipes using separate VTEPs (e.g., 8 in case of a 4-way vLE trunk). When using static trunks, instead, it is also possible (but generally less desirable) to set up, say, a 4-way vLE trunk with 2 2-way trunks as endpoints (which equates to a 4 x 2-port trunk configuration on leaf switches and a 4-way trunk configuration on end devices).
- For vLE endpoints only use physical IP (PIP) addresses. Do not use VRRP virtual IP (VIP) addresses.
- With the allowed-tpid qinq (i.e., 802.1ad TPID) configuration on a BD port configured in 802.1Q mode, MAC address learning includes both outer and inner VLAN of a double-tagged 802.1ad frame. Instead, for a single-tagged 802.1Q frame MAC address learning is based on just one VLAN. Both types of MAC address entries can be seen with the l2-table-show command. The hardware associates a BD and a VNI to a packet based on the port type. For BD ports configured in 802.1Q mode, the hardware lookup does not use the inner VLAN, it uses only the outer VLAN. So for bridge domain-related troubleshooting, use the l2-table-show command to focus on the MAC address+VNI pairs, rather than looking at the outer and/or inner VLAN, as the hardware lookup for Layer 2 entries is based on MAC address and VNI value.