LACP configuration relapse

[JDaggett]

We have had an odd situation with Cisco 3750 edge switches attached to a Nortel 8600 core. The Nortel is running 4.1 software. We have done this successfully for years using legacy EtherChannel on the Cisco and basic MLT/SMLT on the 8600. The thing is that for this to work properly, the Cisco-side links need to be attached to the same physical switch. We wanted to split these uplinks between switches in a 3750 stack (Cisco calls it cross-stack EtherChannel) and according to Cisco the only way that they can support this is with LACP. So, this will be two LACP links on separate Cisco boxes running VLAN trunks to two different SMLT Nortel cores.

OK, so we set up LACP on both the Cisco side and the Nortel side. On the Nortel side LACP works a little differently than standard MLT. You don’t associate VLAN with the MLT, you just define VLAN on the ports and then they join the LACP/MLT via the LACP-key. The thing is that the LACP/MLT has a configuration default of “access” and you do need to tell it that it will be a trunk.

At first all this seemed to work, EXCEPT; sometimes (not all of the time) when one of the two LACP links is brought down and then reconnected, the Nortel side reverts the LACP link from a trunk definition to an access port definition. Yes, I am absolutely positive that we did a “save” on that trunk configuration. The problem is that this means that there is then a mismatch between the two MLT ports, they do not join the LACP-group properly and they end up creating a loop!

This is such a severe problem that for now we are just going to go back to legacy Etherchannel, simple MLT/SMLT and put both uplinks on one Cisco box. I am wondering, however, if anyone else has had similar issues and if there may be a fix out there for what seems like a major Nortel bug.

 

[lobk]

You have a copy of your SMLT/LACP config?

 

[andy88]

Have you created an mlt with the ports and added it to the lacp group?

Also is the lacp set to active?

 

[JDaggett]

LACP works a little differently than normal MLT. In normal MLT you add ports and VLAN to the MLT definition directly. With LACP, the VLAN set is defined exclusively on the ports and the MLT gets nothing but a designation as a trunk and the “LACP-key” definition (along with “aggregation enabled”, which makes it LACP). Then, when the port is activated, the LACP-key on the port gets matched to the LACP-key on the MLT, and the port “dynamically” joins the LACP-group. In our case this is also an SMLT between two 8600 with the MLT-ID, SMLT-ID and LACP-key being the same value all around to reduce confusion. This all works properly as described in the initial setup. We can bring up this LACP-managed MLT/SMLT across two 8600 and the edge device (also defined as LACP) activates properly. The LACP statistics show proper traffic and everything is 100% correct.

The problem is that later on, after everything is up and running, if a link goes down (say we unplug one for testing purposes), then the >saved< 8600 configuration reverts. The MLT still has “aggregation enabled”, the MLT still has the proper “LACP-key”, but the MLT “type” has been wrongly changed from the original “trunk” back to the default of “access”.

What this inappropriate configuration change means is that the port (where the VLANS are defined) can now no longer join the LACP-group properly because the port is a trunk and the MLT is now “access”. This means that when this link comes up, it forms a loop because it is no longer part of the MLT/SMLT managed by LACP, but rather an independent multi-VLAN link.