MLAG Testing in Campus EXOS S&R [Lab 6 Section D]

[Tomasz]

Hello everyone,

Yesterday I had some late hour struggle with MLAG lab and some student. Maybe it was lack of coffee but this time I got confused and would like to get this straight to make no room for future confusions.

MLAG lab design assumes PC-A and PC-D pings running between Switch-A/Switch-B as MLAG peers and Core-A as a downstream device. Pings are likely running through MLAG peers directly, ommiting Core-A. In Lab 6, Section D, step 5 we are asked to disable both ISC ports. This literally breaks MLAG peering. Step note says that pings may or may not keep going uninterrupted, but my two students I had a discussion with, had pings not going at all. I done some troubleshooting with port statistics and fdb and what were my findings:

• I was pretty sure MLAG will break when ISC is broken, and that peers will present themselves with just their own MAC addresses to a downstream Core-A again, making Core-A able to establish LACP only to one of the devices (cannot create standard LACP with two different partners on the other side, that’s why we have MLAG actually). However…
• However it didn’t happen that way, although show mlag commands could show things are bad, Core-A still considered LACP link as fully operational.

In both situations, pings are IMHO unable to pass through between PC-A/SW-A/C-A/SW-B/PC-D. In the first situation, Core-A should consider one of the ports not valid for LACP link establishment and thus could only communicate with either Switch-A or Switch-B, path between PCs would be incomplete. In the situation I had, when Core-A received ICMP request from PC-A through Switch-A, it could even do broadcasts, it would not go up to Switch-B as LACP considers that a single link and there is no way to receive a frame from LAG and put it back into LAG normally. And that’s what I could see, on Switch-B there was no incoming transmission from Core-A during ping attempts.

To overcome this I presented troubleshooting and explained that indeed ISC is crucial for MLAG operation, and showed them a bit different scenario where PC-A pings Core-A and we break one of the uplinks to see the failover happens thanks to MLAG and operational ISC.

I’d really appreciate some comments to make sure where am I wrong, or if my conclusions are correct, I’d recommend adjusting step 5 to ping Core-A (172.16.x1.1) from PC-A instead, and disable port 1 on (most likely) Switch-A instead. It resembles more “natural” use case where we have a downstream device dual-homed for its network access redundancy, and that this downstream device shouldn’t IMHO be considered a failover path for horizontal network traffic.

Thanks,

Tomasz

[Tomasz]

Hi Piotr,

Thanks!

Indeed, it is not able for pings to “run without interruption” “depending on the load sharing (...)”. I don’t mind having a step that proves the importance of ISC, but then these phrases might be a bit inaccurate. And if I’d like to show MLAG failover scenario I’d recommend to add another step to ping PC-A → Core-A and disable port 1 on relevant switch.

I think now I undersand, peers consider each other as down (reminds me of VRRP dual-master) and what they do is not actually moving back to normal operation but just taking down the ISC blocking filters for BUM traffic. I don’t know why I thought yesterday that MLAG might break totally, I was probably too low on caffeine.

Cheers,

Tomasz

[Piotr_Owczarek]

Tomek, 

IMHO that point : “In Lab 6, Section D, step 5 we are asked to disable both ISC ports” is just to prove how important ISC connection is. I have likewise experience - it will newer work with ISC port disabled. So every time on EXOS training I try to explain that part of lab in such way. 

Piotr