Hi, i have a pair of N9K-C93180YC-EX running nxos.9.3.1.bin connected with a LACP port-channel (pair of 100G Links). I got a pair of N9K-C9348GC-FXP running nxos.9.3.5.bin connect with a (single-100G Link) LACP post-channel to only one of the above switches.
I finally got more transceivers to create the missing redundant link(s) to the other one of the first switches , In a second LACP port-channel with just one single-100G Link. No Multi-Chassis LACP here, each device works stand-alone, spanning tree mode is MST, everywhere identically configured. Expected behaviour is: New link gets active, and if spanning tree finds this new link as "lower" it would block it. if spanning tree finds it "better" it should start to use it and block somewhere else. But monitoring was crying, and I found in the loggin: 16:30:19 dsw2 %L2FM-2-L2FM_MAC_FLAP_DISABLE_LEARN: Disabling learning in vlan XXX for 120s due to too many mac moves 16:32:19 dsw2 %L2FM-2-L2FM_MAC_FLAP_RE_ENABLE_LEARN: Re-enabling learning in vlan XXX Yes, that was also the duration of the "outage", adding a redundant link leads two two minutes outage ☹ Cisco's error-messages finder tells me that there is nothing to do ?!? Case opened, infos submitted, but two days (plus weekend) silence. Any idea what is happening and how I can avoid that (the fourth link wants to be plugged in). Will that happen when a link fails, STP unblocks an other link and therefor the switch relearns too much mac-addresses too fast so I get again 2 minutes "down" instead of just 2..3 seconds ? The ancient C4900M did not show that behaviour... Any suggestions? Thank you for your patience, Jürgen. _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
