VSS + MEC -- dynamic clone of port-channel config?

Unanswered Question
Nov 23rd, 2009

Hi All,

Just doing some digging here, but can't find any reference to it in any of the docs.

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 a 3560 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

#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

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

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

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
spasquie Fri, 12/04/2009 - 17:14

Hi,

The Po1A/Po1B are LACP secondary aggregators (also know as lacp sub-channeling). This is a LACP behavior. So you won't see this with PAgP.

There could be several reasons leading to the creation of secondary aggregators, one of them being a small misconfiguration between some of the physical members of the port-channel.

In your case, if all the ports configured to be in Po1 are in Po1A (from show etherchannel summary), you can do a shut/no shut on the Po interface.

It will rebundle all the port in Po1.

Hope this helps,

Regards,

Samuel

Actions

This Discussion

Related Content