MLAG+1Uplink router +ebgp

Hi Gab,

The design you’re proposing will work (vEOS-Lab has some limitations around MLAG dataplane last I checked), but may not be ideal in the event of a flow hashing to the ‘wrong’ device, where it will traverse the peer-link. What we generally recommend instead is utilizing two routed links for BGP peering.

Something like below, utilizing /31 routed links instead of an MLAG port-channel.
A: 192.0.2.0/31 - Router[192.0.2.0]; MLAGA[192.0.2.1]
B: 192.0.2.2/31 - Router[192.0.2.2]; MLAGA[192.0.2.3]

This would allow you to have cleaner BGP peering between the MLAG pair and the router.

Depending on traffic load and if any traffic needs to be routed via the MLAG device IP over the port-channel, your idea would probably be fine. I’d still recommend you reach out to your SE to discuss options specific to your design.

Hello!

Yes, you need the VLAN allowed on the peer-link. This is because the packets egressing out the port-channel on the upstream router can hash to either MLAG peer. As an example, if it picks SW1 as the next-hop, the DMAC of the packet will be SW1-DMAC. If this traffic hashes to SW2 (on account of LAG hashing), the traffic will get back-holed on SW2 since the VLAN is not allowed on the peer-link. So, you need the VLAN on the peer-link.

Couple of recommendations:

1. When using SVIs for peering, consider using an outbound route-map on the MLAG’ed switches to set next-hop to vIP. This is to avoid sub-optimal forwarding and MLAG peer-link utilization.

2. Using point-to-point routed links would be a better option to run eBGP and avoid using SVIs. You don’t need the route map described by [1] in this case.

Cheers
Naveen

Hi

thank you both for your replies. So the mlag multi-homed vlans should always be extended through the peerlink in order to avoid a back-hole scenario, right?. well it seems that the best approach for this setup is to set up a traditional interconnection layout in winch each Arista will run an eBGP sessions via a p2p L3 subnet towards the uplink router, ibgp on the interlink. this means the Uplink router has not a port channel towards the arista switches, right? meaning as well no mlag between arista switches and uplink router,right? if so, does this mean we can no longer setup a mlag between both arista and the uplink in the near future? could both setups live together trough the same physical links?

Best

Hi Gab,

[1] Along the lines of my previous example, assume both MLAG peers SW1 and SW2 advertise their connected networks to the upstream router. From the router end, these networks will be seen as a two-way ECMP with next hops as SW1 and SW2. For the traffic coming from the upstream router towards the host that lives behind the MLAG pair: If these packets hash to the “wrong” switch, they will end up getting bridged via the peer-link before it gets routed to the destination.

There’s two levels of hashing for all the routed packets – ECMP followed by LAG hash:
(1) ECMP hash to pick the next hop and this determines the DMAC of the packet
(2) LAG hash which determines the physical link that’s chosen to forward the packet

You’ll see an extra hop (sub-optimal) via the peer-link for all the packets whose ECMP and LAG hashes pick different switches. In such cases, the data path will be:

[Upstream Router] (Route) –> [SW1 or SW2] (Bridge) –> [SW2 or SW1] (Route) –> [Host]

You can avoid this by configuring a VARP vIP in the VLAN that’s used for eBGP peering and using an outbound route-map with “set ip next-hop “.

[2] With routed links, you break the port-channel and you can no longer use the links as L2 for passing other VLANs. As Tyler mentioned, we recommend getting in touch with your SE to discuss the design options for your use case.

Cheers
Naveen