OT: VSS + MEC - port-channel dynamically cloned?
Hi all.. this one seems to have stumped even the community forums on CCO ;) Anyone else seen this behaviour? (It's not actually a problem as such since the MEC port-channels are actually working fine, just unexpected the way that it has done it...) We have a few paris of VSS running, and having brought the down-stream access-switches online using MEC we note that the active port-channel that they bind under isn't actually the one configured, but rather a CLONE of the configured one which appears to be dynamically generated. In our case, all ports and port-channel configurations are set to dot1q encapsulation and trunk mode active. For example, we have about 20 3560s MEC'd to the VSS: the MEC comes up, but under a slightly different port-channel identifier: Here's the 3560 side: interface status: Gi0/49 connected trunk a-full a-1000 1000BaseSX SFP Gi0/50 connected trunk a-full a-1000 1000BaseSX SFP Gi0/51 connected trunk a-full a-1000 1000BaseSX SFP Gi0/52 connected trunk a-full a-1000 1000BaseSX SFP #sh int po1 | i Member Members in this channel: Gi0/49 Gi0/50 Gi0/51 Gi0/52 Here's the VSS side: Interface status: Po11 CISCO C3560 A01 notconnect 1 auto auto Po11A connected trunk a-full a-1000 ^^^^ Po11A is not actually configured, but appears to be cloned from Po11 #sh int po11A | i Member Members in this channel: Gi1/1/33 Gi1/1/34 Gi2/1/41 Gi2/1/42 #sh cdp nei | i hacc01-d hacc01-d Gig 2/1/42 140 S I WS-C3560G Gig 0/50 hacc01-d Gig 2/1/41 140 S I WS-C3560G Gig 0/49 hacc01-d Gig 1/1/34 161 S I WS-C3560G Gig 0/52 hacc01-d Gig 1/1/33 161 S | WS-C3560G Gig 0/51 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). Config for port-channel and interfaces all match: VSS SIDE: interface Port-channel11 description CISCO C3560 A01 switchport switchport trunk encapsulation dot1q switchport trunk allowed vlan 40-48,51,400 switchport mode trunk mtu 9216 end Physical ports are the same config, with channel-group 11 mode active (and repeated for 20 different port-channels each with 4 ports) ACCESS Side: interface Port-channel1 description DIST-VSS-EQX1 switchport switchport trunk encapsulation dot1q switchport trunk allowed vlan 40-48,51,400 switchport mode trunk mtu 9216 end Similarly, physical ports are the same with channel-group 1 mode active I'm not overly worried about it since the MEC is working with the dynamically generated port-channel, and traffic is flowing correctly... just curious as to why it uses a clone of the configured port-channel, rather than the actual configured port-channel itself. Just find that a bit strange. Thanks, Leland
On Tue, Nov 24, 2009 at 07:51:29AM +0100, Leland Vandervort wrote:
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).
IOS does this when ethernet channel members cannot join the bundle due to negotiation mismatch. If the currently active elements are incompatible with a new element, the A/B interfaces are created. These are called "secondary aggregators" in IOS-speak. http://www.cisco.com/en/US/tech/tk389/tk213/technologies_configuration_examp... -- Ross Vandegrift ross@kallisti.us "If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher." --Woody Guthrie
Thanks Ross, In this case, though I cannot see where the mismatch is given that the encapsulation, trunking (vlans allowed, etc.) and channel mode (LACP) are all configured identically across all ports and the channel itself. Just wondering if it's a left-over from before the VSS migration when the original trunks were two separate etherchannels and then migrated them "live" to MEC... L. On Tue, 2009-11-24 at 13:57 -0500, Ross Vandegrift wrote:
On Tue, Nov 24, 2009 at 07:51:29AM +0100, Leland Vandervort wrote:
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).
IOS does this when ethernet channel members cannot join the bundle due to negotiation mismatch. If the currently active elements are incompatible with a new element, the A/B interfaces are created. These are called "secondary aggregators" in IOS-speak.
http://www.cisco.com/en/US/tech/tk389/tk213/technologies_configuration_examp...
On Tue, Nov 24, 2009 at 10:19:33PM +0100, Leland Vandervort wrote:
In this case, though I cannot see where the mismatch is given that the encapsulation, trunking (vlans allowed, etc.) and channel mode (LACP) are all configured identically across all ports and the channel itself.
Just wondering if it's a left-over from before the VSS migration when the original trunks were two separate etherchannels and then migrated them "live" to MEC...
Check flow control between all of the elements. The only time I've seen this was inconsistent flow control settings between different media types on an F5 BIG-IP <-> 6500 bundle. show interfaces flowcontrol Ross -- Ross Vandegrift ross@kallisti.us "If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher." --Woody Guthrie
participants (2)
-
Leland Vandervort
-
Ross Vandegrift