Is MLAG an Alternative to Stackable Switches?
Alex was trying to figure out how to use Catalyst 3850 switches and sent me this question:
Is MLAG an alternative to use rather than physically creating a switch stack?
Let’s start with some terminology.
Link Aggregation Group (LAG) is the ability to bond multiple Ethernet links into a single virtual link. LAG (as defined in 802.1ax standard) can be used between a pair of adjacent nodes. While that’s good enough if you need more bandwidth it doesn’t help if you want to increase redundancy of your solution by connecting your edge device to two switches while using all uplinks and avoiding the shortcomings of STP. Sounds a bit like trying to keep the cake while eating it.
Enter the magical world of MLAG (Multichassis LAG) – the ability to present two or more physical boxes (members of MLAG cluster) as a single logical device from LACP perspective.
Most MLAG implementations (apart from those based on ICCP or EVPN) are totally proprietary, and vendors use numerous tricks to get the job done. Some use central control plane with all other devices acting as stupid packet forwarders (aka SDN or stackable switches), in which case they're sort-of still running traditional LAG/LACP. Others use traditional distributed control plane with additional control-plane protocols between MLAG cluster members.
Long story short: stackable switches implement MLAG with centralized control plane.
To make matters even more confusing, vendors use different names for their MLAG implementations. Cisco vPC, Cisco VSS, HP IRF, Arista MLAG… do more-or-less the same thing from the perspective of an edge device.
To further confuse the innocent, some vendors call centralized control plane stacking, while getting the same results with the distributed control plane is called MLAG. Go figure.
Want to know more?
MLAG is covered in numerous webinars:
- Some basics are covered in Data Center 3.0 webinar;
- You’ll find more details in Data Center Fabric Architectures where you’ll also find a discussion of control plane architectures;
- Standard way of implementing MLAG with EVPN is described in EVPN Technical Deep Dive webinar.
- I think I have the “SDN = stackable switches” pun in the SDN 101 webinar.
All these webinars are available with standard ipSpace.net webinar subscription. SDN101 webinar is also available with free subscription.
Need more than just technology discussion?
- Want to get fluent with data center fabrics? Check out the Designing and Building Data Center Fabrics online course.
- Want to master all aspects of data center infrastructure while still remaining focused on networking infrastructure? It’s time for Building Next-Generation Data Center online course.
"Why not deleting my inconvenient comment?"
I understand that everyone has their unique way of sharing their experience and accumulated wisdom, and giving back to the community that helped them grow. If this is the best way for you to create value, who am I to stop that?
If you intend to connect hosts with mlag as a redundancy measure, an mlag with a shared control place device that you can't do maintenance on individual devices like a 3850 stack is pointless and wasteful as you'll need to reboot the whole stack to upgrade. Mlag on a 3850 stack is only useful as a mean to augment available bandwidth. VSS is slightly better but not much.
VPC on nx-os is better in that regard; control plane of the switches stay distinct and you can generally do maintenance including upgrades on one switch at a time while keeping one side of the mlag up all the time.
Also, we don't do dual homed FEXs; dual home fexs, as you state, lead to awful and useless complexity and brittleness. We dual home (lacp as much as possible) all our servers/hosts to single homed fex pairs. As so we have a fairly plain topo that is resilient both for outages and maintenance and provides all active links... and thanks to the stability (or lack thereof...) of nx-is code (built in caps monkey as I call it) we get to test loss of a switch regularly without impact to the service (only the server admins notice they temporaires lost a server uplink)
It is however perfectly feasible to design & build a L3-only fabric, including redundant ToR/leaf switches and end host connectivity.
You can obfuscate the answer even more if you get into talking about chassis devices (i.e. Cisco 4500/6500/6800/9300, etc) that support multiple management cards (supervisor engines, route processors, what have you) and multiple interface line cards all within one chassis.