port channel error disables if 1 link incorrect

[jmcgrady1]

I have a 2 link portchannel between a clustered pair of c9500 and a c3850.  The config is simple enough, each end has the aggregate interface defined:

interface Port-Channel1
switchport mode trunk

Member interfaces are defined like:

interface TenGigabitEthernet1/0/9
switchport mode trunk
channel-group 1 mode on

In normal operation this is fine. However, if one end of one link is connected to a switch port other than the intended, or the interface is misconfigured, the whole port channel error disables. Even though the other link is fine. Is there config i can add to make the setup more robust? I dont want the PO to error disable for any reason. If one link is good, it should not care what happens to the other link.

[MHM Cisco World]

channel-group 1 mode on

Change mode from on to active

On meaning no lacp message exchange.

[Leo Laohoo]

The Etherchannel could not have been the one to go "down".  It is more likely to be both links were in disabled or error-disabled.  And since there is no other link that is "up", the Etherchannel will go "down" but not error-disabled.  

[jmcgrady1]

I managed to repeat the behaviour on a bench setup. I have the two switches working as intended. PO is reporting as healthy with both member links working. If i then unplug one link from one switch and move it to a port configured as 'no switchport' with ip address defined - ie; a layer 3 interface - the port channel goes down. It goes down even though the other member link is fine.

[MHM Cisco World · Accepted solution]

check the STP when the PO is err-disable 
the PO is err-disable because of L2 Loop 
check this link 

https://www.dasblinkenlichten.com/port-channel-loops/

and as I mention above try active mode 

[Jitendra Kumar]

Resolution

The port status may become errdisable because of an EtherChannel misconfiguration.

The errdisable status indicates that the port was automatically disabled by the switch operating system software because of an error condition encountered on the port.

To determine if a port is in errdisable status, issue the show port command. For example, to check the status on port 3/2, issue the show port 3/2 command.

This is a sample:

Cat5500> (enable) show port 3/2
Port  Name               Status     Vlan       Level  Duplex Speed Type
----- ------------------ ---------- ---------- ------ ------ ----- ------------
3/2                      errdisable 1          normal   auto  auto 10/100BaseTX

The switch will send a message to the console describing why the port was disabled when it puts a port in the errdisable state. If syslog is configured, the message will be available on the syslog server as well.

Another way to determine the reason for the errdisable status is to issue the show errdisable-timeout command. This command is available in CatOS 5.4(1) or later. Sample command output is below.

Cat5500> (enable) show errdisable-timeout
ErrDisable Reason   Timeout Status
------------------- --------------
bpdu-guard          disable
channel-misconfig   enable
duplex-mismatch     disable
udld                disable
other               disable

Interval: 30 seconds

Port    ErrDisable Reason
----    -----------------
3/2     channel-misconfig
3/3     channel-misconfig

If EtherChannel is misconfigured between two switches, ports may become errdisable.

Check the EtherChannel configuration on both switches. If one side is configured for EtherChannel in the On mode, the peer ports must also be in On mode or they will go to errdisable.

The On mode of EtherChannel does not send Port Aggregation Protocol (PAgP) packets to negotiate with the other side before channeling. It assumes the other side is channeling. If the other side is not channeling, the Spanning-Tree Protocol (STP) detects a loop and places the channeling ports into errdisable status.

These are valid settings for Etherchannel to work properly:

• on-on
• desirable-desirable
• desirable-auto
• If both sides are set to auto the channel will not come up.    
• Verify that all ports in the channel have the same speed and duplex settings

For additional information regarding EtherChannel configuration, refer to EtherChannel Configuration Guidelines and Restrictions.

Once the cause of the errdisable status is found and corrected, re-enable the port by issuing the set port enable command.

For example, to re-enable ports 3/2-3, issue the set port enable 3/2-3 command. If the set port enable command is issued without the cause of the errdisable status being corrected, the port eventually goes back to the errdisable status.

For more information on the errdisable port status, refer to Recovering From errDisable Port State on the CatOS

https://community.cisco.com/t5/networking-knowledge-base/port-status-is-errdisable-due-to-etherchannel-misconfiguration/ta-p/3131226#:~:text=The%20errdisable%20status%20indicates%20that,issue%20the%20show%20port%20command.

[paul driver]

Hello

---

@jmcgrady1 wrote:

In normal operation this is fine. However, if one end of one link is connected to a switch port other than the intended, or the interface is misconfigured,

---

I do not understand the above statement, if the PC is working normally how can you mistakenly then attach one end to another interface?
Also when it is working "Normally" do you see both ports established in the port channel?

sh etherchannel summary
sh etherchannel  1 detail

[David Ruess]

Hello,

A couple things.

1. You're using "On" mode which means it's not negotiating any protocol and is just on. When using this configuration the other side must be set to On as well. So when a link fails (connected to another non-portchannel port) and there is no negotiation its likely not smart enough to figure out how to recover from a link failure. As @Jitendra Kumar mentioned Etherchannel misconfiguration guard could be the cause of putting the whole Port-Channel in a down state if one link fails. 

2. If you try LACP configuration to establish ports do you get the same result? I think you might have better luck as with LACP it negotiates the protocol and can work around some link failures.

Also as @paul driver said if its working why would it be mistakenly connected to something else? This would be my first concern if Port-channel ports are constantly being unplugged and plugged into other things. 

Hope that help

-David

[jmcgrady1]

---

@David Ruess wrote:

Also as @paul driver said if its working why would it be mistakenly connected to something else

---

In this instance, the port channel must stay up even if one of the two links is disconnected or patched into an incorrect switch port. It is a scenario that i am required to cater for. 

Being Cisco to Cisco, would using 'desirable' have the same negotiating ability as using 'active'?

[David Ruess]

Correct. Both desireable for PAGP and Active for LACP starts negotiation for the etherchannel.