No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

Configuration Guide - Ethernet Switching

CloudEngine 8800, 7800, 6800, and 5800 V200R003C00

This document describes the configuration of Ethernet services, including configuring MAC address table, link aggregation, VLANs, MUX VLAN, Voice VLAN, VLAN mapping, QinQ, GVRP, VCMP, STP/RSTP/MSTP, VBST, SEP, RRPP, ERPS, 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).
Configuration Notes of M-LAG

Configuration Notes of M-LAG

Involved Network Elements

Other network elements are not required.

License Requirements

M-LAG is a basic function, and can be used without a license.

Version Requirements

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

Product

Minimum Version Required

CE8868EI

V200R005C10

CE8861EI

V200R005C10

CE8860EI

V100R006C00

CE8850-32CQ-EI

V200R002C50

CE8850-64CQ-EI

V200R005C00

CE7850EI

V100R005C10

CE7855EI

V200R001C00

CE6810EI

V100R005C10

CE6810LI

V100R005C10

CE6850EI

V100R005C10

CE6850HI/CE6850U-HI/CE6851HI

V100R005C10

CE6855HI

V200R001C00

CE6856HI

V200R002C50

CE6857EI

V200R005C10

CE6860EI

V200R002C50

CE6865EI

V200R005C00

CE6870-24S6CQ-EI/CE6870-48S6CQ-EI

V200R001C00

CE6870-48T6CQ-EI

V200R002C50

CE6875EI

V200R003C00

CE6880EI

V200R005C00

CE5880EI

V200R005C10

CE5810EI

V100R005C10

CE5850EI

V100R005C10

CE5850HI

V100R005C10

CE5855EI

V100R005C10

Feature Dependencies and Limitations

Configuration Notes of M-LAG
  • During M-LAG setup, you must use optical modules or copper transceiver modules that are certified for Huawei Ethernet 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 optical or copper transceiver modules that are not certified for Huawei Ethernet 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 an SVF, the other end must be an SVF. If one end is a CloudEngine 8800, 7800, 6800, and 5800 series switches, the other end must be a CloudEngine 8800, 7800, 6800, and 5800 series switches. It is recommended that devices at both ends use the same model and version.
  • 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.
  • 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.
  • 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.
    • (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.
  • 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, 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.
  • In V200R002C50 and later versions, a static MAC address can be configured for an M-LAG member interface. 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 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 CE6810LI, CE5880EI and CE6880EI 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.
  • 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.
  • 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.
  • 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 M-LAG scenarios, when the switch connects to the Network Attached Storage (NAS) device or a load balancer, the NAS device or load balancer (for example, F5 load balancer enabled with Auto Last Hop) does not send an ARP request message to learn the gateway's MAC address. Instead, the NAS device or load balancer analyzes data flows from the gateway and uses the source MAC address in data flows received first as the gateway's MAC address. In this case, the same MAC address needs to be configured on VLANIF interfaces of the two switches (switches excluding the CE6870EI and CE6875EI) that constitute an M-LAG; otherwise, the NAS device or load balancer may fail to forward traffic due to the unidirectional isolation mechanism between the peer-link and M-LAG member interface.
  • 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 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.
  • Only the CE6857EI, CE6865EI, CE8861EI, and CE8868EI devices can establish BFD sessions with the M-LAG member interfaces.
  • If a device establishes a BFD session with a connected device through the M-LAG member interface, and the two M-LAG member devices synchronize BFD protocol packets through peer-link interfaces, BFD protocol packets enter the interface queue with the priority of 6 for forwarding. If service packets enter the interface queue with the priority of 7 for forwarding and the interface uses the default PQ scheduling mode, the BFD session flaps because BFD protocol packets are discarded when the service packets arrive at the interface at the 100% output link rate within a period of time. If other protocol packets are forwarded through peer-link interfaces, the packets may also be discarded due to the scheduling priority problem.

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-6.
Table 4-6 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.

SVF

Switches can set up an SVF system, and the SVF system then can be used to establish an M-LAG as an independent device. In an SVF system, M-LAG member interfaces must be on spine or leaf switches. The interfaces cannot be on both spine and leaf switches.

VBST

M-LAG and VBST cannot be configured together.

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.

IP unicast routing

The two devices that constitute an M-LAG could not set up routing neighbor relationships with the devices to be accessed.

IPv4 multicast

In versions earlier than V100R006C00, M-LAG does not support IPv4 Layer 3 multicast.

In V100R006C00 and later versions, an M-LAG set up with standalone switches, stack systems, or SVF systems supports IPv4 Layer 3 multicast. 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.
  • 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 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.

In V200R003C00 and later versions, for CE6870EI and CE6875EI, an M-LAG set up with standalone switches or stack systems supports IPv6 Layer 3 multicast, and other models do not support IPv6 Layer 3 multicast. 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.

In V200R003C00 and later versions, if the Receiver is dual-homed to an M-LAG:

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 or FSB and NPV coexist on the device.

IPSG

The two devices that constitute an M-LAG cannot be configured with IPSG.

VPLS

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.

  • In V200R003C00, you cannot configure segment VXLAN for Layer 2 DCI on a switch configured with M-LAG or as one of the all-active gateways. In V200R005C00 and later versions, you cannot configure segment VXLAN for Layer 2 DCI on a switch configured with M-LAG, and can configure the function on a switch configured as one of the all-active gateways. In this case, a VXLAN tunnel can be established using only BGP EVPN. In addition, Layer 2 local access traffic on the switch configured with segment VXLAN for Layer 2 DCI can be forwarded only in the data center.

  • On the CE6880EI and CE5880EI, IPv6 VXLAN and M-LAG cannot be configured together.
  • 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.

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.

Translation
Download
Updated: 2019-05-08

Document ID: EDOC1100004351

Views: 118874

Downloads: 292

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Share
Previous Next