OT: VSS + MEC - port-channel dynamically cloned?

Mailman List Mirror (Read Only)
1

Hi all.. this one seems to have stumped even the community forums on
CCO :wink: 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

2

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_example09186a0080094470.shtml#po1a

3

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.

4

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