[c-nsp] OT: VSS + MEC - port-channel dynamically cloned?

[Tassos Chatzithomaoglou]

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  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>