cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3133
Views
0
Helpful
2
Replies

Port-channel changes name on 6509-E switch

weiler
Level 1
Level 1

Greetings all!

I'm hoping someone can shed some light on this odd behavior I'm seeing on one of our switches. It's a 6509-E with IOS Version 12.2(33)SXH2a. Basically I configured a LACP port bundle with 4 ports. This is the switch config (LACP relevant):

port-channel load-balance src-dst-mac

interface Port-channel1

description solaris-bundle

switchport

switchport access vlan 101

switchport mode access

spanning-tree portfast

and each of the 4 ports looks like this:

interface GigabitEthernet4/3

description solaris-bundle

switchport

switchport access vlan 101

switchport mode access

channel-protocol lacp

channel-group 1 mode active

spanning-tree portfast

!

interface GigabitEthernet4/4

description solaris-bundle

switchport

switchport access vlan 101

switchport mode access

channel-protocol lacp

channel-group 1 mode active

spanning-tree portfast

!

interface GigabitEthernet4/5

description solaris-bundle

switchport

switchport access vlan 101

switchport mode access

channel-protocol lacp

channel-group 1 mode active

spanning-tree portfast

!

interface GigabitEthernet4/6

description solaris-bundle

switchport

switchport access vlan 101

switchport mode access

channel-protocol lacp

channel-group 1 mode active

spanning-tree portfast

So far so good. I configured an OpenSolaris box for LACP as well with its 4 interfaces. I have the 'load-balancing policy' on the Solaris box set as "Layer 2 load-balancing". I set the LACP mode as "active" on the Solaris box. Then I plugged the four cables into the switch, and issues a 'no shutdown' on the port-channel1 interface. It connected just fine, and I could send 2+Gb/s through the port bundle. Life was good.

Then, later, I rebooted the Solaris box. Once it came up, the port bundle was working again, HOWEVER, the switch showed that the interface registered as interface Po1A instead of Po1. This is a bummer since I'm watching each interface with SNMP and when the interface changes names it throws off my monitoring software.

To fix it I issue a 'shutdown' on the port-channel interface on the switch, then a 'no-shutdown'. Then the interface correctly identifies itself as Po1 again. Any ideas on why it switches to Po1A whenever I reboot the Solaris box? Note that it works fine either way, I just don't want it to change to Po1A during a reboot.

Thanks for any insight!

-erich

2 Replies 2

Pronoy Dasgupta
Cisco Employee
Cisco Employee

Hello Erich

This behavior is basically a spawned etherchannel, LACP can spawn a secondary portchannel when there is an incompatible port config, this can only happen in LACP and it's usually with a misconfiguration of the

etherchannel, You will need to bring this po13 down and recreate it on both

sides.

This is normal operation of the LACP, it will happen when LACP protocol detects some inconsistency as per the IEEE 802.3ad standard. Most definitely this should not impact anything in the network, but in our case the SNMP is being thrown off track due to the name change, due to the Solaris box being rebooted.

The port channel created a spawn port channel .The LACP etherchannels is functioning correctly as a spawn but to get rid of it,I suggest to schedule a down time and take down the port channel and recreate both sides and make sure the configuration is the same in both sides.

Basically to say, LACP can spawn a secondary portchannel when there is an incompatible port

config.

The above is the normal explanation. Have you tried removing the port channel and recreating it again. I suggest you do it during downtime.

Thanks and Regards

Pronoy

Hi Pronoy,

Thanks for replying! I tried re-creating the port channel on both sides and it still doesn't work - when the Solaris box reboots, the Po1A interface is created, and I have to "shutdown/no shutdown" the Po1 interface for Po1A to go away and for Po1 to become the active interface. I did look in the switch logs and see this when the Solaris box reboots:

7w4d: %EC-SP-5-CANNOT_BUNDLE_LACP: Gi4/3 is not compatible with aggregators in channel 1 and cannot attach to them (flow control send of Gi4/3 is on, Gi4/6 is off)

Now, flow control is configured exactly the same on the switch ports (gi4/3 and gi4/6), nothing different there:

switch#sh interfaces gi4/3

GigabitEthernet4/3 is up, line protocol is up (connected)

Hardware is C6k 1000Mb 802.3, address is 001d.701f.abaa (bia 001d.701f.abaa)

Description: lilhive-bundle

MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation ARPA, loopback not set

Keepalive set (10 sec)

Full-duplex, 1000Mb/s, media type is 10/100/1000BaseT

input flow-control is off, output flow-control is on

Clock mode is auto

ARP type: ARPA, ARP Timeout 04:00:00

Last input never, output 00:00:26, output hang never

Last clearing of "show interface" counters never

Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: fifo

Output queue: 0/40 (size/max)

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

1634234643 packets input, 106775282829 bytes, 0 no buffer

Received 47909 broadcasts (43208 multicasts)

0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored

0 watchdog, 0 multicast, 0 pause input

0 input packets with dribble condition detected

6075102551 packets output, 9014665179551 bytes, 0 underruns

0 output errors, 0 collisions, 21 interface resets

0 babbles, 0 late collision, 0 deferred

0 lost carrier, 0 no carrier, 0 PAUSE output

0 output buffer failures, 0 output buffers swapped out

be-213cbse-6509-s1#

gi4/6 looks exactly the same...

I checked on the Solaris host too and it says that all ports are configured the same with regard to flow control:

root@myserver:~# dladm show-ether

LINK PTYPE STATE AUTO SPEED-DUPLEX PAUSE

nge0 current up yes 1G-f tx

nge1 current up yes 1G-f tx

nge2 current up yes 1G-f tx

nge3 current up yes 1G-f tx

root@myserver:~#

The "PAUSE" field shows flow control - so all ports are in 'tx' mode on the host side which indicates the end-point can transmit pause frames.

Just as a side note - both sides (Solaris box and switch) are in LACP mode 'active', LACP timeout mode is "long" on both sides and they both are in Layer2 load balancing mode (src-dst-mac). I tried it with the port channel on the Cisco side in "spanning-tree portfast" mode and also in "no spanning-tree portfast" mode and it behaved the same either way....

-erich

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: