MLAG vs Stack what am i missing

[Chris_Chance]

Can't seem to wrap my head around the reason for using MLAG vs Stacking, I'm planning to use 2 x670's as a 10gigabit aggregation hub for our remote sites, but i want redundancy, so the idea was run 1 fiber to each of the x670's and run mlag so if 1 x670 fails, tada still up and working... But then i got to thinking if i stack those 2 x670's and use a standard lag group from 1:1 and 2:1 to the remote site, isn't it IDENTICAL, but i get the benefit of not dealing with the mlag, not having to deal with managing 2 core switches, and still keep the same load balancing, same redundancy, same resilience and high availability? I feel like theirs got to be something here I'm missing

[Bill_Stritzinge]

The sending switch determines the distribution based on the hash selected. What are switches lags configured for? Have you tried changing the has to see if you can get get better distribution? What is the makeup of the traffic?

Bill

[eyeV]

Hi, everybody!

I've got a classic MLAG topology like Daniel posted.

I've shutdown port between top router and one of the MLAG switches for some reasone. So... I see strange situation. All bottom S switches tend to send more traffic to X1 switch. Why?

It would be great if someone suggest something.

[cbuchenau]

Great thread & comments, thanks guys!

I have 2 additional thoughts:

1) Dual-homed: Any device connected to the MLAG enabled switches must be dual-homed aka connected to both switches. Taking Daniel's image from just above, that server on the right hand side must not be connected to only one of the 2 switches if they were not stacked but in an MLAG relationship. Otherwise, use a stack.

2) Bigger picture: All examples above are very simple. I believe MLAG gets really interesting when we have a 2-tier environment and more. We are currently working on a 2-Datacenter setup with 2 Cores in each, and several ToR combos (always 2 per rack) behind the Cores. Configuring at least the Cores as MLAG, and possibly the ToRs, prevents us from using Spanning Tree plus gives us the feature of 0-downtime firmware upgrades - and we can still configure each Core as individual router / VRRP instance.

Hope that makes sense....

[Stephane_Grosj1]

It is worth to note that on certain platform and exos version, you can also do a port-based LAG, meaning you can have a local port used in a stack.

[dflouret]

For those of you familiar with EOS, a similar problem can be found in VSB (Virtual Switch Bonding), the virtual "stacking" functionality available in S-Series, K-Series and 7100 Series switches.

EOS allows the management of user traffic accross bonding ports (the equivalent to the stacking ports) with the command
set lacp outportLocalPreference [none | weak | strong | all-local]
to encourage a chassis-bonded switch to use local egress ports on a LAG, where
None = Do not prefer LAG ports based on chasis
Weak = Use a weak preference towards ports on the local chassis
Strong = Use a strong preference towards ports on the local chassis
All-local = Force all packets onto local chassis ports, if possible