I have seen (very frequently) cloned A and B port-channels (debug calls them "secondary
aggregators" if i remember right) created on a 6500 after reloading the peer router
(C10k). Quite annoying, since the cloned interface is a new interface and snmp counters do
not work anymore (neither our eem scripts) .
According to tac, this is expected behavior for LACP if there is a misconfiguration
(typically when two links of the same channel are attempted to be connected on two
different devices on the remote end, like in this case, VSS/MEC) on the moment of the
channel bundling. But in my case it was something else and tac couldn't find the root cause.
--
Tassos
Kevin Graham wrote on 24/11/2009 21:03:
[...taking this from nanog to c-nsp...]
Essentially, for all of the MEC connections, the VSS has created a clone
of the configured port-channel to bind the actual physical connections,
rather than binding them under the configured port-channel (and suffixed
the port-channel number with A or B depending on which chassis was first
to bind).
I believe this is an LACP artifact; speculation, but when the port-channel
is first formed, the far-end aggregator is saved. If the channel is
re-formed with a new aggregator, the channel is "cloned" like this.
I've only tripped across this on standalone 6500's when bringing up new
LACP bundles; destroying and recreating them worked fine (though as you
noticed, there's no functional impact from a "cloned" Po interface, just
cosmetic).
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
