The first is using MLAG - which is the approach I've adopted in another network:

The design entails four cores, two in different locations using MLAG (two locations shown by dotted red line)

All four cores have a common VRRP VRID 100 and common VLANs shared between them

Each pair of cores have their own VRRP VRID 10 & 20 for only VLANs in those areas

Fabric routing mode is enabled on all VLANs

OSPF is enabled on all VLANs as passive. Except /30 between each MLAG pair i.e cores in VRID 10 have a /30 between them as does the cores in VRID 20.

OSPF is configured for broadcast and using a /29 address running between and joining each of the cores together at layer 3, although they run on top of a single lag.

The second option is using stacking. The design is a lot simpler, and that appeal alone might a draw many using it, but I have kept to the habit of keeping stacking out of any large core / data centre.

As you can see it offers exactly the same as above but just tilted around. You can do inline upgrades in both examples as each link is diversely connected.

So these are my arguments for each, but I'm interest in all pro's and con's the community could come up with both

MLAG Approach - although more complex....

It offers the best (by a fair margin) the most optimal approach

Traffic is more evenly distrbuted to each of the switches

Each switch is independently able for forward / route traffic with out passing to a master switch

I can better control traffic distribution across links via lag hashing algorithms

I can simply bundle more links into the lag to increase bandwidth

Can offer a more economical approach by using more cost effective links and simply adding more as and when required

The approach offers more stability over stacking failures

This approach seems more logical for switches that are more geographically separate i.e across the red line. Although possible with V-Stacking its probably not a good idea to have stacks joined so fair apart.

Stacking

Configuration is a lot simpler and easier to manage

Possibly easier to add more switches to core by adding more to the stack, but this is perhaps not a good idea. MLAG design you can just lag to another switch

1 reply

Stacking and MLAGing are more complimentary than they are comparable technologies in my opinion.

Stacking tries to provide the degree of simplified management and resilience a chassis would offer without the cost + rigidity/planning that comes with deciding what type of chassis would fit your needs. On the other hand, MLAGing tries to address the limitations that come with a traditional implementation like STP. Both provide redundandy, but for stacking that is secondary to the fact that stacking came about to increase port density while siplifying management.

The same way you can add more links to an MLAG, you can do the same with Stacking. The same way an ASIC on an MLAG peer would forward a known traffic stream in hardware, a stack member can.

If I may, I don't think stack members should be geographically spaced, even if you have the bandwidth for it. And yes, entire stacks do fail. But if you do find yourself wanting to do that, it would be the best time to think about deploying a 2 tier MLAG. Peering is local, so no check-pointing traffic traverses the links connecting the two locations, and if an entire path fails, you still have your back-up.

For even added resilience, your 2 MLAG peers can be Summit Stacks, which gives the best of both worlds. Ultimately, it all comes down to what you're trying to do and how much room you have to go crazy with ideas