Tag :: Mlag

EOS 4.23.1F added basic MLAG support for 7800R3, 7500R3 and 7280R3 platforms. The MLAG features that are currently

As described in the Multi-VTEP MLAG TOI, singly connected hosts can lead to suboptimal peer-link utilization. By adding a local VTEP to each MLAG peer, the control plane is able to advertise singly connected hosts as being directly behind a specific local VTEP / MLAG peer.

Each ARP/ND packet into a switch may generate an update for the switch ARP/Neighbor table and this update may need to be synchronized with the MLAG peer when VXLAN is configured. Prior to this feature, these updates (on a VXLAN setup) are synchronized by sending an UDP packet (one packet per update) containing the IP/MAC/VLAN information from the MLAG peer where the ARP/ND packet is received to the other MLAG peer. 

4.22.1F introduces support for ip address virtual for PIM and IGMP in MLAG and Vxlan. On a VLAN, the same IP address can

When MLAG peer link goes down, the secondary peer assumes the primary peer is down/dead, and takes over the primary

In order to achieve split horizon and prevent double-delivery of packets in an MLAG setup, egress ACLs are installed on all active MLAG interfaces so that BUM traffic received on the MLAG peer-link cannot get forwarded out any MLAG interfaces. When only one half of an MLAG interface is active, this egress ACL is removed to allow BUM traffic from the peer-link to be forwarded out MLAG interfaces.

In an MLAG setup, periodic TCP/UDP heartbeats are sent over peer link to ensure IP connectivity between peers. Prior

This feature allows users to configure L2 subinterfaces on MLAG interfaces. L2 subinterfaces are not supported on the MLAG peer-link.

The objective of Maintenance Mode on MLAG is to gracefully drain away the traffic (L2 and BGP) flowing through a switch

If an MLAG flaps on one peer, then we may have to remap the MAC addresses learned, such that the reachability is via the

As of release 4.20.5F, this feature is now available on 7160 series switches. Here is a link to earlier

On a MLAG chassis, MAC addresses learned on individual peers are synced and appropriate interfaces are mapped to these MAC addresses. In case of unexpected events like reloading of one of the peers in the MLAG chassis or flapping of one or more MLAG interfaces, some loss of traffic may be observed.

In conventional VXLAN deployments, each MLAG pair of switches are represented as a common logical VTEP. VXLAN traffic can be decapsulated on either switch. In some networks, there are hosts that are singly connected to one of the MLAG pair.

[L2 EVPN] and  [Multicast EVPN IRB] solutions allow for the delivery of customer BUM (Broadcast, Unknown unicast and Multicast) traffic in a L2VPN and L3VPNs respectively using multicast in the underlay network.

Multicast VRF leak allows multicast traffic from a sender in one domain or VRF to be forwarded to a different domain or VRF, in which the receivers are connected. In the rest of this document, the VRF to which the multicast sender belongs to is referred to as the “source VRF” and the VRF that the multicast receiver belongs to is referred to as the “receiver VRF”.

NAT Peer State Synchronization feature provides redundancy and resiliency for Dynamic NAT across a pair of devices in an attempt to mitigate the risk of single NAT device failure. Each switch advertises connection state updates to its peer.  State update consists of connection creation, connection state change (TCP mostly) or connection tear down

From the Precision Time Protocol (PTP) perspective, Multi Chassis Link Aggregation (MLAG) peers are two physical