Licensing Requirements and Limitations for M-LAG

CloudEngine 12800 and 12800E V200R019C10 Configuration Guide - Ethernet Switching

This document describes the configuration of Ethernet services, including configuring MAC address table, link aggregation, M-LAG, VLAN, QinQ, VLAN mapping, GVRP, STP/RSTP, MSTP, VBST, ERPS (G.8032), LBDT, and Layer 2 protocol transparent transmission.

Rate and give feedback:

Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).

Licensing Requirements and Limitations for M-LAG

Involved Network Elements

Other network elements are not required.

License Requirements

M-LAG is a basic function of the switch, and as such is controlled by the license for basic software functions. The license for basic software functions has been loaded and activated before delivery. You do not need to manually activate it.

Version Requirements

Table 4-6 Products and minimum version supporting M-LAG

Product	Minimum Version Required
CE12804/CE12804S/CE12808/CE12808S/CE12812/CE12816	V100R005C00
CE12804E/CE12808E/CE12816E	V200R005C00

For details about the mapping between software versions and switch models, see the Hardware Query Tool.

Software version evolution: V100R001C00 -> V100R002C00 -> V100R003C00 -> V100R003C10 -> V100R005C00 -> V100R005C10 -> V100R006C00 -> V200R001C00 -> V200R002C50 -> V200R003C00 -> V200R005C00 -> V200R005C10 -> V200R019C00 -> V200R019C10

Feature Dependencies and Limitations

Limitations on M-LAG Establishment

During M-LAG setup, you must use optical modules or copper transceiver modules that are certified for Huawei data center switches. If high-speed cables or active optical cables (AOCs) are used, you must purchase cables from Huawei. Optical or copper transceiver modules that are not certified for Huawei Ethernet switches, and cables not purchased from Huawei cannot ensure transmission reliability and may affect service stability. Huawei is not liable for any problem caused by the use of optical or copper modules that are not certified for Huawei data center switches, or cables not purchased from Huawei, and will not fix such problems.
The two devices that constitute an M-LAG must use the same model. If one end is a CloudEngine 12800 and 12800E series switches, the other end must be a CloudEngine 12800 and 12800E series switches. It is recommended that devices at both ends use the same model and version.

Limitations on Configuring the Root Bridge and V-STP

The two devices that constitute an M-LAG need to be configured with the root bridge and bridge ID or V-STP. They are virtualized into one device for STP calculation to prevent loops.
When the root bridge mode is used to configure M-LAG, the two devices that constitute an M-LAG must use the same bridge ID and the highest root priority so that the devices function as the root nodes.
When the switch used as the root bridge is configured with M-LAG, the switch does not support STP multi-process. When the switch is configured with both V-STP and M-LAG, the switch does not support the MSTP mode or STP multi-process in versions earlier than V200R002C50; the switch does not support the MSTP mode but supports the STP multi-process in V200R002C50 and later versions.
In V-STP scenarios, configure M-LAG and connect cables according to the following sequence:
1. Configure V-STP.
2. Configure a DFS group and peer-link interfaces.
3. Use a cable to connect peer-link interfaces of M-LAG master and backup devices.
4. Configure M-LAG member interfaces and use cables to connect M-LAG master and backup devices and the user-side host or switching device.

Limitations on Configuring M-LAG Consistency Check

To ensure that traffic is forwarded normally, the configurations of M-LAG interfaces with the same M-LAG ID on the master and backup devices must be consistent.
If the M-LAG consistency check mode is set to strict mode and the system detects that type 1 configurations of the two M-LAG devices are inconsistent, contact the device administrator to immediately adjust the configurations and not restart the devices. If type 1 configurations are inconsistent, member interfaces on the M-LAG backup device enter the Error-Down state and the alarm about type 1 configuration inconsistency is generated.

If the administrator does not adjust the configurations and restarts the M-LAG master device, interfaces on the M-LAG backup device may enter the Error-Down state because of type 1 configuration inconsistency during re-negotiation between M-LAG devices when the master device is recovering. In this case, M-LAG member interfaces on the M-LAG master device go Up after a delay. As a result, both the M-LAG master and backup devices fail to forward traffic, and services are interrupted.

If M-LAG configuration consistency check is disabled and type 1 and type 2 configurations of M-LAG master and backup devices are inconsistent, traffic forwarding may be abnormal. You are advised to manually adjust configurations of M-LAG master and backup devices to ensure that they have consistent type 1 and type 2 configurations, and enable M-LAG configuration consistency check.
If the system software of M-LAG member switches is upgraded from a version earlier than V200R003C00 to V200R019C10 or a later version, the M-LAG configuration consistency check fails during the upgrade. If the system software of M-LAG member switches is upgraded from a version between V200R003C00 and V200R005C10 to V200R019C10 or a later version, the M-LAG configuration consistency check is not supported during the upgrade. After the upgrade is complete, the M-LAG configuration consistency check is performed.

Limitations on Configuring Dual-Active Gateways

When the two devices that constitute an M-LAG function as gateways and servers are single-homed or dual-homed to the two devices, pay attention to the following points:
- When servers connect to the two devices through VRRP or VRRP6, the two devices must be configured with the same VLAN, and VLANIF interfaces must be created. Do not configure strict ARP learning on the VLANIF interfaces; otherwise, ARP entries cannot be synchronized. VBDIF interfaces do not support the preceding VRRP or VRRP6 configuration. M-LAG dual-homing access supports only the VRRP/VRRP6 dual-active mode.
- (Recommended) Select the access mode in which the same IP and MAC addresses are configured for VLANIF and VBDIF interfaces. This mode is supported in V100R006C00 and later versions. In V200R002C50 and earlier versions, if the same IP and MAC addresses are configured on two VLANIF or VBDIF interfaces, the IP and MAC address conflict alarm hwEthernetARPMACIPConflict is generated. It is normal that this alarm is generated in this scenario. You can ignore this alarm. To mask this alarm, run the undo snmp-agent trap enable feature-name arp trap-name hwethernetarpmacipconflict command to disable the alarm function for this conflict. After the alarm function for this conflict is disabled, you cannot detect loops on the network through alarms, and user services may be interrupted. Exercise caution when performing this operation. In V200R003C00SPC810 and later versions, if the same IP and MAC addresses are configured on two VLANIF and VBDIF interfaces, the conflict alarm is not generated.
- In a data center, if M-LAG dual-active gateways need to be deployed, you are advised to deploy them by configuring IP addresses and virtual MAC addresses of VLANIF/VBDIF interfaces, not by configuring VRRP.
In V200R002C50 and earlier versions, when devices are dual-homed to gateways through M-LAG, the M-LAG master and backup devices are configured with many Layer 2 sub-interfaces, and optical interfaces on the M-LAG master and backup devices are connected to copper transceiver modules, restarting the M-LAG master or backup device may cause packet loss for a long time. In this case, you are advised to manually switch traffic to the other M-LAG device and upgrade and restart the original M-LAG device.
In an M-LAG single-homing scenario where enhanced M-LAG Layer 3 forwarding is enabled, if VLANIF or VBDIF interfaces on both M-LAG member devices are configured with different IP addresses, no virtual MAC address can be configured for the VLANIF or VBDIF interfaces.

Limitations on Configuring DAD

When configuring an independent dual-active detection link, you are advised to use main interfaces to establish the dual-active detection link. If a VLANIF interface is used, ensure that the peer-link interface does not allow packets from the VLAN to pass through. Otherwise, a loop or MAC address flapping occurs.

Limitations on Configuring the Peer-Link

When member interfaces of a peer-link are deployed on the same card, a fault of the card causes a peer-link fault. To improve reliability, it is recommended that member interfaces of the peer-link be deployed on different cards.

Limitations in Fault Scenarios

When M-LAG faults occur, the convergence performance of Layer 3 traffic is in direct proportion to the ARP entries learned on the switch and interface. If there are many ARP entries, the convergence performance is low.
To prevent STP flapping caused by device restart and peer-link faults and ensure switching performance, you are advised to set the delay in reporting the Up event to be at least 30s on the M-LAG interface, peer-link interface, and other service interfaces. By default, the delay for an M-LAG interface to report the Up state is 120s in V200R005C00 and earlier versions, and 240s in V200R005C10 and later versions.
After a switch restarts or a card resets, the physical status of an interface changes to Up, but the upper-layer protocol modules do not meet forwarding requirements, resulting in packet loss. To ensure switching performance, by default, the delay for an M-LAG interface to report the Up state is 120s in V200R005C00 and earlier versions, and 240s in V200R005C10 and later versions. If a delay after which the Layer 3 protocol status changes to Up is configured on a VLANIF interface, ensure that the delay for an M-LAG member interface to report the Up event is longer than the delay configured on the VLANIF interface. Otherwise, triggering of learning for ND entries that fail to be synchronized depends on ND Miss messages.
A static MAC address can be configured for an M-LAG member interface in V200R002C50 and later versions. When the M-LAG member interface fails, the MAC address of the faulty M-LAG member interface is changed to that of a peer-link interface in corresponding entries.
In V200R005C10 and earlier versions, if a static ARP entry with a specified M-LAG member interface as the outbound interface is configured in an M-LAG dual-homing scenario, the outbound interface of the ARP entry cannot be changed to a peer-link interface when the M-LAG member interface fails. As a result, traffic cannot be forwarded. Therefore, do not configure a static ARP entry with a specified M-LAG member interface as the outbound interface in an M-LAG dual-homing scenario. In V200R019C00 and later versions, you can enable enhanced M-LAG Layer 3 forwarding on switches to apply for backup FRR resources for dynamic and static ARP entries with M-LAG member interfaces as outbound interfaces. The outbound interfaces can be changed to peer-link interfaces to establish active and standby paths for traffic forwarding. However, FRR resources applied for static ARP entries are not released when the M-LAG member interface goes Down and the corresponding VLANIF interface is still Up. As a result, the FRR resource consumption increases.
In V200R005C00 and earlier versions, if a static IPv6 neighbor entry with a specified M-LAG member interface as the outbound interface is configured in an M-LAG dual-homing scenario, the outbound interface of the entry cannot be changed to a peer-link interface when the M-LAG member interface fails. As a result, traffic cannot be forwarded. Therefore, do not configure a static IPv6 neighbor entry with a specified M-LAG member interface as the outbound interface in an M-LAG dual-homing scenario. In V200R005C10, you can enable enhanced M-LAG Layer 3 forwarding on switches except the CE12800E equipped with the ED-E, EG-E, and EGA-E series cards to apply for backup FRR resources for all ND entries with M-LAG member interfaces as outbound interfaces. The outbound interfaces can be changed to peer-link interfaces to establish active and standby paths for traffic forwarding. However, FRR resources applied for static IPv6 peer relationship entries are not released when the M-LAG member interface goes Down and the corresponding VLANIF interface is still Up. As a result, the corresponding system resources are not released. In V200R019C00 and later versions, you can enable enhanced M-LAG Layer 3 forwarding on the CE12800E equipped with the ED-E, EG-E, and EGA-E series cards.
If an access device is dual-homed to M-LAG master and backup devices through Layer 2 sub-interfaces and one Layer 2 sub-interface is Down, north-south traffic cannot be forwarded through the peer-link because of the M-LAG unidirectional isolation mechanism, resulting in packet loss. In the M-LAG unidirectional isolation mechanism, if a device is dual-homed to the M-LAG in active-active mode through main interfaces, all packets excluding Layer 3 known unicast packets from a peer-link interface to an M-LAG member interface are isolated.
After logical interfaces are configured to change to Error-Down state when the peer-link fails but the DAD heartbeat status is normal in an M-LAG, if a faulty peer-link interface in the M-LAG recovers, the devices restore VLANIF interfaces, VBDIF interfaces, and loopback interfaces to Up state 6 seconds after DFS group pairing succeeds to ensure that ARP entry synchronization on a large number of VLANIF interfaces is normal. If a delay after which the Layer 3 protocol status of the interface changes to Up is configured, the delay after which VLANIF interfaces, VBDIF interfaces, and loopback interfaces go Up is the configured delay plus 6s.

Configuration Notes When M-LAG Is Deployed with Other Services

When M-LAG needs to be configured with multiple other services, some services may fail to be delivered because of insufficient ACL resources. For services that can be configured together with M-LAG, see "Using CSS/M-LAG with Other Services" in CloudEngine Series Switches ACL Technical Special Topic.

The support for service features by M-LAG and the device is similar, but there are differences which are described in Table 4-7.

Table 4-7 Constraints when M-LAG is used with other features

Feature	Configuration Note
Stack	Switches can set up a stack, and the stack then can be used to establish an M-LAG as an independent device.
VS	Among all VSs in port mode, M-LAG can only be configured in the admin-VS. M-LAG can be configured in any VS in group mode. If M-LAG is configured in a VS and the VS is reset or the shutdown VS is started, the delay before an M-LAG member interface can go Up configured using the m-lag up-delay command does not take effect for M-LAG member interfaces in the VS. You can run the set vs port up-delay command to set the delay before interfaces in the VS can go Up to prevent traffic loss. You are advised to set the delay to a value greater than 45s.
VBST	M-LAG and VBST cannot be configured together.
QinQ and VLAN Mapping	M-LAG cannot be configured together with VLAN Mapping or VLAN Stacking.
CFM	M-LAG and CFM cannot be configured together.
GVRP	GVRP and M-LAG cannot be configured on an Eth-Trunk together.
DHCP	The two devices that constitute an M-LAG cannot be configured with DHCP snooping. The DHCP relay function must be configured on the two devices that constitute an M-LAG. The DHCP server function must be configured on the two devices that constitute an M-LAG, and addresses in the address pools of the two devices cannot overlap.
ARP	On the CE12800E equipped with FD-X series cards, the large-arp mode or UFT hybrid mode where ARP entries are specified is mutually exclusive with the m-lag forward layer-3 ipv4 enhance enable command.
IP unicast routing	The two devices that constitute an M-LAG cannot set up routing neighbor relationships with the devices to be accessed. If two member devices in an M-LAG need to establish a neighbor relationship, you are advised to manually configure router IDs on the two M-LAG devices. If the devices automatically obtain router IDs, the neighbor relationship may fail to be established due to a router ID conflict.
IPv4 multicast	In versions earlier than V100R006C00, an M-LAG set up with standalone switches or stack systems does not support IPv4 Layer 3 multicast. An M-LAG set up with standalone switches, stack systems supports IPv4 Layer 3 multicast in V100R006C00 and later versions. Pay attention to the following points: In addition to the peer-link, there must be a direct Layer 3 link between the M-LAG master and backup devices. STP must be disabled on the interfaces at both ends of the Layer 3 link. The M-LAG master and backup devices must have the same multicast configuration. On the M-LAG master and backup devices, PIM-SM and IGMP must be enabled on all the VLANIF interfaces that need to run Layer 3 multicast services, and IGMP snooping must be enabled in the corresponding VLANs. The PIM silent function must be configured on the user-side interfaces of the M-LAG master and backup devices. If the Layer 3 link is established on a VLANIF interface of the M-LAG master and backup devices, the VLANIF interface must run the PIM protocol, and the corresponding VLAN cannot be allowed on the peer-link. If the peer-link is selected as the optimal link to the RP or multicast source by the unicast routing protocol, multicast traffic with the peer-link interface as the outbound interface may fail to be forwarded. To prevent this problem, ensure that the Layer 3 link between the M-LAG master and backup devices has a route cost less than or equal to the route cost of the peer-link, so that the Layer 3 link is selected as the optimal route by the unicast routing protocol. On the network when the Receiver is dual-homed to an M-LAG: In versions earlier than V200R003C00, only the master M-LAG member interface forwards multicast traffic to the Receiver. Both the master and backup M-LAG member interfaces forward multicast traffic to the Receiver, implementing load sharing in V200R003C00 and later versions. The M-LAG master and backup devices share load according to the following rule: If the last decimal number of the multicast group address is an odd number, such as the address 225.1.1.1, the master M-LAG member interface forwards the multicast traffic. If the last decimal number of the multicast group address is an even number, such as the address 225.1.1.2, the backup M-LAG member interface forwards the multicast traffic. If the M-LAG master and backup devices run different versions, the multicast traffic forwarding rule is subject to the device running the earlier version.
IPv6 multicast	In versions earlier than V200R003C00, M-LAG does not support IPv6 Layer 3 multicast. An M-LAG set up with standalone switches or stack systems supports IPv6 Layer 3 multicastin V200R003C00 and later versions. Pay attention to the following points: In addition to the peer-link, there must be a direct Layer 3 link between the M-LAG master and backup devices. STP must be disabled on the interfaces at both ends of the Layer 3 link. The M-LAG master and backup devices must have the same multicast configuration. On the M-LAG master and backup devices, PIM-SM (IPv6) and MLD must be enabled on all the VLANIF interfaces that need to run Layer 3 multicast services, and MLD snooping must be enabled in the corresponding VLANs. The PIM silent (IPv6) function must be configured on the user-side interfaces of the M-LAG master and backup devices. If the Layer 3 link is established on a VLANIF interface of the M-LAG master and backup devices, the VLANIF interface must run the PIM (IPv6) protocol, and the corresponding VLAN cannot be allowed on the peer-link. If the peer-link is selected as the optimal link to the RP or multicast source by the unicast routing protocol, multicast traffic with the peer-link interface as the outbound interface may fail to be forwarded. To prevent this problem, ensure that the Layer 3 link between the M-LAG master and backup devices has a route cost less than or equal to the route cost of the peer-link, so that the Layer 3 link is selected as the optimal route by the unicast routing protocol. If the Receiver is dual-homed to an M-LAG in V200R003C00 and later versions: Both the master and backup M-LAG member interfaces forward multicast traffic to the Receiver, implementing load sharing. The M-LAG master and backup devices share load according to the following rule: If the last hexadecimal number of the multicast group address is an odd number, such as the addresses FF1E::1 and FF1E::B, the master M-LAG member interface forwards the multicast traffic. If the last hexadecimal number of the multicast group address is an even number, such as the addresses FF1E::2 and FF1E::A, the backup M-LAG member interface forwards the multicast traffic.
FCoE	The M-LAG function is not available if FSB and FCF coexist on the device.
IPSG	The two devices that constitute an M-LAG cannot be configured with IPSG.
VPLS/VLL	The two devices that constitute an M-LAG cannot be configured as PE devices.
VXLAN	In versions earlier than V200R003C00, Layer 2 sub-interfaces that use the QinQ traffic encapsulation type cannot be configured with M-LAG together. In V200R003C00 and later versions, M-LAG can be configured with termination QinQ Layer 2 sub-interfaces and cannot be configured with transparent transmission QinQ Layer 2 sub-interfaces. A switch configured with M-LAG does not support segment VXLAN for Layer 2 DCI. For CE12800 switches, if a VXLAN tunnel is established over an IPv6 network and an M-LAG is connected to the VXLAN network, configure peer-link interfaces on the CE-L48XS-FG, CE-L36CQ-FG, CE-L36CQ-FD1, CE-L36CQ-SD, CE-L48XS-FD1, CE-L08CF-FG1, or CE-L16CQ-FD card. On a CE12800E configured with ED-E, EG-E, or EGA-E series cards, the function of configuring a VXLAN tunnel over an IPv6 underlay network and the M-LAG function are mutually exclusive and cannot be deployed on the same switch. When VXLAN dual-active access is configured and the gateways work in loopback mode in a distributed gateway scenario, the NVE interfaces of different M-LAG systems on the network must be configured with different MAC addresses. For example, if devices A and B establish M-LAG system 1 and devices C and D establish M-LAG system 2, the NVE interfaces of M-LAG systems 1 and 2 must be configured with different MAC addresses. If active-active gateways are configured on VBDIF interfaces when a switch is connected to a VXLAN network, the VRRP or VRRP6 mode cannot be used. Currently, M-LAG member devices synchronize packets through UDP. The default UDP port number is 1025, which is different from the UDP port number configured for the all-active gateway neighbor in the DFS group view. If the two UDP port numbers conflict, you can run the source ip ip-address [ vpn-instance vpn-instance-name ] [ peer peer-ip-address [ udp-port port-number ] ] or source ipv6 ipv6-address [ vpn-instance vpn-instance-name ] [ peer peer-ipv6-address [ udp-port port-number ] ] command to change the UDP port number bound to the DFS group, or run the udp port port-number command to change the UDP port number configured for the all-active gateway neighbor.
Storm control	You are not advised to configure storm control for multicast packets on physical member interfaces of a peer-link. Otherwise, M-LAG synchronization packets may be suppressed, resulting in abnormal forwarding of data packets in the M-LAG system.
Port security	After port security is configured on a port, dynamic MAC addresses learned by the port are changed to secure dynamic MAC addresses or sticky MAC addresses. Secure dynamic MAC addresses and sticky MAC addresses are static MAC addresses and cannot be synchronized through peer-link interfaces on the two M-LAG member devices. When port security is configured on the M-LAG interfaces through which a device is dual-homed, the secure dynamic MAC addresses or sticky MAC addresses on the two M-LAG member devices may be different.
Ping and tracert	When an M-LAG member device pings or tracerts an access device, the ping or tracert fails. In V200R019C10 and later versions, an M-LAG member device can ping an access device, but a tracert may still fail.

Translation

简体中文

Download

Updated: 2021-04-01

Document ID: EDOC1100138135

Downloads: 159

Average rating:

This Document Applies to these Products

Enterprise

Huawei Cloud

Carrier

Consumer

Corporate

This document describes the configuration of Ethernet services, including configuring MAC address table, link aggregation, M-LAG, VLAN, QinQ, VLAN mapping, GVRP, STP/RSTP, MSTP, VBST, ERPS (G.8032), LBDT, and Layer 2 protocol transparent transmission.

Involved Network Elements

License Requirements

Version Requirements

Feature Dependencies and Limitations

Related Version

Related Documents