• Tag : mlag

 
 

EVPN – MLAG single homed hosts

Description As described in the Multi-VTEP MLAG TOI, singly connected hosts can lead to suboptimal peer-link utilisation. 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. The multi-VTEP MLAG feature has been extended to add EVPN control plane support. VXLAN bridging (EVPN Type-2 and Type-3 routes) and routing (EVPN Type-5 routes and IRB) are supported by this feature. When multi-VTEP MLAG mode is enabled, outgoing EVPN route advertisements will contain a nexthop and router MAC extended community as summarized...
Continue reading →

attached-host routes and MLAG

I have been experimenting in our test environment with attached-host routes on a vxlan network. We have are using asymmetric IRB across our vxlan infrastructure as it is (for the moment at least) simple enough for this not to cause us an issue. We want to use attached-host to ensure that the correct pair of leaf switches are used for routing “southbound” traffic. In the production environment there will be 5 pairs of leaf switches which will be routing traffic for the edge vlan. Behind this vlan are ~50 nodes that are connected with MLAG to the pairs of (7060CX)...
Continue reading →

“ip address virtual” support for PIM and IGMP

Description 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 be configured using ip address virtual on both mlag devices as well as on different VTEPs. Control packets are source NATed by the kernel to a chosen IP address. The source NATing fails for PIM and IGMP. To overcome this, users can configure pim ipv4 local-interface and borrow the IP address to be used on the VLAN.  PIM and IGMP bypass the source NATing in the kernel. The interface configuration pim ipv4 local-interface allows PIM and...
Continue reading →

Default Load-balancing method in DCS-7160-48TC6-F

IN DCS-7160-48TC6-F version 4.20.7M EoS, we’re not able to check what default method is implemented in SW as we can do in other models like DCS-7280SR-48C6-F. In documentation, they’re not any reference to configuration like command line permit: #port-channel load-balance xp polynomial hash-a … Could you help me, please? Regards.

MLAG MaintenanceMode

Description The objective of Maintenance Mode on MLAG is to gracefully drain away the traffic (L2 and BGP) flowing through a switch that is part of the MLAG pair while the switch is put into maintenance and to gracefully add it back into the network and attract traffic again, once the switch is out of maintenance. Platform compatibility Compatible with all platforms. Configuration Maintenance Mode on a device in an MLAG Domain can only be configured for System Unit which consists of all the BGP neighbors and the interfaces. Following steps are putting device into maintenance mode: Setting mlag and non-mlag...
Continue reading →

MLAG Additional Port

Hi, I have existing MLAG between 2 switches in Arista 7050sx-64 and now I want to add additional Port to the MLAG for safety and redundancy there is any quick guide / commands for it? Regards,

MAC Address flapping – VXLAN with MLAG

As per the attached diagram, its a VXLAN EVPN setup. Everything was working fine on that side. Both switches in city A and City B have MLAG configured with the TOR Stack switches. After creating MLAG with the TOR Stack switches, all MAC addresses have started flapping. For example MAC address ab-bc-cd is coming from the server connected to TOR Stack switch in City B. On B-SW01 it is learning from Port-channel10 (MLAG) but on B-SW02 it is learning from VX1 interface (vxlan) which is coming from the RR via B-SW01 and then it hands it back to the TOR...
Continue reading →

Multi-VTEP MLAG

Description In conventional VXLAN deployments, each MLAG pair of switches are represented as a common virtual 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. VXLAN packets destined for the singly connected host could land on the other MLAG peer and subsequently be forwarded over the MLAG peer-link to reach the destination host. This path is undesirable since it would use up some bandwidth on the peer-link. Figure 1 : Suboptimal Packet Path to Singly Connected Host The Multi-VTEP MLAG feature prevents unicast VXLAN...
Continue reading →

MLAG+1Uplink router +ebgp

HI all let’s say we have a similar topology like the one above in which we have 2 arista switches forming a mlag peership between them and on the other side we just have 1 uplink router connected to both switches. is it possible to configure the router with a portchannel connected to both arista while running 2 different eBGP sessions one of each towards each arista? can this x2 eBGP sessions be runnig over the same vlan? let’s say svi1 on sw1, svi2 on sw2, svi3 on router port-channel sharing the same lan. If so, should that vlan be...
Continue reading →

MLAG Unicast Convergence

MLAG Unicast Convergence provides the ability to fast redirect traffic through the other peer, in the event of local peer reloading or local peer’s MLAG interface(s) flapping. As of release 4.20.5F, this feature is now available on 7160 series switches. Here is a link to earlier TOI on Mlag Unicast Convergence: https://eos.arista.com/eos-4-18-0f/mlag-unicast-convergence/

MLAG Dual Primary Detection

When MLAG peer-link goes down, the secondary peer assumes the primary peer is down/dead, and takes over the primary role. It is possible that when peer-link is down, the primary isn’t actually down/dead and both MLAG peers think they are the primary. This is called “dual-primary” condition/state. In this state, each peer will run Layer-2 protocols such as Spanning Tree Protocol independently. Depending on the topology, this can cause loops in the network. This can also impact IGMP snooping feature. The Dual Primary Detection feature uses the management interface as an out-of-band connection between the two peers along with the peer-link. Once configured, the MLAG peers will send...
Continue reading →

MLAG: Traffic flow for single-homed hosts

Objective The objective of this document is to explain the traffic flows, best practice designs, and configuration details when single-homed devices are connected to an MLAG domain.  It is assumed that the reader is familiar with the concept of Leaf-Spine fabrics, MLAG, and VXLAN. More details about these concepts can be found on EOS Central. Recommended articles are: MLAG – Basic configurationMLAG – Advanced configurationVXLAN bridging with MLAGVXLAN routing with MLAG Introduction Arista’s Multi-Chassis LAG (MLAG) technology provides the ability to build a loop-free active-active layer 2 topology. The technology operates by allowing two physical Arista switches to appear as...
Continue reading →

MLAG ECMP load balance method

Hello, I need a help with proper design. I have a pair 7050X with MLAG configuration. To the downstream devices I have 2 mlag port-channels each contain 2 links. 7050X will provide L3 functionality : gateways and routing.  I would like to enabling ecmp and load-balance the traffic. What will be the best method to choose in this scenario ?   Thank you

OSPF on MLAG Peers

I have a simple single area OSPF topology with two routers. The setup exchanges routes just fine. I would like to convert one of the router/switches to a MLAG configuration. My question is what would be the correct way to approach adding the peer system into the OSPF configuration? Do I treat the two MLAG peered systems as discreet as far as OSPF is concerned? Does/can VARP play a role? I would guess not since the routing engines are separate. Thanks

vEOS – Logical VTEP with MLAG – VXLAN interpreted on MLAG Peer

Hello all, Please see attached picture for network topolgy. I try to use VXLAN with HER for DCI, together with BGP&BFD as routing protocol (for underlay) between Site A and Site B.– Site A: VLAN100 mapped to DCI VNI 10100– Site B: VLAN1100 mapped to DCI VNI 10100– spine1&spine2 as mlag peers with logical VTEP– spine3 as single VTEP– ports for DCI configured as L3 routed (no switchport)– EBGP between spine1 and spine3 as well as spine2 and spine3– VLAN4093 between spine1 (10.0.1.1) and spine2 (10.0.1.2) for re-routing in case one DCI is down– IBGP between spine1 and spine2– target...
Continue reading →

MLAG Unicast Convergence

On an MLAG chassis we sync the MAC addresses learnt on individual peers and make sure we use the appropriate interface to map the 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, we may observe some loss of traffic. If an MLAG flaps on one peer, then we may have to remap the MAC addresses learned, such that the reachability is via the other peer in the MLAG domain. Until we re-map the MAC addresses and host routes, we may drop some...
Continue reading →

DHCP Snooping and MLAG interfaces

I have a vlan that I want to allocate IP addresses to the hosts based on their switch port-number so that the machines will get a consistent IP address based on their physical location in our cluster. The interface that this vlan is presented to the host is running as an MLAG. The Circuit ID gets correctly inserted as switchname:PortChannelxxx but which switchname will be sent is not clear. Any advice on how to make this configuration work reliably (we can only have one circuit ID in the DHCP configuration)? Should I only run dhcp snooping on one of the...
Continue reading →

VXLan, MLAG and duplicate ARP

We having an issue that we believe is related to receiving duplicate ARP requests. We’ve got nodes (part of openstack) connected to a pair of 7060 switches using MLAG, these 7060 switches then join a VXLan to connect to other pairs of 7060 switches where other nodes exist. The behaviour we’re seeing with ARP requests is that the broadcast is being flooded to the VTEP that is on both switches in the MLAG group, this is then being forwarded down both legs to the node, so the node sees the request twice. This seems to be confusing the OVS running...
Continue reading →

MSTP and MLAG Best Pratices

Hello folks, Following situation:– 2 datacenters– 2 spines per datacenter (short name: S1 & S2 in DC1, S3 & S4 in DC2)– multiple leafs per datacenter connected to both spines via bowtie MLAG– S1 & S2 forms MLAG pair, S3 & S4 forms MLAG pair– CWDM: S1 connected to S3, S2 connected to S4 (ring)– bowtie MLAG between MLAG pairs S1/S2 and S3/S4– MSTP with 1 MST instance What is the best practise for configuring MSTP root bridges?Configuring S1 as primary and S2-4 as secondary? Or S1 AND S2 as primary and S3+S4 as secondary?As far as I know, in...
Continue reading →

Follow

Get every new post on this blog delivered to your Inbox.

Join other followers: