Topology: MLAG

  • 19 October 2018
  • 10 replies
  • 382 views

Userlevel 3
Hey,

Can you validate that the following is a valid setup using MLAG.

Sites A and B contain two MLAG peers each.

There are two independent links between sites A and B, and in order to connect both sites, both peers can use MLAG at each end. (Each group of switches thinks that it is talking to one switch at the other end.)

This would make the two links active, thus double the bandwidth compared to STP which would always block one ISL. But I'm not sure about STP in this scenario.

I couldn't really validate nor not validate such a setup from reading the manual. Is it valid?

Anything that comes to mind about this?

Thanks.


10 replies

Userlevel 5
Hi jeronimo,

I've encountered this when visiting one of the customers.
From MLAG perspective, it will forward the traffic, but IMO you don't benefit MLAG here. It's like having failover scenario due to diagonal links (A1-B2, A2-B1) outage.
I'm not sure right now if the ISC blocking filters be disabled due to this.

With such four switches you can also think of different non-port-blocking mechanism, it could be EAPS or A and B stacks + LACP... Or perhaps you would like to play with MSTP and manipulating the bridge priorities for every MST instance so for each VLAN root bridge is different one, so all links are used. But that sounds like a lot to do. ;)
All depends on place in the network and your goals and constraints.

Kind regards,
Tomasz
Userlevel 7
Hi jeronimo,

the topology is valid. No link needs to be blocked with MLAG while STP, EAPS, or similar would need to block at least one (logical) link. You might want to consider adding cross-links (upper left to lower right, lower left to upper right) if possible to optimize redundancy and fail-over speed.

Please see the GTAC Knowledge site for additional info:
Thanks,
Erik
Userlevel 3
Ok, thanks. Now I am wondering indeed what would be the use of using MLAG here. As Tomasz claims, there's no real benefit here. What would you do? Use MLAG for those ISLs or simply treat them as single links and let STP handle them? Cross-links are not possible right now.
Userlevel 5
Ok, thanks. Now I am wondering indeed what would be the use of using MLAG here. As Tomasz claims, there's no real benefit here. What would you do? Use MLAG for those ISLs or simply treat them as single links and let STP handle them? Cross-links are not possible right now.
IMO single STP domain makes you benefit less as the link is blocked. MSTP might cover this issue, but more to configure. If those cross-links are not possible just for some time, perhaps you might leave it as is until it becomes full-blown MLAG (then there'll be not much to reconfigure). 🙂
Userlevel 7
Ok, thanks. Now I am wondering indeed what would be the use of using MLAG here. As Tomasz claims, there's no real benefit here. What would you do? Use MLAG for those ISLs or simply treat them as single links and let STP handle them? Cross-links are not possible right now.
The benefits are all links active and no extra protocol running.
Userlevel 3
Interesting this question came up - I was about to post about a near identical setup.

The benefit I see of this "back to back" MLAG is that both sides just see a LAG, so you have a true active-active situation for traffic in either direction. The alternative is EAPS or STP; which would work, and you could probably arrange multiple VLANs to get maximum use of both connections. But it is still more work and config compared to the MLAG example.

When I did some testing of this (well actually ended up deploying it with 2x X460G2s on one side, and 2x customer X440s on the other side), I was seeing some destination macs in the same L2 network that just didn't work. It had all the hallmarks of a situation where a LAG without LACP was unidirectional so a packet was hashed and sent down a link that just didn't work.

I can't see why this shouldn't work, and so long as you have LACP enabled (we do all remember to always enable LACP, don't we folks) you have a control protocol to deal with connectivity problems where the link may appear to still be up and avoid the blackhole situation I saw.

The "Two Tier MLAG design" topologically isn't quite the same as what we're describing here - it has the cross connections in place. Are they required to make this legal (I can imagine, given that I had packets going nowhere, that this would fix what I saw) - or should this "just work" with the simple two cables between two sets of switches setup?

Paul.
Userlevel 3
Interesting this question came up - I was about to post about a near identical setup.

The benefit I see of this "back to back" MLAG is that both sides just see a LAG, so you have a true active-active situation for traffic in either direction. The alternative is EAPS or STP; which would work, and you could probably arrange multiple VLANs to get maximum use of both connections. But it is still more work and config compared to the MLAG example.

When I did some testing of this (well actually ended up deploying it with 2x X460G2s on one side, and 2x customer X440s on the other side), I was seeing some destination macs in the same L2 network that just didn't work. It had all the hallmarks of a situation where a LAG without LACP was unidirectional so a packet was hashed and sent down a link that just didn't work.

I can't see why this shouldn't work, and so long as you have LACP enabled (we do all remember to always enable LACP, don't we folks) you have a control protocol to deal with connectivity problems where the link may appear to still be up and avoid the blackhole situation I saw.

The "Two Tier MLAG design" topologically isn't quite the same as what we're describing here - it has the cross connections in place. Are they required to make this legal (I can imagine, given that I had packets going nowhere, that this would fix what I saw) - or should this "just work" with the simple two cables between two sets of switches setup?

Paul.

I found using MLAG on both sides between switches quite a thought experiment, since you usually somehow associate MLAG with the "server"/"switch"-side and a port-channel/LAG with the "client"/host-side. In this scenario, MLAG is both...
Userlevel 7
Interesting this question came up - I was about to post about a near identical setup.

The benefit I see of this "back to back" MLAG is that both sides just see a LAG, so you have a true active-active situation for traffic in either direction. The alternative is EAPS or STP; which would work, and you could probably arrange multiple VLANs to get maximum use of both connections. But it is still more work and config compared to the MLAG example.

When I did some testing of this (well actually ended up deploying it with 2x X460G2s on one side, and 2x customer X440s on the other side), I was seeing some destination macs in the same L2 network that just didn't work. It had all the hallmarks of a situation where a LAG without LACP was unidirectional so a packet was hashed and sent down a link that just didn't work.

I can't see why this shouldn't work, and so long as you have LACP enabled (we do all remember to always enable LACP, don't we folks) you have a control protocol to deal with connectivity problems where the link may appear to still be up and avoid the blackhole situation I saw.

The "Two Tier MLAG design" topologically isn't quite the same as what we're describing here - it has the cross connections in place. Are they required to make this legal (I can imagine, given that I had packets going nowhere, that this would fix what I saw) - or should this "just work" with the simple two cables between two sets of switches setup?

Paul.

This two-tier-MLAG construct is used in quite a few EXOS based networks, because all links are active as opposed to blocking links with STP or EAPS.
Userlevel 7
Hi Paul,

the setup should work without the cross connections, we are using this exact setup in the network of the small company I work for (we are using older EXOS switches, not -G2, but this should still work). We have a switch pair on the office floor and another one in the basement connected via two-tier-MLAG using just two links.

Thanks,
Erik
Userlevel 3

The benefit I see of this "back to back" MLAG is that both sides just see a LAG, so you have a true active-active situation for traffic in either direction.

When I did some testing of this (well actually ended up deploying it with 2x X460G2s on one side, and 2x customer X440s on the other side), I was seeing some destination macs in the same L2 network that just didn't work. It had all the hallmarks of a situation where a LAG without LACP was unidirectional so a packet was hashed and sent down a link that just didn't work.

I can't see why this shouldn't work, and so long as you have LACP enabled (we do all remember to always enable LACP, don't we folks) you have a control protocol to deal with connectivity problems where the link may appear to still be up and avoid the blackhole situation I saw.

The "Two Tier MLAG design" topologically isn't quite the same as what we're describing here - it has the cross connections in place. Are they required to make this legal (I can imagine, given that I had packets going nowhere, that this would fix what I saw) - or should this "just work" with the simple two cables between two sets of switches setup?


Paul has a point. I was testing back-to-back MLAG topology concerning all kinds of link failures:
* direct: the simplest failure: the port goes physically down
* indirect: 1. there is something in-between that isn't passing data anymore, or 2. there is nothing in-between so something on the other side has died but the link is still up

Now the challenge is of course an indirect link failure. Like when you "pause" the link in GNS3, when the ports stay up but data isn't passing. Whether you implement the cross connections or not, I found that when I pause one of the links, some traffic starts getting blackholed. Probably because in back-to-back MLAG there is nothing like LACP which would watch the links (or loop-protect like in STP which stops using the link if there are no more BPDUs).

Reply