When MLAG Is Good Enough
March 07, 2011
I recall having a discussion with Juniper several months ago about MLAG and why only two core switches. They indicated they were working on a set of features that would have more than two core switches. 20/20 hindsight being what it is, it seems that they were floating what is now known as QFabric, which seems to be dual core only but that might change by the time the interconnect ships in Q3. As an aside, I was talking to a network equipment engineer shortly thereafter (I honestly forget who) about MLAG and why only dual cores and mentioned another vendor was claiming more than two core switches. His response was something like "Good luck with that. Maintaining a coherent state between two devices in sub-microsecond time between more than two nodes is extremely hard to do well."
MLAG inherits many of the same traits of LAG in that all frames in a flow are sent over the same physical link; some algorithm determines how flows get sent to particular links, frame order is maintained and duplication is avoided. The number of switches (I am avoiding the politically hot term "hops") that are traversed between two devices, like a server and NAS, remain the same so delay should be equivalent regardless of the path taken.
The point at which you have to look at TRILL or SPB or some other method to route Ethernet (sorry, I don't know how else to describe it) is:
- When the number of access port needs exceeds your vendors MLAG capacity and you need to add an additional core switch that doesn't not participate in the MLAG
- When you want to run a multi-vendor network with one vendor's switches at the access layer and anothers in the core
- When you want to run different switch product lines from a single vendor, where one product like Brocades 8000, Cisco's Catalyst, or Junipers EX switches can't participate in the fabric, or
- When you want a mesh network.