The Intelligent Resilient Framework (IRF) technology is developed by H3C to virtualize multiple physical devices at the same layer into one virtual fabric to provide data center class availability and scalability. IRF virtualization technology offers processing power, interaction, unified management, and uninterrupted maintenance of multiple devices.

Multichassis Link Aggregation (M-LAG) virtualizes two physical devices into one system through multi-chassis link aggregation for device redundancy and traffic load sharing.

Table 1 shows the differences between IRF and M-LAG. For high availability and short service interruption during software upgrade, use M-LAG. You cannot use IRF and M-LAG in conjunction on the same device.

Table 1 Comparison between IRF and M-LAG

Item	IRF	M-LAG
Control plane	· The IRF member devices have a unified control plane for central management. · The IRF member devices synchronize all forwarding entries.	· The control plane of the M-LAG member devices is separate. · The M-LAG member devices synchronize entries such as MAC, ARP, and ND entries.
Device requirements	· Hardware: The chips of the IRF member devices must have the same architecture, and typically the IRF member devices are from the same series. · Software: The IRF member devices must run the same software version.	· Hardware: The M-LAG member devices can be different models. · Software: Some device models can run different software versions when they act as M-LAG member devices. Full support for different software versions will be implemented in the future.
Software upgrade	· The IRF member devices are upgraded simultaneously or separately. A separate upgrade is complex. · Services are interrupted for about 2 seconds during an upgrade.	The M-LAG member devices are upgrade separately, and the service interruption time is shorter than 1 second during an upgrade. If the software supports graceful insertion and removal (GIR), an upgrade does not interrupt services. For more information about upgrading the M-LAG member devices by using GIR, see H3C Switches M-LAG System Upgrade & Replacement & Expansion Guide.
Management	The IRF member devices are configured and managed in a unified manner. Single points of failure might occur when a controller manages the IRF member devices.	The M-LAG member devices are configured separately, and they can perform configuration consistency check for you to remove inconsistencies in the configuration that affects operation of the M-LAG system. You must ensure that service features also have consistent configuration. The M-LAG member devices are managed separately. No single point of failure will occur when a controller manages the M-LAG member devices.

Item

IRF

M-LAG

Control plane

· The IRF member devices have a unified control plane for central management.

· The IRF member devices synchronize all forwarding entries.

· The control plane of the M-LAG member devices is separate.

· The M-LAG member devices synchronize entries such as MAC, ARP, and ND entries.

Device requirements

· Hardware: The chips of the IRF member devices must have the same architecture, and typically the IRF member devices are from the same series.

· Software: The IRF member devices must run the same software version.

· Hardware: The M-LAG member devices can be different models.

· Software: Some device models can run different software versions when they act as M-LAG member devices. Full support for different software versions will be implemented in the future.

Software upgrade

· The IRF member devices are upgraded simultaneously or separately. A separate upgrade is complex.

· Services are interrupted for about 2 seconds during an upgrade.

The M-LAG member devices are upgrade separately, and the service interruption time is shorter than 1 second during an upgrade.

If the software supports graceful insertion and removal (GIR), an upgrade does not interrupt services. For more information about upgrading the M-LAG member devices by using GIR, see H3C Switches M-LAG System Upgrade & Replacement & Expansion Guide.

Management

The IRF member devices are configured and managed in a unified manner.

Single points of failure might occur when a controller manages the IRF member devices.

The M-LAG member devices are configured separately, and they can perform configuration consistency check for you to remove inconsistencies in the configuration that affects operation of the M-LAG system. You must ensure that service features also have consistent configuration.

The M-LAG member devices are managed separately. No single point of failure will occur when a controller manages the M-LAG member devices.

NOTE:

GIR enables you to gracefully isolate a device from the network for device maintenance or upgrade. GIR minimizes service interruption by instructing the affected protocols (for example, routing protocols) to isolate the device and switch over to the redundant path. You do not need to configure graceful switchover protocol by protocol. For more information about GIR, see Fundamentals Configuration Guide for the devices.

Overlay network planning

H3C offers the following overlay network models for M-LAG:

· Three-tiered overlay—The overlay network is formed by the leaf, spine, and border tiers, as shown in Figure 1. Use this model if the border devices do not have enough downlink interfaces to connect to all leaf devices. The spine devices act as route reflectors (RR) in the network.

· Two-tiered overlay—The overlay network is formed by the leaf and spine tiers, and the spine devices are also border devices, as shown in Figure 2.

Figure 1 Three-tiered overlay network model

Figure 2 Two-tiered overlay network model

The overlay network contains the following device roles:

· Border device—A border gateway with M-LAG configured. The border devices are attached to firewalls and load balancers by using M-LAG interfaces. The border devices use Layer 3 Ethernet interfaces to connect to the spine or leaf devices, and traffic is load shared among the Layer 3 Ethernet links based on ECMP routes.

On a border device, you can use a Layer 3 Ethernet interface, VLAN interface, or M-LAG interface to establish Layer 3 connections with a PE or core device. As a best practice, use Layer 3 Ethernet interfaces.

· Edge device (ED)—A device providing Layer 2 and Layer 3 connectivity to another data center by using VXLAN. You can deploy independent EDs, configure EDs to be collocated with border devices, or configure a device to act as an ED, border, and spine device.

· Spine device—An RR does not have M-LAG configuration and reflects BGP routes between the border and leaf tiers in the three-tiered network model. An RR performs only underlay forwarding, and ECMP routes are used for traffic load sharing among the spine, border, and leaf tiers.

In a small network, spine devices can be collocated with border devices.

· Leaf device—An M-LAG-configured gateway for the servers. If the server NICs operate in bond4 mode for load sharing, a leaf device is connected to the servers by using M-LAG interfaces. If the server NICs operate in bond1 mode for link backup, a leaf device is connected to the servers by using physical interfaces assigned to the same VLAN as the servers. As a best practice to reduce active/standby NIC switchovers upon link flapping, disable active link preemption or set a preemption delay.

For high availability, make sure the servers are dualhomed to the leaf devices.

A leaf device is connected to upstream devices by using Layer 3 Ethernet interfaces, and ECMP routes are configured for high availability and load sharing.

· Firewall (FW)—An internal firewall attached to the M-LAG interfaces on the border devices by using two aggregate interfaces, one for the uplink and one for the downlink. Static routes are configured to enable Layer 3 communication between the firewall and border devices.

· Load balancer (LB)—A load balancer attached to the M-LAG interfaces on the border devices by using an aggregate interface. Static routes are configured to enable Layer 3 communication between the load balancer and border devices.

Underlay network planning

H3C offers the following underlay network models:

· M-LAG at the spine and leaf tiers—If the network is large, set up M-LAG systems at the spine and leaf tiers, and configure the spine devices as gateways for the servers. For configuration examples, see Multi-tier M-LAG+Spine Gateways+ECMP Paths to External Network Configuration Example.

· M-LAG at the leaf tier—If the network is small, set up M-LAG systems at the leaf tier, and configure the leaf devices as gateways for the servers. Configure ECMP routes between the leaf and spine tiers.

Figure 3 M-LAG at the spine and leaf tiers

Figure 4 M-LAG at the leaf tier

Restrictions and guidelines for M-LAG system setup

Peer link

In addition to protocol packets, the peer link also transmits data packets between the M-LAG member devices when an uplink fails.

If an M-LAG member device is a modular device, assign at least one port on each slot to the aggregation group for the peer-link interface as a best practice. This configuration prevents asynchronous service module reboots from causing peer link flapping after a device reboot. As a best practice, make sure at least one member port resides on a different slot than the uplink interfaces.

If an M-LAG member device is a fixed-port device with interface expansion modules, assign ports from multiple interface expansion modules to the aggregation group for the peer-link interface. As a best practice, make sure at least one member port resides on a different interface expansion module than the uplink interfaces.

If an M-LAG member device is a fixed-port device, assign at least two physical interfaces to the aggregation group for the peer-link interface.

Make sure the member ports in the aggregation group for the peer-link interface have the same speed.

If a leaf-tier M-LAG system is attached to a large number of servers whose NICs operate in active/standby mode, take the size of the traffic sent among those servers into account when you determine the bandwidth of the peer link.

As a best practice to reduce the impact of interface flapping on upper-layer services, use the link-delay command to configure the same link delay settings on the peer-link interfaces. Do not set the link delay to 0.

To prevent data synchronization failure, you must set the same maximum jumbo frame length on the peer-link interfaces of the M-LAG member devices by using the jumboframe enable command.

Keepalive link

The M-LAG member devices exchange keepalive packets over the keepalive link to detect multi-active collisions when the peer link is down.

As a best practice, establish a dedicated direct link between two M-LAG member devices as a keepalive link. Do not use the keepalive link for any other purposes. Make sure the M-LAG member devices have Layer 2 and Layer 3 connectivity to each other over the keepalive link.

You can use management Ethernet interfaces, Layer 3 Ethernet interfaces, Layer 3 aggregate interfaces, or interfaces with a VPN instance bound to set up the keepalive link. As a best practice, do not use VLAN interfaces for keepalive link setup. If you have to use VLAN interfaces, remove the peer-link interfaces from the related VLANs to avoid loops.

If a device has multiple management Ethernet interfaces, you can select one from them to set up a dedicated keepalive link independent of the management network.

On a modular device or fixed-port device with interface expansion modules, do not use the same module to provide interfaces for setting up the keepalive link and peer link.

For correct keepalive detection, you must exclude the physical and logical interfaces used for keepalive detection from the shutdown action by M-LAG MAD.

M-LAG interface

M-LAG interfaces in the same M-LAG group must use the different LACP system MAC addresses.

As a best practice, use the undo lacp period command to enable the long LACP timeout timer (90 seconds) on an M-LAG system.

You must execute the lacp edge-port command on the M-LAG interfaces attached to bare metal servers.

M-LAG MAD

Follow these restrictions and guidelines when you exclude interfaces from the shutdown action by M-LAG MAD on the underlay network:

· By default, M-LAG MAD shuts down network interfaces after an M-LAG system splits.

· You must exclude the VLAN interfaces of the VLANs to which the M-LAG interfaces and peer-link interfaces belong.

· For correct keepalive detection, you must exclude the interfaces used for keepalive detection.

· Do not exclude the uplink Layer 3 interfaces, VLAN interfaces, or physical interfaces.

When you use EVPN in conjunction with M-LAG, follow these restrictions and guidelines:

· Set the default M-LAG MAD action to NONE by using the m-lag mad default-action none command.

· Do not configure the M-LAG MAD action on the VLAN interfaces of the VLANs to which the M-LAG interfaces and peer-link interfaces belong. These interfaces will not be shut down by M-LAG MAD. Use the m-lag mad include interface command to include the non-M-LAG interfaces attached to single-homed servers in the shutdown action by M-LAG MAD. These interfaces will be shut down by M-LAG MAD when the M-LAG system splits.

· Do not configure the M-LAG MAD action on aggregation member ports. These interfaces will be shut down by M-LAG MAD after an M-LAG system splits.

· If you use an Ethernet aggregate link as a peer link, add the uplink Layer 3 interfaces, VLAN interfaces, and physical interfaces to the list of included interfaces by using the m-lag mad include interface command. These interfaces will be shut down by M-LAG MAD. This restriction does not apply to a VXLAN tunnel peer link.

· Do not configure the M-LAG MAD action on the interfaces used by EVPN, including the VSI interfaces, interfaces that provide BGP peer addresses, and interfaces used for setting up the keepalive link. These interfaces will not be shut down by M-LAG MAD.

· Do not configure the M-LAG MAD action on the interface that provides the IP address specified by using the evpn m-lag group command. These interfaces will not be shut down by M-LAG MAD.

When you configure M-LAG MAD, use either of the following methods:

· To shut down all network interfaces on the secondary M-LAG member device except a few special-purpose interfaces that must be retained in up state:

¡ Set the default M-LAG MAD action to M-LAG MAD DOWN by using the m-lag mad default-action down command.

¡ Exclude interfaces from being shut down by M-LAG MAD by using the m-lag mad exclude interface command.

In some scenarios, you must retain a large number of logical interfaces (for example, VSI interfaces, VLAN interfaces, aggregate interfaces, tunnel interfaces, and loopback interfaces) in up state. To simplify configuration, you can exclude all logical interfaces from the shutdown action by M-LAG MAD by using the m-lag mad exclude logical-interfaces command.

· To have the secondary M-LAG member device retain a large number of interfaces in up state and shut down the remaining interfaces:

¡ Set the default M-LAG MAD action to NONE by using the m-lag mad default-action none command.

¡ Specify network interfaces that must be shut down by M-LAG MAD by using the m-lag mad include interface command.

If you configure inter-VPN static routes without a next hop in ADDC 6.2 or a later solution, you must perform the following tasks for the static routes to take effect:

1. Create a service loopback group, and then assign an interface to it.

2. Access the M-LAG system editing page and exclude that interface from the shutdown action by M-LAG MAD.

MAC address assignment for the S12500X-AF switches

When you configure MAC addresses on the S12500X-AF switches, configure the base MAC address by using the routing-interface base-mac command before you assign MAC addresses.

Table 2 MAC address assignment for the S12500X-AF switches

Device	Bridge MAC address	Base MAC address	M-LAG system MAC address	EVPN global MAC address	MAC address of the VSI interface assigned an L3VNI	MAC address of a gateway VLAN interface	MAC address of a VSI interface
M-LAG member device 1	542b-de0c-0a00	Lower bridge MAC address + 64: 542b-de0c-0264	Lower base MAC address: 542b-de0c-0200	Lower base MAC address + 1: 542b-de0c-0201	EVPN global MAC address: 542b-de0c-0201	Default: base MAC address + 1, which is 542b-de0c-0265 Recommended: Lower base MAC address + c8, which is 542b-de0c-02c8	Default: base MAC address + 1, which is 542b-de0c-0265 Recommended: EVPN global MAC address, which is 542b-de0c-0201
M-LAG member device 2	542b-de0c-0200	Lower bridge MAC address: 542b-de0c-0200	Lower base MAC address: 542b-de0c-0200	Lower base MAC address + 1: 542b-de0c-0201	EVPN global MAC address: 542b-de0c-0201	Default: base MAC address + 1, which is 542b-de0c-0201 Recommended: Lower base MAC address + c8, which is 542b-de0c-02c8	Default: base MAC address + 1, which is 542b-de0c-0201 Recommended: EVPN global MAC address, which is 542b-de0c-0201

Device

Bridge MAC address

Base MAC address

M-LAG system MAC address

EVPN global MAC address

MAC address of the VSI interface assigned an L3VNI

MAC address of a gateway VLAN interface

MAC address of a VSI interface

M-LAG member device 1

542b-de0c-0a00

Lower bridge MAC address + 64: 542b-de0c-0264

Lower base MAC address: 542b-de0c-0200

Lower base MAC address + 1: 542b-de0c-0201

EVPN global MAC address: 542b-de0c-0201

Default: base MAC address + 1, which is 542b-de0c-0265

Recommended: Lower base MAC address + c8, which is 542b-de0c-02c8

Default: base MAC address + 1, which is 542b-de0c-0265

Recommended: EVPN global MAC address, which is 542b-de0c-0201

M-LAG member device 2

542b-de0c-0200

Lower bridge MAC address: 542b-de0c-0200

Lower base MAC address: 542b-de0c-0200

Lower base MAC address + 1: 542b-de0c-0201

EVPN global MAC address: 542b-de0c-0201

Default: base MAC address + 1, which is 542b-de0c-0201

Recommended: Lower base MAC address + c8, which is 542b-de0c-02c8

Default: base MAC address + 1, which is 542b-de0c-0201

Recommended: EVPN global MAC address, which is 542b-de0c-0201

To view the bridge MAC address, execute the debug sysm bridgemac read command in probe view and examine the BridgeMac field.

[Sysname-probe]debug sysm bridgemac read

The Bridge Macs are as follows:

542b-de0c-0200

Total reserved mac number: 256

SNID:23a6-db6c-d829-a93d

BridgeMac:542b-de0c-0200 BaseInfMac:542b-de0c-0200 INTFMac:542b-de0c-0201

Make sure the higher 36 bits in the MAC addresses assigned to VSI interfaces are the same as those in the base MAC address. As a best practice, configure VSI interfaces to use the EVPN global MAC address.

For more information about base MAC addresses, see Layer 2—LAN Switching Configuration Guide for the S12500X-AF switches.

Restrictions and guidelines

M-LAG compatibility with third-party devices

You cannot use M-LAG interfaces for communicating with third-party devices.

M-LAG system configuration

You can assign two member devices to an M-LAG system. For the M-LAG member devices to be identified as one M-LAG system, you must configure the same M-LAG system MAC address and M-LAG system priority on them. You must assign different M-LAG system numbers to the M-LAG member devices.

Make sure each M-LAG system uses a unique M-LAG system MAC address.

To ensure correct forwarding, delete M-LAG configuration from an M-LAG member device if it leaves its M-LAG system.

When you bulk shut down physical interfaces on an M-LAG member device for service changes or hardware replacement, shut down the physical interfaces used for keepalive detection prior to the physical member ports of the peer-link interface. If you fail to do so, link flapping will occur on the member ports of M-LAG interfaces.

Do not execute the m-lag drcp period short command to enable the short DRCP timeout timer when the M-LAG process is restarting or before you perform an ISSU. If you do so, traffic forwarding will be interrupted during the M-LAG process restart or ISSU.

M-LAG standalone mode

The M-LAG member devices might both operate with the primary role to forward traffic if they have M-LAG interfaces in up state after the M-LAG system splits. M-LAG standalone mode helps avoid traffic forwarding issues in this multi-active situation by allowing only the member ports in the M-LAG interfaces on one member device to forward traffic.

The following information describes the operating mechanism of this feature.

The M-LAG member devices change to M-LAG standalone mode when they detect that both the peer link and the keepalive link are down. In addition, the secondary M-LAG member device changes its role to primary.

In M-LAG standalone mode, the LACPDUs sent out of an M-LAG interface by each M-LAG member device contain the interface-specific LACP system MAC address and LACP system priority.

The Selected state of the member ports in the M-LAG interfaces in an M-LAG group depends on their LACP system MAC address and LACP system priority. If an M-LAG interface has a lower LACP system priority value or LACP system MAC address, the member ports in that M-LAG interface become Selected to forward traffic. If those Selected ports fail, the member ports in the M-LAG interface on the other M-LAG member device become Selected to forward traffic.

To configure the M-LAG system priority, use the m-lag system-priority command in system view. To configure the LACP system priority, use one of the following methods:

· Execute the lacp system-mac and lacp system-priority commands in system view.

· Execute the port lacp system-mac and port lacp system-priority commands in M-LAG interface view.

The M-LAG interface-specific configuration takes precedence over the global configuration.

When you configure the M-LAG system priority and LACP system priority, follow these guidelines:

· For a single tier of M-LAG system at the leaf layer, set the M-LAG system priority value to be larger than the LACP system priority value for M-LAG interfaces. The smaller the value, the higher the priority. For an M-LAG group, configure different LACP system priority values for the member M-LAG interfaces.

· For two tiers of M-LAG systems at the spine and leaf layers, configure the M-LAG system priority settings of spine devices to be the same as the LACP system priority settings of leaf devices. This ensures traffic is forwarded along the correct path when an M-LAG system splits.

Peer-link interface configuration

To ensure correct Layer 3 forwarding over the peer link, you must execute the undo mac-address static source-check enable command to disable static source check on the Layer 2 aggregate interface assigned the peer-link interface role. This restriction does not apply to the S12500X-AF, S12500G-AF, or S6890 switches.

M-LAG data restoration interval

The data restoration interval set by using the m-lag restore-delay command specifies the maximum amount of time for the secondary M-LAG member device to synchronize forwarding entries with the primary M-LAG member device during M-LAG system setup. Adjust the data restoration interval based on the size of forwarding tables. If the M-LAG member devices have small forwarding tables, reduce this interval. If the forwarding tables are large, increase this interval. Typically, set the data restoration interval to 300 seconds. If the ARP table of an S12500X-AF or S12500G-AF switch contains about 48K entries, set this interval to 900 seconds.

IRF

M-LAG is not supported by an IRF member device, even when the device is the only member in an IRF fabric. Before you configure M-LAG on a device, verify that it is operating in standalone mode.

MDC

You cannot use M-LAG on MDCs.

GIR

Before you change an M-LAG member device back to normal mode, execute the display m-lag mad verbose command to verify that no network interfaces are in M-LAG MAD DOWN state.

MAC address table

If the M-LAG system has a large number of MAC address entries, set the MAC aging timer to a higher value than 20 minutes as a best practice. To set the MAC aging timer, use the mac-address timer aging command.

The MAC address learning feature is not configurable on the peer-link interface. Do not execute the mac-address mac-learning enable or undo mac-address mac-learning enable command on the peer-link interface.

ARP

If an M-LAG interface provides Layer 3 services, a VLAN interface is configured for the VLAN that contains the M-LAG interface for example, do not configure the following features on the M-LAG interface:

· ARP active acknowledgement, configurable with the arp active-ack enable command.

· Dynamic ARP learning limit, configurable with the arp max-learning-number command.

This restriction ensures that the M-LAG member devices can learn consistent ARP entries.

Link aggregation

Do not configure automatic link aggregation on an M-LAG system.

The aggregate interfaces in an S-MLAG group cannot be used as M-LAG interfaces or peer-link interfaces.

You cannot configure link aggregation management subnets on an M-LAG system.

When you configure an M-LAG interface, follow these restrictions and guidelines:

· The link-aggregation selected-port maximum and link-aggregation selected-port minimum commands do not take effect on an M-LAG interface.

· If you execute the display link-aggregation verbose command for an M-LAG interface, the displayed system ID contains the M-LAG system MAC address and the M-LAG system priority.

· If the reference port is a member port of an M-LAG interface, the display link-aggregation verbose command displays the reference port on both M-LAG member devices.

Port isolation

Do not assign M-LAG interfaces and peer-link interfaces to the same port isolation group.

CFD

Do not use the MAC address of a remote MEP for CFD tests on peer-link interfaces. These tests cannot work on peer-link interfaces.

Smart Link

The M-LAG member devices in an M-LAG system must have the same Smart Link configuration.

For Smart Link to operate correctly on an M-LAG interface, do not assign the M-LAG interface and non-M-LAG interfaces to the same smart link group.

Do not assign a peer-link interface to a smart link group.

You can use Smart Link on an M-LAG system formed by the following device models:

· S6805.

· S6825.

· S6850.

· S9850.

· S9820-64H.

· S9820-8C.

· S12500G-AF.

Mirroring

If you use port mirroring together with M-LAG, do not assign the source port, destination port, egress port, and reflector port for a mirroring group to two aggregation groups. If the source port is in a different aggregation group than the other ports, mirrored LACPDUs will be transmitted between aggregation groups and cause aggregate interface flapping.

MAC address synchronization

Two M-LAG member devices synchronize underlay MAC address entries over the peer link and overlay MAC address entries through BGP EVPN.

Only the MAC address entries learned by hardware age out. Synchronized MAC address entries do not age out. If a hardware-learned MAC address entry ages out on one M-LAG member device, the device requests the other M-LAG member device to delete that MAC address entry.

M-LAG network models

Layer 2 M-LAG network models

Loop prevention on an M-LAG system

For an M-LAG system on an underlay network, configure spanning tree to remove loops. For an M-LAG system on an overlay network, configure VSI-based loop detection to remove loops.

M-LAG and spanning tree

Network model

You can use M-LAG in conjunction with spanning tree to remove loops, as shown in Figure 5 and Table 3.

Figure 5 Network diagram

Table 3 Deployment schemes

Scenario	Solution	Commands
Due to an M-LAG system split, misconnection, or misconfiguration, traffic is sent between two member ports of the same aggregation group over the peer link, which creates a loop.	Enable spanning tree on the M-LAG member devices.	stp global enable (system view)
	Assign the spine-facing interfaces on leaf devices to different VLANs if the leaf and spine devices are interconnected by using VLAN interfaces in an EVPN M-LAG network. In addition, disable spanning tree on physical interfaces to remove loops and prevent the upstream device from falsely blocking interfaces.	undo stp enable (Layer 2 Ethernet interface view)
A new device added to the network preempts the root bridge role, and network flapping occurs as a result.	Configure the M-LAG member devices in the upstream M-LAG system as root bridges and enable root guard on them.	stp root primary (system view) stp root-protection (M-LAG interface view)
The M-LAG member devices are attacked by using TC-BPDUs and flush MAC address entries frequently, which causes network flapping, high CPU usage, and transient floods.	Enable the TC-BPDU guard feature on the M-LAG member devices.	stp tc-protection (system view)
On an M-LAG member device, an interface cannot recognize BPDUs after its physical state changes.	Configure an interface as an edge port if its peer port does not support or run spanning tree protocols.	stp edged-port (M-LAG interface view)
Network flapping occurs after an M-LAG member device receives forged BPDUs on interfaces whose counterparts do not send BPDUs.	Enable BPDU guard on the M-LAG member device. When interfaces with BPDU guard enabled receive configuration BPDUs, the device performs the following operations: · Shuts down these interfaces. · Notifies the NMS that these interfaces have been shut down by the spanning tree protocol. The device reactivates the interfaces that have been shut down when the port status detection timer expires.	stp bpdu-protection (system view)

Restrictions and guidelines

Make sure the M-LAG member devices in an M-LAG system have the same spanning tree configuration. Violation of this rule might cause network flapping. The configuration includes:

· Global spanning tree configuration.

· Spanning tree configuration on the peer-link interface.

· Spanning tree configuration on M-LAG interfaces.

Peer-link interfaces of the M-LAG system do not participate in spanning tree calculation.

The M-LAG member devices still use the M-LAG system MAC address after the M-LAG system splits, which will cause spanning tree calculation issues. To avoid the issues, enable M-LAG standalone mode on the M-LAG member devices before the M-LAG system splits.

Spanning tree configurations made in system view take effect globally. Spanning tree configurations made in Layer 2 Ethernet interface view take effect only on the interface. Spanning tree configurations made in Layer 2 aggregate interface view take effect only on the aggregate interface. Spanning tree configurations made on an aggregation member port can take effect only after the port is removed from its aggregation group.

After you enable a spanning tree protocol on a Layer 2 aggregate interface, the system performs spanning tree calculation on the Layer 2 aggregate interface. It does not perform spanning tree calculation on the aggregation member ports. The spanning tree protocol state and forwarding state of each selected member port are consistent with those of the corresponding Layer 2 aggregate interface. The member ports of an aggregation group do not participate in spanning tree calculation. However, the ports still reserve their spanning tree configurations for participating in spanning tree calculation after leaving the aggregation group.

M-LAG and VSI-based loop detection

Mechanisms

As shown in Figure 6, if an endpoint is dualhomed to the M-LAG system, you must enable loop detection on both VTEPs in the M-LAG system. Loop detection works as follows on the VTEPs:

1. The VTEPs send loop detection frames out of the ACs configured on the M-LAG interfaces facing the endpoint. The loop detection frames contain the same source MAC address, VLAN tag, loop detection interval, and loop detection priority. The source MAC address is the M-LAG system MAC address.

2. When receiving loop detection frames on a local M-LAG interface, a VTEP sends the loop detection frames to the peer VTEP over the peer link. This synchronization mechanism ensures that a VTEP can receive loop detection frames in case of link or interface failure.

3. If a VTEP receives a self-sent loop detection frame from an AC, the VTEP compares the loop detection priority of the AC with that in the frame and acts as follows:

¡ If the loop detection priority in the frame is higher, the VTEP performs the loop protection action on all ACs configured for the M-LAG group that accommodates the looped M-LAG interface.

¡ If the loop detection priority of the AC is higher, the system only records the loop information.

If an endpoint is singlehomed to one VTEP in the M-LAG system, enable loop detection only on that VTEP. Loop detection works as follows on the VTEP:

4. The VTEP sends loop detection frames out of the ACs configured on the M-LAG interface facing the endpoint. The source MAC address is the M-LAG system MAC address.

5. If the VTEP receives a self-sent loop detection frame from an AC, the VTEP compares the loop detection priority of the AC with that in the frame and acts as follows:

¡ If the loop detection priority in the frame is higher, the VTEP performs the loop protection action on the looped AC.

¡ If the loop detection priority of the AC is higher, the system only records the loop information.

Figure 6 Loop detection in a VXLAN network with M-LAG configured

Compatibility of data center switches with VSI-based loop detection

Hardware	Software	Reference
S12500X-AF, S6890	Not supported	N/A
S12500G-AF	R7625 and later	See VXLAN loop detection in Layer 2—LAN Switching Configuration Guide in H3C S12500G-AF Switch Series Configuration Guides-R7625Pxx.
S6805, S6825, S6850, S9850	R6710 and later	See VXLAN loop detection in Layer 2—LAN Switching Configuration Guide in H3C S6805 & S6825 & S6850 & S9850 Switch Series Configuration Guides-Release 671x.
S9820-64H, S9820-8C	Not supported	N/A
S6800, S6860	R6710 and later	See VXLAN loop detection in Layer 2—LAN Switching Configuration Guide in H3C S6800 & S6860 Switch Series Configuration Guides-Release 671x.
S6812, S6813	N/A	Under development. To obtain the latest images, contact Technical Support.

Restrictions and guidelines

If you enable loop detection in an EVPN VXLAN M-LAG dualhoming environment, configure the same loop detection parameters for the VTEPs in the M-LAG system.

Layer 3 M-LAG network models

Gateway deployment schemes

Table 4 shows the schemes to configure gateways on an M-LAG system for attached servers.

Table 4 Gateway deployment schemes for M-LAG

Gateway type	Description
VLAN interface (recommended)	· A VLAN interface is configured on each M-LAG member device, and both M-LAG member devices can respond to ARP packets and perform Layer 3 forwarding. · Attached servers require Layer 3 connectivity to the M-LAG system in some scenarios, containers are deployed on the servers for example. To fulfil this requirement, perform one of the following tasks: ¡ Configure static routes. ¡ Assign a virtual IPv4 or IPv6 address to each gateway VLAN interface by using the port m-lag virtual-ip or port m-lag ipv6 virtual-ip command.
VRRP group	· Both the VRRP master and backup devices perform Layer 3 forwarding, but only the master device responds to ARP packets. In a VRRP dual-active scenario, a gateway locally forwards a packet at Layer 3 if the packet is destined for the VRRP virtual MAC address, real MAC address of the local device, or real MAC address of the M-LAG peer. The M-LAG member devices synchronize the real MAC addresses of the gateways with each other. · The server-side devices can set up dynamic routing neighbor relationships with the M-LAG member devices.

Gateway type

Description

VLAN interface (recommended)

· A VLAN interface is configured on each M-LAG member device, and both M-LAG member devices can respond to ARP packets and perform Layer 3 forwarding.

· Attached servers require Layer 3 connectivity to the M-LAG system in some scenarios, containers are deployed on the servers for example. To fulfil this requirement, perform one of the following tasks:

¡ Configure static routes.

¡ Assign a virtual IPv4 or IPv6 address to each gateway VLAN interface by using the port m-lag virtual-ip or port m-lag ipv6 virtual-ip command.

VRRP group

· Both the VRRP master and backup devices perform Layer 3 forwarding, but only the master device responds to ARP packets.
In a VRRP dual-active scenario, a gateway locally forwards a packet at Layer 3 if the packet is destined for the VRRP virtual MAC address, real MAC address of the local device, or real MAC address of the M-LAG peer. The M-LAG member devices synchronize the real MAC addresses of the gateways with each other.

· The server-side devices can set up dynamic routing neighbor relationships with the M-LAG member devices.

For more information about support for dual-active VLAN interfaces, see the applicable product matrix in M-LAG+IPv4 and IPv6 Dual-Active VLAN Gateway Configuration Example.

Dual-active VLAN interfaces

About dual-active VLAN interfaces

Configure VLAN interfaces as gateways on both M-LAG member devices, as shown in Figure 7 and Table 5.

For more information about configuring dual-active VLAN interfaces, see M-LAG+IPv4 and IPv6 Dual-Active VLAN Gateway Configuration Example.

Figure 7 Network diagram

Table 5 Configuration tasks

Tasks	Forwarding
· VLAN interface configuration: a. Create a gateway VLAN interface on each M-LAG member device for the same VLAN. b. Assign the same IP address and MAC address to the gateway VLAN interfaces. c. Create a VLAN interface on each M-LAG member device for another VLAN, assign the peer-link interfaces to this VLAN, and assign a unique IP address from the same subnet to each of the VLAN interfaces. The M-LAG member devices use those VLAN interfaces to forward traffic between them when a link to the upstream device is failed. · Use Layer 3 interfaces to connect the M-LAG member devices to the upstream device, and configure ECMP routes for load sharing across the uplinks. · Configure static routes for reaching the attached servers if the servers accommodate containers and the M-LAG virtual IP address feature is not supported.	· For Layer 2 traffic sent by the servers, the M-LAG member devices look up the MAC address table and forward the traffic locally. · For Layer 3 traffic sent by the servers, the M-LAG member devices perform Layer 3 forwarding based on the FIB table. · For external traffic destined for the servers, the M-LAG member devices perform forwarding based on the routing table.

Tasks

Forwarding

· VLAN interface configuration:

a. Create a gateway VLAN interface on each M-LAG member device for the same VLAN.

b. Assign the same IP address and MAC address to the gateway VLAN interfaces.

c. Create a VLAN interface on each M-LAG member device for another VLAN, assign the peer-link interfaces to this VLAN, and assign a unique IP address from the same subnet to each of the VLAN interfaces.
The M-LAG member devices use those VLAN interfaces to forward traffic between them when a link to the upstream device is failed.

· Use Layer 3 interfaces to connect the M-LAG member devices to the upstream device, and configure ECMP routes for load sharing across the uplinks.

· Configure static routes for reaching the attached servers if the servers accommodate containers and the M-LAG virtual IP address feature is not supported.

· For Layer 2 traffic sent by the servers, the M-LAG member devices look up the MAC address table and forward the traffic locally.

· For Layer 3 traffic sent by the servers, the M-LAG member devices perform Layer 3 forwarding based on the FIB table.

· For external traffic destined for the servers, the M-LAG member devices perform forwarding based on the routing table.

Network models for deploying dual-active VLAN interfaces on M-LAG systems at multiple layers with core devices as gateways

As shown in Figure 8, M-LAG systems are set up at three layers to avoid single points of failure:

· Device A and Device B form an M-LAG system at the access layer. Device C and Device D form an M-LAG system at the distribution layer. Device E and Device F form an M-LAG system at the core layer.

· The server is dualhomed to the access M-LAG system. The VM is dualhomed to the core M-LAG system via Device G.

· Dual-active VLAN interfaces are configured on the core M-LAG system to offer gateway and routing services.

· Spanning tree is configured on Device A through Device F, and Device E and Device F are configured as root bridges.

Figure 8 Three-layer model

As shown in Figure 9, M-LAG systems are set up at the access and distribution layers to avoid single points of failure.

M-LAG deployment does not differ greatly between a three-layer network and a two-layer network. For more configuration details, see Multi-Layer M-LAG+STP+Dual-Active VLAN Gateway Configuration Examples.

Figure 9 Two-layer model

Network models for deploying dual-active VLAN interfaces on M-LAG systems at multiple layers with distribution and core devices as gateways

As shown in Figure 10, M-LAG systems are set up at three layers to avoid single points of failure:

· Device A and Device B form an M-LAG system at the access layer. Device C and Device D form an M-LAG system at the distribution layer. Device E and Device F form an M-LAG system at the core layer.

· The server is dualhomed to the core M-LAG system via Device G. The VM is dualhomed to the access M-LAG system.

· Dual-active VLAN interfaces are configured on the core M-LAG system to offer gateway and routing services to the server. Dual-active VLAN interfaces are configured on the distribution M-LAG system to offer gateway and routing services to the VM. OSPF provides Layer 3 connectivity between the distribution and core layers.

· M-LAG virtual IP addresses are configured on Device C through Device F for them to set up OSPF neighbor relationships.

For more configuration details, see Multi-Layer M-LAG+Dual-Active VLAN Gateway+OSPF Configuration Examples.

Figure 10 Network diagram

Device	Interface	IP address
Device C Device D	Vlan-int10	IPv4: 10.1.1.1/24 IPv6: 10:1::1/64
Device C Device D	Vlan-int20	IPv4: 20.1.1.1/24 Device C's M-LAG virtual IPv4 address: 20.1.1.103/24 Device D's M-LAG virtual IPv4 address: 20.1.1.104/24 IPv6: 20:1::1/64 Device C's M-LAG virtual IPv6 address: FE80::6 Device D's M-LAG virtual IPv6 address: FE80::8
Device E Device F	Vlan-int20	IPv4: 20.1.1.2/24 Device E's M-LAG virtual IPv4 address: 20.1.1.101/24 Device F's M-LAG virtual IPv4 address: 20.1.1.102/24 IPv6: 20:1::2/64 Device E's M-LAG virtual IPv6 address: FE80::2 Device F's M-LAG virtual IPv6 address: FE80::4
Device E Device F	Vlan-int30	IPv4: 30.1.1.1/24 IPv6: 30:1::1/64

Restrictions and guidelines

To ensure correct ND entry synchronization, execute the ipv6 nd unsolicited-na-learning enable command on the IPv6 dual-active VLAN interfaces.

Routing neighbor relationship setup on dual-active VLAN interfaces using M-LAG virtual IP addresses

For the gateway VLAN interfaces to establish routing neighbor relationships with a server-side network device, perform the following tasks:

· Assign a virtual IPv4 or IPv6 address to each gateway VLAN interface by using the port m-lag virtual-ip or port m-lag ipv6 virtual-ip command.

· Configure routing protocols.

The gateway VLAN interfaces will use the virtual IP addresses to establish routing neighbor relationships.

Use this scheme if the servers accommodate containers.

Figure 11 Network diagram

Table 6 Configuration tasks

Scenario	Tasks	Forwarding
The servers attached to the M-LAG system accommodate containers, and a dynamic routing protocol runs between the M-LAG system and the servers.	· VLAN interface configuration: a. Create a gateway VLAN interface on each M-LAG member device for the same VLAN. b. Assign the same IP address and MAC address to the gateway VLAN interfaces. c. Assign a unique virtual IP address from the same subnet to each of the gateway VLAN interfaces. The gateway VLAN interfaces use the virtual IP addresses for BGP or OSPF neighbor relationship setup. d. Create a VLAN interface on each M-LAG member device for another VLAN, assign the peer-link interfaces to this VLAN, and assign a unique IP address from the same subnet to each of the VLAN interfaces. The M-LAG member devices use those VLAN interfaces to forward traffic between them when a link to the upstream device is failed. · Create a VLAN interface on each M-LAG member device for another VLAN, assign the peer-link interfaces to this VLAN, and assign a unique IP address from the same subnet to each of the VLAN interfaces. The M-LAG member devices use those VLAN interfaces to forward traffic between them when a link to the upstream device is failed. · Use Layer 3 interfaces to connect the M-LAG member devices to the upstream device, and configure ECMP routes for load sharing across the uplinks.	· For Layer 2 traffic sent by the servers, the M-LAG member devices look up the MAC address table and forward the traffic locally. · For Layer 3 traffic sent by the servers, the M-LAG member devices perform Layer 3 forwarding based on the FIB table. · For external traffic destined for the servers, the M-LAG member devices perform forwarding based on the routing table.
BFD is required.	Configure the M-LAG member devices to use the M-LAG virtual IP addresses to set up BFD sessions with the secondary IP address of the gateway VLAN interface on the server-side network device.	N/A

Scenario

Tasks

Forwarding

The servers attached to the M-LAG system accommodate containers, and a dynamic routing protocol runs between the M-LAG system and the servers.

· VLAN interface configuration:

a. Create a gateway VLAN interface on each M-LAG member device for the same VLAN.

b. Assign the same IP address and MAC address to the gateway VLAN interfaces.

c. Assign a unique virtual IP address from the same subnet to each of the gateway VLAN interfaces.
The gateway VLAN interfaces use the virtual IP addresses for BGP or OSPF neighbor relationship setup.

d. Create a VLAN interface on each M-LAG member device for another VLAN, assign the peer-link interfaces to this VLAN, and assign a unique IP address from the same subnet to each of the VLAN interfaces.
The M-LAG member devices use those VLAN interfaces to forward traffic between them when a link to the upstream device is failed.

· Create a VLAN interface on each M-LAG member device for another VLAN, assign the peer-link interfaces to this VLAN, and assign a unique IP address from the same subnet to each of the VLAN interfaces.
The M-LAG member devices use those VLAN interfaces to forward traffic between them when a link to the upstream device is failed.

· Use Layer 3 interfaces to connect the M-LAG member devices to the upstream device, and configure ECMP routes for load sharing across the uplinks.

· For Layer 2 traffic sent by the servers, the M-LAG member devices look up the MAC address table and forward the traffic locally.

· For Layer 3 traffic sent by the servers, the M-LAG member devices perform Layer 3 forwarding based on the FIB table.

· For external traffic destined for the servers, the M-LAG member devices perform forwarding based on the routing table.

BFD is required.

Configure the M-LAG member devices to use the M-LAG virtual IP addresses to set up BFD sessions with the secondary IP address of the gateway VLAN interface on the server-side network device.

N/A

For more configuration details, see M-LAG+IPv4 and IPv6 Dual-Active VLAN Gateway Configuration Example.

VRRP gateways

Network model

You can configure VRRP groups on an M-LAG system to provide gateway services for the attached servers, as shown in Figure 12 and Table 7.

For more configuration details, see M-LAG and VRRP Configuration Example.

Figure 12 Network diagram

Table 7 Configuration tasks

Tasks	Forwarding
· Configure a VRRP group on the M-LAG member devices and use the VRRP virtual IP address as the gateway for the attached servers. · VLAN interface configuration: a. Create a VLAN interface for the VLAN where the M-LAG interface resides on each M-LAG member device. b. Assign a unique primary IP address from one subnet to each of the VLAN interfaces. c. Assign a unique secondary IP address from another subnet to each of the VLAN interfaces. · Use the primary or secondary IP addresses of the VLAN interfaces to set up BGP or OSPF neighbor relationships with the server-side network device. Perform this task if the servers accommodate containers. · Set up a Layer 3 connection over the peer link between the M-LAG member devices. The M-LAG member devices use the Layer 3 connection to forward traffic between them when a link to the upstream device is failed. · Use Layer 3 interfaces to connect the M-LAG member devices to the upstream device, and configure ECMP routes for load sharing across the uplinks.	· For the Layer 3 traffic sent by the servers, both M-LAG member devices can perform forwarding. · For the external traffic destined for the servers, the M-LAG member devices make forwarding decisions based on local routes.

Tasks

Forwarding

· Configure a VRRP group on the M-LAG member devices and use the VRRP virtual IP address as the gateway for the attached servers.

· VLAN interface configuration:

a. Create a VLAN interface for the VLAN where the M-LAG interface resides on each M-LAG member device.

b. Assign a unique primary IP address from one subnet to each of the VLAN interfaces.

c. Assign a unique secondary IP address from another subnet to each of the VLAN interfaces.

· Use the primary or secondary IP addresses of the VLAN interfaces to set up BGP or OSPF neighbor relationships with the server-side network device. Perform this task if the servers accommodate containers.

· Set up a Layer 3 connection over the peer link between the M-LAG member devices.
The M-LAG member devices use the Layer 3 connection to forward traffic between them when a link to the upstream device is failed.

· Use Layer 3 interfaces to connect the M-LAG member devices to the upstream device, and configure ECMP routes for load sharing across the uplinks.

· For the Layer 3 traffic sent by the servers, both M-LAG member devices can perform forwarding.

· For the external traffic destined for the servers, the M-LAG member devices make forwarding decisions based on local routes.

Restrictions and guidelines

Both VRRP standard mode and load balancing mode are supported. VRRP standard mode also supports load sharing on an M-LAG system. Use VRRP standard mode as a best practice.

If you use M-LAG and VRRP together, make sure the keepalive hold timer is shorter than the interval at which the VRRP master sends VRRP advertisements. Violation of this restriction might cause a VRRP master/backup switchover to occur before peer link failure is acknowledged. To set the interval at which the VRRP master sends VRRP advertisements, use the vrrp vrid timer advertise command or the vrrp ipv6 vrid timer advertise command. To set the keepalive hold timer, use the m-lag keepalive hold-time command.

To avoid frequent master/backup switchovers, configure the routers in a VRRP group to operate in non-preemptive mode.

For the S12500X-AF H card series, a device supports 15 VRRP group IDs in VRRP standard mode and 7 VRRP group IDs in VRRP load balancing mode. As a best practice, configure the same VRRP group ID for multiple Layer 3 interfaces to save VRRP group IDs. If a device fails to issue a VRRP group to a VLAN interface because of VRRP group ID exhaustion, delete other VRRP groups, delete the VRRP group configuration to issue, and then reconfigure the VRRP group.

The S12500G-AF, S6805, S6825, S6850, S9850, S9820-64H, S9820-8C, S6800, and S6860 switches support a maximum of 256 VRRP groups, and each interface supports a maximum of 32 VRRP groups. As a best practice, configure the same VRRP group ID for multiple Layer 3 interfaces to save VRRP group IDs.

The S6812 and S6813 switches support a maximum of 255 VRRP groups, and each interface supports a maximum of 16 VRRP groups. As a best practice, configure the same VRRP group ID for multiple Layer 3 interfaces to save VRRP group IDs.

Restrictions and guidelines for single-homed servers attached to non-M-LAG interfaces

Dual-active VLAN interfaces

If all servers are single-homed to an M-LAG system or operate in active/standby (bond1) mode, perform the following tasks to ensure correct traffic forwarding:

1. Create an aggregate interface.

2. Assign the aggregate interface to all VLANs where the single-homed and active/standby servers reside.

3. Assign the aggregate interface to an M-LAG group.

If no M-LAG interfaces are assigned to the VLAN of a dual-active VLAN gateway interface, traffic might be interrupted in that VLAN.

To resolve this issue, perform the following tasks:

· For the S6800, S6860, S6805, S6825, S6850, S9850, S9820-64H, and S9820-8C switches, use the m-lag extra-vlan command in system view to configure the VLANs of dual-active VLAN gateways as extra VLANs.

· For the S12500X-AF, S6890, S6812, and S6813 switches, create an M-LAG interface and assign it to the VLANs of dual-active VLAN gateway interfaces. You do not need to assign physical interfaces to the aggregation group of the M-LAG interface.

· For the S12500G-AF switches, create an M-LAG interface and assign it to the VLANs of dual-active VLAN gateway interfaces. Assign up physical interfaces to the aggregation group of the M-LAG interface to prevent M-LAG MAD from falsely shutting down the not rebooted secondary device after the primary device reboots.

VRRP gateways

If the NICs of a server operate in active/standby (bond1) mode, perform the following tasks to ensure correct traffic forwarding:

1. Create an aggregate interface.

2. Assign the aggregate interface to the VLAN where the VRRP gateway resides.

3. Assign the aggregate interface to an M-LAG group.

If no M-LAG interfaces are assigned to the VLAN of a VLAN interface with a VRRP gateway configured, unexpected unknown unicast traffic might trigger unknown unicast suppression and cause traffic loss in that VLAN.

To resolve this issue, perform the following tasks:

· For the S6800, S6860, S6805, S6825, S6850, S9850, S9820-64H, and S9820-8C switches, use the m-lag extra-vlan command in system view to configure the VLANs of VLAN interfaces with a VRRP gateway configured as extra VLANs.

· For the S12500X-AF, S6890, S6812, and S6813 switches, create an M-LAG interface and assign it to the VLANs of VLAN interfaces with a VRRP gateway configured. You do not need to assign physical interfaces to the aggregation group of the M-LAG interface.

· For the S12500G-AF switches, create an M-LAG interface and assign it to the VLANs of VLAN interfaces with a VRRP gateway configured. Assign up physical interfaces to the aggregation group of the M-LAG interface to prevent M-LAG MAD from falsely shutting down the not rebooted secondary device after the primary device reboots.

Only a VRRP master can learn the ARP entries for single-homed servers. A VRRP backup can learn ARP entries for single-homed servers only when it needs to send ARP requests to the single-homed servers after receiving certain packets, and transient traffic loss might occur as a result.

Restrictions and guidelines for routing configuration

Router ID

You must manually assign unique router IDs to the M-LAG member devices in an M-LAG system. If you use EVPN and M-LAG together, perform the following tasks:

· On each M-LAG member device, use loopback 0 to provide the local VTEP address and router ID. You must assign different IP addresses to loopback 0 on the M-LAG member devices.

· On each M-LAG member device, use loopback 1 to provide the virtual VTEP address. You must assign the same IP address to loopback 1 on the M-LAG member devices.

To configure the virtual VTEP address, use the evpn m-lag group command.

NSR

You must enable NSR for the routing protocol used on M-LAG member devices that have two MPUs.

OSPF and OSPFv3

For fast network convergence, perform the following tasks on all devices with OSPF or OSPFv3 configured:

· Execute the ospf network-type p2p or ospfv3 network-type p2p command on the interfaces that have OSPF or OSPFv3 neighbors.

· Execute the spf-schedule-interval 1 10 10 and lsa-generation-interval 1 10 10 commands in OSPF or OSPFv3 view to speed up SPF calculation and LSA generation after link failure occurs.

· Accelerate network convergence after a device reboots:

¡ In OSPF view, execute the stub-router include-stub on-startup command. For a fixed-port device, set this timeout time to 300 seconds. For a modular device, set the timeout time to be longer than 300 seconds. If all slots of a modular device have modules installed, set the timeout time to 900 seconds or longer.

¡ In OSPFv3 view, execute the stub-router max-metric include-stub on-startup command. For a fixed-port device, set this timeout time to 300 seconds. For a modular device, set the timeout time to be longer than 300 seconds. If all slots of a modular device have modules installed, set the timeout time to 900 seconds or longer.

M-LAG and RDMA

Network model

As shown in Figure 13, you can set up M-LAG systems with leaf devices in an RDMA network for the servers to be dual-homed to the network. The redundant links between an M-LAG system and an attached server are aggregated for high availability and traffic load sharing.

Figure 13 Network diagram

Table 8 Configuration tasks

Tasks	Forwarding
· For server uplink redundancy and traffic load sharing, set up one M-LAG system with Leaf 1 and Leaf 2, and set up another M-LAG system with Leaf 3 and Leaf 4. · For gateway redundancy and traffic load sharing, configure dual-active VLAN gateways or VRRP groups on the M-LAG systems. · Configure the spine devices at the distribution layer as RRs to reflect BGP routes among the leaf devices. · Configure the lossless network as follows on the server-facing physical interfaces of the leaf devices and the physical interfaces interconnecting the leaf and spine devices: a. Enable PFC and set the PFC threshold for lossless queues to implement priority-based flow control. b. Configure PFC deadlock detection to prevent the devices from entering PFC deadlock state when forwarding paths are looped for packets with a specific priority. c. Configure QoS queue scheduling to prioritize traffic forwarding for lossless queues and CNP queues. d. Configure WRED to avoid congestion. Configure ECN for lossless queues and CNP queues for end-to-end congestion control. · Adjust the data buffer settings for lossless queues on the leaf devices, including the maximum Headroom buffer size and maximum outbound shared-area space. · For traffic to fail over through the peer link in case of uplink failure, configure Monitor Link on the M-LAG member devices in the same M-LAG system, or configure the devices to set up routing neighbor relationships with each other on VLAN interfaces.	· For Layer 2 traffic sent between the downstream servers attached to the same M-LAG system, the M-LAG member devices look up the MAC address table and forward the traffic locally. · For Layer 3 traffic sent by a server, the upstream M-LAG member devices perform Layer 3 forwarding over the ECMP links towards the spine devices. The spine devices will forward the traffic towards the destination server attached to another M-LAG system. · For external traffic destined for a server, the upstream M-LAG member devices perform forwarding based on the routing table. · Traffic traversing each M-LAG system is load shared across the uplinks and downlinks. · Traffic loss does not occur when the traffic sent between two servers attached to the same M-LAG system or different M-LAG systems is congested.

Tasks

Forwarding

· For server uplink redundancy and traffic load sharing, set up one M-LAG system with Leaf 1 and Leaf 2, and set up another M-LAG system with Leaf 3 and Leaf 4.

· For gateway redundancy and traffic load sharing, configure dual-active VLAN gateways or VRRP groups on the M-LAG systems.

· Configure the spine devices at the distribution layer as RRs to reflect BGP routes among the leaf devices.

· Configure the lossless network as follows on the server-facing physical interfaces of the leaf devices and the physical interfaces interconnecting the leaf and spine devices:

a. Enable PFC and set the PFC threshold for lossless queues to implement priority-based flow control.

b. Configure PFC deadlock detection to prevent the devices from entering PFC deadlock state when forwarding paths are looped for packets with a specific priority.

c. Configure QoS queue scheduling to prioritize traffic forwarding for lossless queues and CNP queues.

d. Configure WRED to avoid congestion. Configure ECN for lossless queues and CNP queues for end-to-end congestion control.

· Adjust the data buffer settings for lossless queues on the leaf devices, including the maximum Headroom buffer size and maximum outbound shared-area space.

· For traffic to fail over through the peer link in case of uplink failure, configure Monitor Link on the M-LAG member devices in the same M-LAG system, or configure the devices to set up routing neighbor relationships with each other on VLAN interfaces.

· For Layer 2 traffic sent between the downstream servers attached to the same M-LAG system, the M-LAG member devices look up the MAC address table and forward the traffic locally.

· For Layer 3 traffic sent by a server, the upstream M-LAG member devices perform Layer 3 forwarding over the ECMP links towards the spine devices. The spine devices will forward the traffic towards the destination server attached to another M-LAG system.

· For external traffic destined for a server, the upstream M-LAG member devices perform forwarding based on the routing table.

· Traffic traversing each M-LAG system is load shared across the uplinks and downlinks.

· Traffic loss does not occur when the traffic sent between two servers attached to the same M-LAG system or different M-LAG systems is congested.

For more configuration details, see M-LAG and RDMA Configuration Example.

Restrictions and guidelines

Configure the following features on the physical interfaces used as peer-link interfaces:

· Configure QoS queue scheduling to prioritize traffic forwarding for lossless queues and CNP queues.

· Configure WRED to avoid congestion.

M-LAG and EVPN

You can set up an M-LAG system with two leaf or border devices in an EVPN network to prevent single points of failure from interrupting servers. For more information about EVPN overlay network planning, see "Overlay network planning." This section uses a three-tiered network as an example.

You can deploy distributed or centralized gateways in the network. If you use distributed gateways, all leaf devices can act as VXLAN IP gateways to forward Layer 3 traffic locally. If you use a centralized gateway, it forwards all traffic sent between VXLANs and from the VXLANs to external networks. The traffic load on the centralized gateway is heavier than on a distributed gateway.

As a best practice, use an Ethernet aggregate interface as a peer link. Do not use a VXLAN tunnel as a peer link.

Distributed gateway deployment

Figure 14 Network diagram

Table 9 Configuration tasks

Tasks	Forwarding
· Configure the leaf devices as VTEPs or EVPN gateways to forward Layer 2 and Layer 3 traffic among the servers. · Set up M-LAG systems at the leaf tier and attach each server to two M-LAG member devices in the same M-LAG system. · Configure the spine devices (not M-LAG member devices) as RRs to reflect routes between the leaf and border tiers. · Configure the border devices as EDs to set up VXLAN-DCI tunnels to other data centers. · Set up an M-LAG system at the border tier for reliable access to external networks.	For the Layer 2 and Layer 3 traffic sent by the servers, the leaf devices forward it over VXLAN tunnels to the destination servers or towards the border devices. The border devices look up the routing table to forward the traffic destined for the external networks. The M-LAG member devices in an M-LAG system use the virtual VTEP IP address to set up VXLAN tunnels, and they use their real IP addresses to establish BGP peer relationships with the spine devices. For load sharing and high availability, traffic destined for the virtual VTEP IP address is distributed over the underlay network to both M-LAG member devices based on ECMP routes.

Tasks

Forwarding

· Configure the leaf devices as VTEPs or EVPN gateways to forward Layer 2 and Layer 3 traffic among the servers.

· Set up M-LAG systems at the leaf tier and attach each server to two M-LAG member devices in the same M-LAG system.

· Configure the spine devices (not M-LAG member devices) as RRs to reflect routes between the leaf and border tiers.

· Configure the border devices as EDs to set up VXLAN-DCI tunnels to other data centers.

· Set up an M-LAG system at the border tier for reliable access to external networks.

For the Layer 2 and Layer 3 traffic sent by the servers, the leaf devices forward it over VXLAN tunnels to the destination servers or towards the border devices. The border devices look up the routing table to forward the traffic destined for the external networks.

The M-LAG member devices in an M-LAG system use the virtual VTEP IP address to set up VXLAN tunnels, and they use their real IP addresses to establish BGP peer relationships with the spine devices. For load sharing and high availability, traffic destined for the virtual VTEP IP address is distributed over the underlay network to both M-LAG member devices based on ECMP routes.

For more configuration details, see M-LAG and EVPN Distributed Gateway Configuration Example.

Centralized gateway deployment

Figure 15 Network diagram

Table 10 Configuration tasks

Tasks

Forwarding

· Configure the leaf devices as VTEPs to forward Layer 2 traffic among the servers.

· Set up M-LAG systems at the leaf tier and attach each server to two M-LAG member devices in the same M-LAG system.

· Configure the spine devices (not M-LAG member devices) as RRs to reflect routes between the leaf and border tiers.

· Set up an M-LAG system at the border tier for reliable access to external networks.

· Configure centralized gateway interfaces on the M-LAG system.

· Configure the border devices as EDs to set up VXLAN-DCI tunnels to other data centers.

For the Layer 2 traffic sent by the servers, the leaf devices forward it over VXLAN tunnels to the destination servers. For the Layer 3 traffic sent by the servers, the leaf devices forward it towards the border devices. The border devices look up the routing table to forward the traffic destined for the external networks or another server at Layer 3.

For more configuration details, see M-LAG and EVPN Distributed Gateway (IS-IS for underlay routing) Configuration Example and M-LAG and EVPN Distributed Gateway (BGP for Underlay Routing) Configuration Example.

Failover between data centers

If the links to external network fail or the local border devices fail in a data center, traffic exchanged between internal and external networks can fail over to the border devices in a backup data center. M-LAG+EVPN DC Switchover Upon Border Failure Configuration Examples introduces configuration details for border devices that use M-LAG interfaces and Layer 3 Ethernet interfaces to connect external networks. Traffic fails over to a backup data center when one of the following events occurs on the border devices.

· All member ports of an M-LAG interface go down. In this scenario, only traffic on that M-LAG interface fails over to a backup data center.

· All spine-facing interfaces go down on both border devices.

· Both border devices fail.

NOTE:

Failure handling mechanisms for M-LAG interfaces, peer link, keepalive link, and transport-facing interfaces on a single border device and recovery of a single border device have been introduced in EVPN and M-LAG configuration examples.

Basic configuration restrictions and guidelines

Network setup

· In an M-LAG system, M-LAG member devices such as VTEPs or EVPN gateways must have the same EVPN configuration, including:

¡ ACs.

¡ VSI-to-VXLAN mappings.

¡ EVPN router MAC address. You can use one of the following methods to configure the EVPN router MAC address:

- Use the evpn global-mac command to configure the EVPN global MAC address.

- Use the mac-address command to assign a MAC address to a VSI interface with a L3VNI configured.

· Do not use VSI-interface 0 as a distributed EVPN gateway.

· For an M-LAG member device to re-establish VXLAN tunnels, you must execute the address-family l2vpn evpn command in BGP instance view after you enable or disable M-LAG.

· You cannot specify a secondary IP address of an interface as the virtual VTEP address.

· You must execute the undo mac-address static source-check enable command on the Layer 2 aggregate interfaces that act as peer-link interfaces and transport-facing physical interfaces. This restriction does not apply to S12500X-AF, S12500G-AF, or S6890 switches.

· Make sure the underlay network and the virtual VTEP address are the same IP version. IP version inconsistency will cause VXLAN tunnel setup failure.

· As a best practice, do not redistribute external routes on the M-LAG member devices.

ACs

If an Ethernet aggregate link is used as the peer link, follow these restrictions:

· If the frame match criteria of dynamic ACs on the peer link are created based on site-facing Ethernet service instances, you can configure only the following criteria for site-facing Ethernet service instances:

¡ encapsulation s-vid { vlan-id | vlan-id-list }

¡ encapsulation untagged

In addition, you must set the access mode to VLAN for the site-facing Ethernet service instances. Ethernet service instances with the same frame match criterion configured must be mapped to the same VSI.

· When the frame match criteria of dynamic ACs on the peer link are created based on VXLAN IDs, you must set the access mode to VLAN for the site-facing Ethernet service instances. To match double-tagged VLAN packets on an Ethernet service instance, you must configure the encapsulation s-vid vlan-id-list c-vid vlan-id-list criterion. If you use the encapsulation s-vid { vlan-id | vlan-id-list } criterion to match multi-tagged packets, packets forwarded over the peer link might carry incorrect VLAN tags.

Whether these restrictions apply to S12500G-AF, S6812, and S6813 switches is to be verified.

· If the traffic outgoing interface for a VXLAN tunnel is an M-LAG interface, do not assign the M-LAG interface to a VLAN matched by an Ethernet service instance on the peer link.

Peer link

· As a best practice, set the PVID to 4094 on the peer-link interfaces. If you fail to do so and also execute the l2vpn m-lag peer-link ac-match-rule vxlan-mapping command, an M-LAG member device might set the outer VLAN ID matched by an AC to the PVID of its peer-link interface. This issue will affect forwarding of the underlay traffic whose VLAN ID is VXLAN ID%4094 + 1.

· The M-LAG member devices synchronize with each other their MAC address, ARP, and ND entries learned on local AC interfaces over the peer link.

Miscellaneous

· Assign the spine-facing interfaces on leaf devices to different VLANs if the leaf and spine devices are interconnected by using VLAN interfaces in an EVPN M-LAG network. In addition, disable spanning tree on physical interfaces to remove loops and prevent the upstream device from falsely blocking interfaces.

· Configure backup routes for directing traffic from one M-LAG member device to the other M-LAG member device upon uplink failure.

· If the peer link or an AC forwards both overlay and underlay traffic, the peer-link interface or the site-facing interface that hosts the AC might reflect back received packets. To resolve this issue, assign the peer-link interface or site-facing interface to a port isolation group to disable it from reflecting packets back. If the interface is an aggregate interface, it will not reflect back the packets received by a member port. This restriction applies to the following switches:

¡ S6800-32Q (LS-6800-32Q-H1)

¡ S6800-54HF

¡ S6800-54HT

¡ S6800-2C (LS-6800-2C-H1)

¡ S6800-2C-FC

¡ S6800-4C (LS-6800-4C-H1)

¡ S6800-54QF (LS-6800-54QF-H3)

¡ S6800-54QF (LS-6800-54QF-H5)

¡ S6800-54QT (LS-6800-54QT-H3)

Restrictions and guidelines for peer link ACs

As a best practice, enable frame match criteria creation based on VXLAN IDs for the dynamic ACs on the peer link if you use the S12500G-AF, S6800, S6860, S6812, S6813, S6805, S6825, S6850, and S9850 switches. This feature is configurable with the l2vpn m-lag peer-link ac-match-rule vxlan-mapping command. Make sure the highest VXLAN ID is not larger than 16000000.

If you use the S12500X-AF or S6890 switches, use the l2vpn m-lag peer-link tunnel command to enable the switches to automatically set up a VXLAN tunnel with an M-LAG peer. After you execute this command, the M-LAG member devices no longer create dynamic ACs on the peer link. Instead, they set up a VXLAN tunnel and assign it to all VXLANs. The forwarding entries synchronized between the M-LAG member devices will be associated with the related VXLAN tunnel interfaces.

If neither frame match criteria creation based on VXLAN IDs (l2vpn m-lag peer-link ac-match-rule vxlan-mapping) nor automatic VXLAN tunnel setup (l2vpn m-lag peer-link tunnel) is enabled, and an Ethernet aggregate link is used as the peer link, the M-LAG member devices by default automatically create ACs on the peer link based on site-facing ACs. The peer link ACs and the site-facing ACs have the same frame match criteria. In this scenario, Ethernet service instances matching the same outer VLAN ID must be mapped to the same VSI.

MAC address configuration restrictions and guidelines

Distributed EVPN gateways use the following VSI interfaces to perform Layer 3 forwarding:

· VSI interfaces acting as distributed gateway interfaces. Their MAC addresses are used as gateway addresses in VXLANs.

· VSI interfaces with an L3VNI and a VPN instance associated. Their MAC addresses are encapsulated as the inner source MAC addresses in the Layer 3 packets sent between gateways. These MAC addresses are known as router MAC addresses.

Do not assign the same MAC address to VSI interfaces of different types.

MAC address configuration for L3VNI associated VSI interfaces

· You can use one of the following methods to assign MAC addresses to L3VNI associated VSI interfaces:

¡ Use the evpn global-mac command to configure an EVPN global MAC address for all L3VNI associated VSI interfaces on a device. This method is recommended.

¡ Use the mac-address command to assign MAC addresses on a per-VSI interface basis.

· A distributed EVPN gateway selects the lowest-numbered L3VNI associated VSI interface to provide the router MAC address. In an M-LAG system, distributed EVPN gateways that act as M-LAG member devices must use the same router MAC address. As a best practice, assign the same MAC address to the L3VNI associated VSI interfaces.

· Configure the same EVPN global MAC address on the M-LAG member devices in an M-LAG system. Make sure the EVPN global MAC address of an M-LAG system is unique in the local data center and the remote data centers connected to the local data center through DCI tunnels.

· As a best practice, use one of the following methods to configure the EVPN global MAC address on an M-LAG system formed by the S6805, S6825, S6850, S9850, S6800, S6860, or S12500G-AF switches:

¡ Use the default MAC address of a Layer 3 Ethernet interface on an M-LAG member device as the EVPN global MAC address. This method is recommended.

¡ Use an available unicast MAC address in the range of 0001-0001-0001 to 0001-0001-FFFE as the EVPN global MAC address.

For information about EVPN global MAC address configuration on S12500X-AF switches, see "MAC address assignment for the S12500X-AF switches." For information about EVPN global MAC address configuration on S6890 switches, contact H3C Support.

· If you use the mac-address command to modify the MAC address of a L3VNI associated VSI interface on an M-LAG system, also modify the MAC address of the other L3VNI associated VSI interfaces. These VSI interfaces must use the same MAC address.

· If a distributed EVPN gateway is connected to an IPv6 site, make sure the L3VNI associated VSI interfaces use the same link-local address.

MAC address configuration for distributed gateway interfaces

· On different distributed EVPN gateways, the VSI interface of a VXLAN must use the same IP address and MAC address to provide services.

· Do not assign reserved MAC addresses to VSI interfaces. For more information about reserved MAC addresses, see the configuration guides for the devices you use.

Leaf device configuration restrictions and guidelines

Execute the evpn m-lag local command. If single-homed ACs are attached to an M-LAG system, a VTEP uses the source IP address of the peer link as the next hop of routes for single-homed ACs to ensure correct traffic forwarding.

Execute the vxlan default-decapsulation command. If a VXLAN tunnel is configured on only one device in a pair of devices, the VXLAN tunnel is a unidirectional tunnel to the device not configured with the tunnel. For an M-LAG member device to receive VXLAN packets from a unidirectional VXLAN tunnel, enable default VXLAN decapsulation for the interface whose IP address is the tunnel destination address. The M-LAG member device will decapsulate all the VXLAN packets destined for the IP address of that interface. This feature takes effect only when the specified interface has an IP address.

Execute the l2vpn m-lag peer-link ac-match-rule vxlan-mapping command on the S12500G-AF, S6800, S6860, S6812, S6813, S6805, S6825, S6850, and S9850 switches.

Border and ED configuration restrictions and guidelines

Execute the nexthop evpn-m-lag group-address command. After you execute this command, an M-LAG member device changes the next hop in advertised EVPN routes to the M-LAG virtual IP address. The traffic destined for the M-LAG virtual IP address will be distributed to both M-LAG member devices based on the ECMP routes on the underlay network.

Do not execute the evpn m-lag local command on border devices, even when single-homed devices exist. If you do so, the nexthop evpn-m-lag group-address command does not take effect.

Restrictions and guidelines for server access in active/standby mode

For the S12500G-AF switches, if all servers are attached to an M-LAG system in bond1 mode and NIC preemption is enabled, create an M-LAG group for M-LAG MAD to take effect and for fast convergence after a device reboot or peer link down event. Assign up physical interfaces to the M-LAG aggregation group to prevent M-LAG MAD from falsely shutting down the not rebooted secondary device after the primary device reboots.

This restriction does not apply if all servers are attached to an M-LAG system in bond1 mode with NIC preemption disabled.

Routing neighbor relationship setup on an M-LAG system formed by distributed EVPN gateways

If you set up an M-LAG system with distributed EVPN gateways, you must assign the same IP and MAC addresses to the VSI interfaces that provide gateway services for the same subnet. For the M-LAG member devices to set up routing neighbor relationships with server-side network devices, assign unique M-LAG virtual IP addresses to the VSI interfaces by using the port m-lag virtual-ip or port m-lag ipv6 virtual-ip command. The M-LAG member devices will use the M-LAG virtual IP addresses to set up routing neighbor relationships with the server-side network devices. If the servers send Layer 3 traffic sourced from container nodes, the server-side network devices forward the traffic to the M-LAG system based on the routes generated for the routing neighbor relationships, as shown in Figure 16.

NOTE:

For support of VSI interfaces for M-LAG virtual IP addresses in this application scenario and configuration details, see Access to M-LAG Through Dynamic Routing and Distributed EVPN Gateways Configuration Example.

Figure 16 Network diagram

Table 11 Configuration tasks

Tasks	Forwarding
· Create a VSI interface with the same number on each M-LAG member device as the gateways for a subnet. · Assign the same gateway IP address to the VSI interfaces. · Assign different M-LAG virtual IP addresses to the VS interfaces.	· For the Layer 2 and Layer 3 overlay traffic sent by the servers, the M-LAG member devices perform forwarding based on the MAC address entries and FIB entries. · For the external traffic destined for the servers, the M-LAG member devices perform forwarding based on the routes generated for the routing neighbor relationships with the server-side network devices.

Tasks

Forwarding

· Create a VSI interface with the same number on each M-LAG member device as the gateways for a subnet.

· Assign the same gateway IP address to the VSI interfaces.

· Assign different M-LAG virtual IP addresses to the VS interfaces.

· For the Layer 2 and Layer 3 overlay traffic sent by the servers, the M-LAG member devices perform forwarding based on the MAC address entries and FIB entries.

· For the external traffic destined for the servers, the M-LAG member devices perform forwarding based on the routes generated for the routing neighbor relationships with the server-side network devices.

M-LAG, EVPN, and DHCP relay

About this deployment scheme

You can use both EVPN and DHCP relay on an M-LAG system. As shown in Figure 17, the leaf-tier M-LAG systems are formed by distributed EVPN gateways, and the DHCP server and DHCP client reside in different subnets that belong to two VXLANs. The DHCP client can obtain an IP address from the DHCP server through DHCP relay. The DHCP server and client are unaware of the overlay network.

Both DHCPv4 relay and DHCPv6 relay are supported on an M-LAG system, and the M-LAG member devices in an M-LAG system must have the same DHCP relay configuration.

As a best practice, use a dedicated DHCP server instead of one collocated with a switch. The collocation scheme degrades the performance of a switch.

Figure 17 Network diagram

Table 12 Configuration tasks

Tasks	Forwarding	Remarks
· Set up two M-LAG systems at the leaf tier. · Attach the DHCP server and DHCP client to their local M-LAG systems with one or two links. · Configure distributed EVPN gateway and DHCP relay settings on the M-LAG systems.	· A DHCP request sent from the DHCP client to the DHCP server is forwarded as follows: a. Leaf 1-1 or Leaf 1-2 selects a DHCP server, encapsulates the DHCP request, and forwards it over a VXLAN tunnel towards the DHCP server. b. Leaf 2-1 or Leaf 2-2 decapsulates the DHCP request and forwards it to the DHCP server. · A DHCP relay sent from the DHCP server to the DHCP client is forwarded as follows: a. Leaf 2-1 or Leaf 2-2 encapsulates the DHCP reply and forwards it over a VXLAN tunnel towards the DHCP client. b. Leaf 1-1 or Leaf 1-2 decapsulates the DHCP reply and forwards it to the DHCP client. If multiple M-LAG systems are deployed on the route between the DHCP server and DHCP client, the M-LAG systems forward a DHCP reply hop by hop to the gateway for the DHCP client. When a large number of endpoints access the network simultaneously, DHCP packets will surge. As a result, some endpoints might fail to obtain IP addresses immediately after requests are sent.	You must configure DHCP relay on the leaf devices attached to the DHCP client. If you do not know the location of the DHCP client, configure DHCP relay on all leaf devices. If leaf devices provide both distributed EVPN gateway and DHCP relay services, you must perform the following steps: · Execute the dhcp relay mac-forward enable command to enable MAC address table lookup for DHCP replies that do not have request forwarding information. · Execute the dhcp relay request-from-tunnel discard command on the VSI interfaces that act as DHCP relay agents to discard the DHCP requests received from VXLAN tunnels. This feature prevents the DHCP server from receiving the same DHCP request from the relay agents on different leaf devices.

Tasks

Forwarding

Remarks

· Set up two M-LAG systems at the leaf tier.

· Attach the DHCP server and DHCP client to their local M-LAG systems with one or two links.

· Configure distributed EVPN gateway and DHCP relay settings on the M-LAG systems.

· A DHCP request sent from the DHCP client to the DHCP server is forwarded as follows:

a. Leaf 1-1 or Leaf 1-2 selects a DHCP server, encapsulates the DHCP request, and forwards it over a VXLAN tunnel towards the DHCP server.

b. Leaf 2-1 or Leaf 2-2 decapsulates the DHCP request and forwards it to the DHCP server.

· A DHCP relay sent from the DHCP server to the DHCP client is forwarded as follows:

a. Leaf 2-1 or Leaf 2-2 encapsulates the DHCP reply and forwards it over a VXLAN tunnel towards the DHCP client.

b. Leaf 1-1 or Leaf 1-2 decapsulates the DHCP reply and forwards it to the DHCP client.

If multiple M-LAG systems are deployed on the route between the DHCP server and DHCP client, the M-LAG systems forward a DHCP reply hop by hop to the gateway for the DHCP client. When a large number of endpoints access the network simultaneously, DHCP packets will surge. As a result, some endpoints might fail to obtain IP addresses immediately after requests are sent.

You must configure DHCP relay on the leaf devices attached to the DHCP client. If you do not know the location of the DHCP client, configure DHCP relay on all leaf devices.

If leaf devices provide both distributed EVPN gateway and DHCP relay services, you must perform the following steps:

· Execute the dhcp relay mac-forward enable command to enable MAC address table lookup for DHCP replies that do not have request forwarding information.

· Execute the dhcp relay request-from-tunnel discard command on the VSI interfaces that act as DHCP relay agents to discard the DHCP requests received from VXLAN tunnels. This feature prevents the DHCP server from receiving the same DHCP request from the relay agents on different leaf devices.

For more configuration details, see M-LAG+EVPN Distributed Gateway (OSPF on Underlay Network)+DHCP Relay+Microsegmentation+Service Chain Configuration Example.

Restrictions and guidelines

In a distributed EVPN gateway network, the replies from the DHCPv6 server must carry client MAC address information for DHCPv6 reply forwarding based on MAC address table to take effect. To meet this requirement, use the ipv6 dhcp relay interface-id user mac command. This command enables the DHCPv6 relay agent to insert client MAC addresses into Option 18 for DHCPv6 requests. Then, the replies from the DHCPv6 server will carry client MAC address information.

M-LAG does not support the following DHCP relay features:

· Relay entry recording by the relay agent.

· DHCP relay agent and DHCP server proxy.

· Client offline detection.

EVPN M-LAG, microsegmentation, and service chain

Network model

To simplify O&M and implement security protection, you can use microsegments to isolate users of different subnets and control traffic on a per-user group basis in an EVPN network with distributed gateways deployed. To filter and protect service traffic, you can deploy service chains to direct service traffic to traverse a series of service nodes in turn, firewall nodes for example.

Figure 18 Network diagram

Table 13 Configuration tasks

Tasks	Forwarding
· Set up three M-LAG systems with the following devices to ensure availability of the network: ¡ Service Leaf 1 and Service Leaf 2. ¡ Leaf 3 and Leaf 4. ¡ Leaf 5 and Leaf 6. · Configure Spine A and Spine B as RRs to reflect routes between the leaf and borer tiers, and configure them to forward underlay traffic. · Set up an M-LAG system with Border 1 and Border 2, borer devices of the fabric. Aggregate the uplinks to the external devices through M-LAG, and use Layer 3 Ethernet interfaces to connect the downstream spine devices. · Configure microsegments on the leaf and border devices to isolate and protect users on different subnets. · Configure service chains on the leaf and border devices to direct service traffic processing.	· For the service packets received from an AC, a leaf device matches them to ACLs to allocate them to a microsegment. · For north-south service traffic, a leaf device specifies the next hop as the IP address of the NS firewall and adds a service chain ID. For east-west service traffic, a leaf device specifies the next hop as the IP address of the EW firewall and adds a service chain ID. · The service leaf devices forward service traffic to the NS and EW firewalls based on the service ID for filtering and protection. · After processed by the NS and EW firewalls, service traffic is forwarded back to the leaf devices based on configured routes. The leaf devices then forward the service traffic to their local sites.

Tasks

Forwarding

· Set up three M-LAG systems with the following devices to ensure availability of the network:

¡ Service Leaf 1 and Service Leaf 2.

¡ Leaf 3 and Leaf 4.

¡ Leaf 5 and Leaf 6.

· Configure Spine A and Spine B as RRs to reflect routes between the leaf and borer tiers, and configure them to forward underlay traffic.

· Set up an M-LAG system with Border 1 and Border 2, borer devices of the fabric. Aggregate the uplinks to the external devices through M-LAG, and use Layer 3 Ethernet interfaces to connect the downstream spine devices.

· Configure microsegments on the leaf and border devices to isolate and protect users on different subnets.

· Configure service chains on the leaf and border devices to direct service traffic processing.

· For the service packets received from an AC, a leaf device matches them to ACLs to allocate them to a microsegment.

· For north-south service traffic, a leaf device specifies the next hop as the IP address of the NS firewall and adds a service chain ID. For east-west service traffic, a leaf device specifies the next hop as the IP address of the EW firewall and adds a service chain ID.

· The service leaf devices forward service traffic to the NS and EW firewalls based on the service ID for filtering and protection.

· After processed by the NS and EW firewalls, service traffic is forwarded back to the leaf devices based on configured routes. The leaf devices then forward the service traffic to their local sites.

For more configuration details, see M-LAG+EVPN Distributed Gateway (OSPF on Underlay Network)+DHCP Relay+Microsegmentation+Service Chain Configuration Example.

M-LAG and underlay multicast

You can attach Layer 2 or Layer 3 multicast sources or receivers to an M-LAG system to prevent single points of failure from interrupting multicast forwarding.

The following matrix shows hardware support for conjunctive use of M-LAG and underlay multicast.

Hardware	Software	Reference
S12500X-AF, S6890	Not supported	N/A
S12500G-AF	Layer 2 multicast: R7625 or later Layer 3 multicast: R7625 or later	See the following chapters in IP Multicast Configuration Guide of H3C S12500G-AF Switch Series Configuration Guides-R7625Pxx: · IGMP snooping configuration · PIM configuration · MLD snooping configuration · IPv6 PIM configuration
S6805, S6825, S6850, S9850	Layer 2 multicast: R6710 (only IPv4) Layer 3 multicast: R6710 (only IPv4)	See the following chapters in IP Multicast Configuration Guide of H3C S6805 & S6825 & S6850 & S9850 Configuration Guides-671xx: · IGMP snooping configuration · PIM configuration
S9820-64H, S9820-8C	Layer 2 multicast: Not supported Layer 3 multicast: Not supported	N/A
S6800, S6860	Layer 2 multicast: Not supported Layer 3 multicast: Not supported	N/A
S6812, S6813	Layer 2 multicast: Not supported Layer 3 multicast: F6628P22	See the following chapters in IP Multicast Configuration Guide of H3C S6812 & S6813 Switch Series Configuration Guide-R662x: · PIM configuration · IPv6 PIM configuration

M-LAG and MVXLAN

Multicast VXLAN (MVXLAN) transmits multicast traffic from a multicast source to multicast receivers in a VXLAN or EVPN VXLAN network.

You can set up an M-LAG system with two VTEPs or border devices in an MVXLAN network to prevent single points of failure from interrupting services. A multicast source can reside in the local data center, a remote data center, or the public network.

In an M-LAG system, the M-LAG member devices set up MVXLAN tunnels that use the virtual VTEP address as the multicast source and the default group address as the destination. The M-LAG member devices synchronize multicast traffic and multicast join requests (IGMP membership reports or PIM join messages) over the peer link to maintain consistency in multicast source and receiver information. When one M-LAG member device fails or its uplink or downlink fails, the other M-LAG member device forwards all multicast traffic to avoid traffic interruption.

NOTE:

For more information about support for MVXLAN and configuration details, see M-LAG and MVXLAN Configuration Example.

Figure 19 Network diagram

Table 14 Configuration tasks

Tasks	Forwarding
· Configure the leaf devices as VTEPs to provide network access for the multicast source and receivers. · Set up M-LAG systems with the VTEPs, and attach each multicast source or receiver to the local M-LAG system by using two links. · Configure the spine devices as RRs to reflect routes between the leaf and border tiers. · Set up an M-LAG system with the border devices to ensure reliable external network access. · Configure PIM-SM on the interfaces used by the leaf, spine, and border devices to interconnect one another. · Configure IGMP snooping on the leaf devices for multicast forwarding entry creation. · Establish MVXLAN tunnels between the leaf and border tiers. · Configure the EDs to discover multicast receivers outside the local data center based on BGP EVPN routes.	· When an M-LAG member device receives multicast traffic, it sends the traffic over the peer link for the other M-LAG member device to load share the traffic. ¡ The M-LAG member device with an odd M-LAG system number forwards traffic destined for odd multicast group addresses. ¡ The M-LAG member device with an even M-LAG system number forwards traffic destined for even multicast group addresses. ¡ When one M-LAG member device fails, the other M-LAG member device forwards all multicast traffic. · The MVXLAN tunnel is used to forward multicast traffic between two leaf-tier M-LAG systems or between a leaf-tier M-LAG system and the border-tier M-LAG system. · The device attached to a multicast receiver forwards multicast traffic based on multicast forwarding entries.

Tasks

Forwarding

· Configure the leaf devices as VTEPs to provide network access for the multicast source and receivers.

· Set up M-LAG systems with the VTEPs, and attach each multicast source or receiver to the local M-LAG system by using two links.

· Configure the spine devices as RRs to reflect routes between the leaf and border tiers.

· Set up an M-LAG system with the border devices to ensure reliable external network access.

· Configure PIM-SM on the interfaces used by the leaf, spine, and border devices to interconnect one another.

· Configure IGMP snooping on the leaf devices for multicast forwarding entry creation.

· Establish MVXLAN tunnels between the leaf and border tiers.

· Configure the EDs to discover multicast receivers outside the local data center based on BGP EVPN routes.

· When an M-LAG member device receives multicast traffic, it sends the traffic over the peer link for the other M-LAG member device to load share the traffic.

¡ The M-LAG member device with an odd M-LAG system number forwards traffic destined for odd multicast group addresses.

¡ The M-LAG member device with an even M-LAG system number forwards traffic destined for even multicast group addresses.

¡ When one M-LAG member device fails, the other M-LAG member device forwards all multicast traffic.

· The MVXLAN tunnel is used to forward multicast traffic between two leaf-tier M-LAG systems or between a leaf-tier M-LAG system and the border-tier M-LAG system.

· The device attached to a multicast receiver forwards multicast traffic based on multicast forwarding entries.

M-LAG and DCI

You can use M-LAG to virtualize two physical EDs of a data center into a virtual ED to prevent single points of failure from interrupting traffic.

You can use a ring or mesh topology to interconnect the EDs of different data centers. As shown in Figure 20, a ring topology requires fewer physical links than a mesh topology. In a mesh topology, an ED is connected to a remote ED by using multiple physical links, which increases availability of the network. If the link between ED 1 and ED 3 fails in the ring topology, traffic of ED 1 is forwarded to ED 2 and then to ED 4. In a mesh topology, ED 1 can forward traffic directly to ED 4.

The S12500X-AF, S6890, S6800, and S6860 switches support IPv4 underlay and both IPv4 and IPv6 overlay.

The S12500G-AF, S6805, S6825, S6850, and S9850 switches support both IPv4 and IPv6 underlay networks. The overlay and underlay networks can use different IP versions. For example, you can set up an IPv4 overlay network on top of an IPv6 underlay network.

NOTE:

For more information about support for M-LAG on EDs and configuration details, see M-LAG and DCI Configuration Example.

Figure 20 Network diagram

Table 15 Configuration tasks

Tasks	Forwarding
· Establish VXLAN-DCI tunnels between EDs of different data centers, and set up an M-LAG system with the local EDs in each data center. · Establish VXLAN tunnels between the leaf devices and EDs in each data center. · Configure the spine devices as RRs to reflect routes between the leaf devices and EDs.	· In an M-LAG system, the member EDs use a virtual ED address to set up VXLAN tunnels or VXLAN-DCI tunnels with VTEPs or remote EDs. The member EDs use different BGP peer addresses to establish neighbor relationships with the spine devices or remote EDs. For load sharing and link redundancy, a neighbor sends traffic destined for the virtual ED address to both of the member EDs based on ECMP routes for the underlay network. · A packet is forwarded between VMs in different data centers as follows: a. The source-side leaf device forwards the packet to the local EDs over a VXLAN tunnel. b. An ED decapsulates the packet, encapsulates the packet, and forwards it over a VXLAN-DCI tunnel to a remote data center. c. A remote ED decapsulates the packet, encapsulates the packet, and forwards it over a VXLAN tunnel to the destination-side VTEP. d. The destination-side VTEP decapsulates the packet and forwards it to the destination VM.

Tasks

Forwarding

· Establish VXLAN-DCI tunnels between EDs of different data centers, and set up an M-LAG system with the local EDs in each data center.

· Establish VXLAN tunnels between the leaf devices and EDs in each data center.

· Configure the spine devices as RRs to reflect routes between the leaf devices and EDs.

· In an M-LAG system, the member EDs use a virtual ED address to set up VXLAN tunnels or VXLAN-DCI tunnels with VTEPs or remote EDs. The member EDs use different BGP peer addresses to establish neighbor relationships with the spine devices or remote EDs. For load sharing and link redundancy, a neighbor sends traffic destined for the virtual ED address to both of the member EDs based on ECMP routes for the underlay network.

· A packet is forwarded between VMs in different data centers as follows:

a. The source-side leaf device forwards the packet to the local EDs over a VXLAN tunnel.

b. An ED decapsulates the packet, encapsulates the packet, and forwards it over a VXLAN-DCI tunnel to a remote data center.

c. A remote ED decapsulates the packet, encapsulates the packet, and forwards it over a VXLAN tunnel to the destination-side VTEP.

d. The destination-side VTEP decapsulates the packet and forwards it to the destination VM.

Management network design

As a best practice to prevent forwarding faults from interrupting device management, use management Ethernet interfaces to connect devices to a management network for out-of-band management. Table 16 shows the number of management Ethernet interfaces on the data center devices.

In an M-LAG system, all management Ethernet interfaces on both M-LAG member devices are available. You need to manage the M-LAG member devices separately.

Table 16 Number of management Ethernet interfaces on data center devices

Devices providing two or more management Ethernet interfaces	Devices providing one management Ethernet interface
· S12500X-AF and S12500F series (some MPU models provide four management Ethernet interfaces) · S12500G-AF series · S6890 series · S6805 series · S6825 series · S6850 series · S9850 series · S9820-8C · S9820-64H · S6800-54QF (LS-6800-54QF-H3) · S6800-54QF (LS-6800-54QF-H5) · S6800-54QT (LS-6800-54QT-H3) · S6800-54HF · S6800-54HT	· S6800-32Q · S6800-54QF (LS-6800-54QF) · S6800-54QF (LS-6800-54QF-H1) · S6800-54QT (LS-6800-54QT) · S6800-54QT (LS-6800-54QT-H1) · S6800-2C · S6800-2C-FC · S6800-4C · S6812, S6813

Devices providing two or more management Ethernet interfaces

Devices providing one management Ethernet interface

· S12500X-AF and S12500F series (some MPU models provide four management Ethernet interfaces)

· S12500G-AF series

· S6890 series

· S6805 series

· S6825 series

· S6850 series

· S9850 series

· S9820-8C

· S9820-64H

· S6800-54QF (LS-6800-54QF-H3)

· S6800-54QF (LS-6800-54QF-H5)

· S6800-54QT (LS-6800-54QT-H3)

· S6800-54HF

· S6800-54HT

· S6800-32Q

· S6800-54QF (LS-6800-54QF)

· S6800-54QF (LS-6800-54QF-H1)

· S6800-54QT (LS-6800-54QT)

· S6800-54QT (LS-6800-54QT-H1)

· S6800-2C

· S6800-2C-FC

· S6800-4C

· S6812, S6813

Figure 21 shows the management network topology for a data center. The border, spine, and leaf devices are attached to the out-of-band management switch by using management Ethernet interfaces, and the servers are attached to the switch by using BMCs. The switch provides gateway services.

Figure 21 Out-of-band management

High availability for M-LAG

High availability of uplinks

You can use the following methods to ensure high availability of uplinks:

· Configure routes—Create one VLAN interface on each M-LAG member device, and set up routing neighbor relationships over the peer link between the VLAN interfaces. When the uplink on an M-LAG member device fails, the device sends its traffic over the peer link for the other M-LAG member device to forward.

¡ If an M-LAG system is attached to standalone upstream devices and ECMP routes are configured for load sharing across the uplinks, you need to interconnect the M-LAG member devices through routing. The Layer 3 connections will be used to transmit traffic between the M-LAG member devices in case of uplink failure.

¡ If an M-LAG system operating at Layer 2 is attached to an upstream M-LAG system, you do not need to interconnect the M-LAG member devices through routing.

· Configure Monitor Link—Associate the M-LAG interfaces with the uplink interfaces. When the uplink interface of an M-LAG member device fails, that device shuts down its M-LAG interface for the other M-LAG member device to forward all traffic. Use this method if the peer link forwards heavy traffic and has bandwidth bottlenecks.

For Monitor Link configuration details, see M-LAG+EVPN+Monitor Link Configuration Examples.

High availability of leaf devices

To ensure high availability of leaf devices in an M-LAG system, use the schemes in Table 17.

Figure 22 High availability of leaf devices

Table 17 Leaf high availability schemes

Scenario	Impact	High availability scheme
Leaf device failure	· When Leaf 1 restarts, traffic is switched to Leaf 2. · After Leaf 1 restarts, the following events occur: a. The peer link comes up. b. Leaf 2 sends its MAC address entries and ARP entries over the peer link to Leaf 1. c. Leaf 1 brings up the member ports of the M-LAG interfaces when the data restoration interval set by using the m-lag restore-delay command expires. d. Leaf 1 brings up all service interfaces after forwarding entries are refreshed for all interfaces.	N/A
Failure of a link to a spine device	· When the link between Leaf 1 and Spine 1 fails, all uplink traffic is sent to Spine 2. · Leaf 1 sends traffic over the peer link to Leaf 2 if the link between Leaf 1 and Spine 2 is also down.	N/A
Link failure on an M-LAG interface	A server is dualhomed to the leaf devices. When one uplink failures, the server sends all traffic through the other uplink. After the failed uplink recovers, the server sends traffic over both uplinks.	N/A
Failure of a link to a single-homed server (server NIC in active/standby mode)	A server is singhomed to both leaf devices by using non-aggregate uplinks, and only one uplink is active. When the active uplink fails, the standby uplink comes up to transmit traffic. If active link preemption is enabled, the original active link preempts the active link role after it recovers.	N/A
Keepalive link failure	Keepalive link failure does not affect traffic forwarding. This link is used for multi-active collision detection only when a device or the peer link fails.	Exclude the interfaces used for keepalive detection from the shutdown action by M-LAG MAD.
Peer link failure	· The secondary leaf device places its uplink and downlink interfaces in M-LAG MAD DOWN state to switch traffic to the other leaf device. · After the peer link recovers, the interfaces in M-LAG MAD DOWN state are brought up after the data restoration interval set by using the m-lag restore-delay command expires. Then, traffic is switched back to the secondary leaf device.	Use interfaces from multiple modules or submodules to set up the peer link.
Concurrent peer link and keepalive link failures (M-LAG dualhoming)	If the keepalive link goes down before the peer link goes down, the following events occur: 1. The leaf devices are placed in M-LAG standalone mode. 2. Only one leaf device has selected aggregation member ports and forwards traffic. If the peer link goes down before the keepalive link goes down, the following events occur: 1. When the peer link does down, the secondary leaf device places its interfaces in M-LAG MAD DOWN state. 2. When the keepalive link goes down, the secondary leaf device brings up its interfaces in M-LAG MAD DOWN state. 3. The leaf devices are placed in M-LAG standalone mode. Only one leaf device has selected aggregation member ports and forwards traffic.	· Enable M-LAG standalone mode on the leaf devices. · Configure the LACP system ID by using one of the following methods: a. Execute the lacp system-mac and lacp system-priority commands in system view. b. Execute the port lacp system-mac and port lacp system-priority commands in Layer 2 aggregate interface view.
Concurrent peer link and keepalive link failures (server NIC in active/standby mode)	If the peer link goes down before the keepalive link goes down, the following events occur: 1. When the peer link does down, the secondary leaf device places its interfaces in M-LAG MAD DOWN state. 2. When the keepalive link goes down, the secondary leaf device removes its interfaces from M-LAG MAD DOWN state. 3. Both leaf devices are primary devices, and forwarding faults occur. To avoid forwarding faults, execute the m-lag mad persistent command on the secondary device. The secondary device will not remove its interfaces from M-LAG MAD DOWN state even if the primary device fails. You must use the m-lag mad restore command to bring up the interfaces. If the keepalive link goes down before the peer link goes down, recover the links as soon as possible.	Execute the m-lag mad persistent command.

High availability of border devices

To ensure high availability of border devices in an M-LAG system, use the schemes in Table 18.

Figure 23 High availability of border devices

Table 18 Border high availability schemes

Scenario	Impact	High availability scheme
Border device failure	· When Border 1 restarts, traffic is switched to Border 2. · After Border 1 restarts, the following events occur: a. The peer link comes up. b. Border 2 sends its MAC address entries and ARP entries over the peer link to Border 1. c. Border 1 brings up the member ports of the M-LAG interfaces when the data restoration interval set by using the m-lag restore-delay command expires. d. Border 1 brings up all service interfaces after forwarding entries are refreshed for all interfaces.	N/A
Module failure on a border device	Uplinks or downlinks might be distributed to multiple modules. When a module fails, traffic is switched to the other modules for forwarding. If no available links exist on the other modules, traffic is switched to the peer M-LAG member device.	Distribute uplink and downlink to multiple modules or submodules as a best practice. Do not use a single module or submodule to provide uplinks or downlinks.
Uplink failure or upstream device failure	When the link between a border device and a PE fails, traffic is switched to backup links. After the link recovers, traffic is switched back to it. The switchback speed is determined by the configuration on the PE.	Configure routing settings as follows on the border devices to reduce the packet loss caused by slow PE-side network convergence. You do not need to execute the following commands if the routing table is small or network convergence is fast on the PEs. For IS-IS, OSPF, or OSPFv3, execute the following commands: · isis peer hold-max-cost duration · ospf peer hold-max-cost duration · ospfv3 peer hold-max-cost duration For BGP, execute the following commands: · bgp apply-policy on-startup duration second The value for the seconds argument must be longer than the time used to establish neighbor relationships between the PEs and border devices. · bgp policy on-startup med
Failure of a link between a border and a firewall or load balancer	The firewall or load balancer is dualhomed to the border devices. When one link fails, traffic is switched to the other link. When the failed link recovers, traffic is switched back to it.	N/A
Failure of a link between a border device and a spine device	ECMP routes exist between the spine devices and the border devices. If a link fails, its traffic is switched to another link.	N/A
Keepalive link failure	Keepalive link failure does not affect traffic forwarding. This link is used for multi-active collision detection only when a device or the peer link fails.	Exclude the interfaces used for keepalive detection from the shutdown action by M-LAG MAD.
Peer link failure	· The secondary border device places its uplink and downlink interfaces in M-LAG MAD DOWN state to switch traffic to the other border device. · After the peer link recovers, the interfaces in M-LAG MAD DOWN state are brought up after the data restoration interval set by using the m-lag restore-delay command expires. Then, traffic is switched back to the secondary border device.	Use interfaces from multiple modules or submodules to set up the peer link.
Concurrent peer link and keepalive link failures	If the keepalive link goes down before the peer link goes down, the following events occur: 1. The border devices are placed in M-LAG standalone mode. 2. Only one border device has selected aggregation member ports and forwards traffic. If the peer link goes down before the keepalive link goes down, the following events occur: 1. When the peer link does down, the secondary border device places its interfaces in M-LAG MAD DOWN state. 2. When the keepalive link goes down, the secondary border device brings up its interfaces in M-LAG MAD DOWN state. 3. The border devices are placed in M-LAG standalone mode. Only one border device has selected aggregation member ports and forwards traffic.	· Enable M-LAG standalone mode on the border devices. · Configure the LACP system ID by using one of the following methods: a. Execute the lacp system-mac and lacp system-priority commands in system view. b. Execute the port lacp system-mac and port lacp system-priority commands in Layer 2 aggregate interface view.

Recommended hardware and software versions

You must install the latest patches (if any) for the recommended software versions on all devices.

If the hardware and software versions listed in the following matrix conflict with those used in configuration examples, use the hardware and software versions in the configuration examples. If you have any doubts, contact H3C Support.

Table 19 Recommended hardware and software versions

Device role	Scenario	Hardware	Software version
Border/ED	Medium and large networks	H-series modules for the S12500X-AF switches	R2825
	Medium and large networks	All modules supported by the S12500G-AF switches	R7625 and later
	Small networks	Same as the leaf devices	Same as the leaf devices
Spine	N/A	H-series modules for the S12500X-AF switches	R2825
Spine	N/A	All modules supported by the S12500G-AF switches	R7625 and later
Leaf	10GE connection	· S6800 · S6860 · S6805 · S6890 · S6850-2C or S9850-4C with 10GE interface expansion modules installed · S6812, S6813	· S6800, S6860: R6710 · S6805, S6850, S9850: R6710 · S6890: R2825 · S6812, S6813: F6628P22
	25GE connection	· S6825 · S6850-56HF · S6850-2C or S9820-4C with 25GE interface expansion modules installed	S6825, S6850, S9850: R6710
	40GE connection	· S6800 · S6850-2C or S9850-4C with 40GE interface expansion modules installed	· S6800: R6710 · S6850, S9850: R6710
	100GE connection	· S9850-32H · S6850-2C or S9850-4C with 100GE interface expansion modules installed · S9820-8C · S9820-64H	S6850, S9850, S9820-8C, S9820-64H: R6710

H3C Data Center Switches M-LAG Configuration Guide-6W100

M-LAG network planning

Overlay network planning

Underlay network planning

Restrictions and guidelines for M-LAG system setup

Peer link

Keepalive link

M-LAG interface

M-LAG MAD

MAC address assignment for the S12500X-AF switches

Restrictions and guidelines

M-LAG system configuration

Peer-link interface configuration

M-LAG data restoration interval

IRF

MDC

GIR

MAC address table

ARP

Link aggregation

Port isolation

CFD

Smart Link

Mirroring

MAC address synchronization

M-LAG network models

Network model

Restrictions and guidelines

Mechanisms

Compatibility of data center switches with VSI-based loop detection

Restrictions and guidelines

About dual-active VLAN interfaces

Network models for deploying dual-active VLAN interfaces on M-LAG systems at multiple layers with core devices as gateways

Network models for deploying dual-active VLAN interfaces on M-LAG systems at multiple layers with distribution and core devices as gateways

Restrictions and guidelines

Routing neighbor relationship setup on dual-active VLAN interfaces using M-LAG virtual IP addresses

VRRP gateways

Network model

Restrictions and guidelines

Dual-active VLAN interfaces

VRRP gateways

Restrictions and guidelines for routing configuration

Router ID

NSR

OSPF and OSPFv3

M-LAG and EVPN

Failover between data centers

Network setup

ACs

Peer link

Miscellaneous

MAC address configuration for L3VNI associated VSI interfaces

MAC address configuration for distributed gateway interfaces

Border and ED configuration restrictions and guidelines

Routing neighbor relationship setup on an M-LAG system formed by distributed EVPN gateways

Restrictions and guidelines

M-LAG and underlay multicast

Cloud & AI

InterConnect

Intelligent Terminal Products

Product Support Services

Technical Service Solutions

Resource Center

Policy

Online Help

Become a Partner

Partner Resources

Partner Business Management

Company Information

News & Events

Contact Us