Interfaces in port-channel keep err-disabling because of keepalives

[Drew Browning]

Below is the current portchannel that I am having problems with.  The interfaces on Switch A keep going into an error disabled state because they receive their own loopback.  Cisco says to disable keepalives and that it will fix the problem, but I do not like the idea of disabling keepalives.  Has anyone found a solution other than disabling keepalives?  Notice that ios's are different, but am not convinced that this is the issue.  Also one is PoE and the other isn't.  Lastly, i found this article "Keepalives are sent on all interfaces by default in Cisco IOS Software Release 12.1EA-based software. In Cisco IOS Software Release 12.2SE-based software and later, keepalives are not sent by default on fiber and uplink interfaces".  I would think trunked interfaces in a port-channel would be uplink interfaces and if this is true, it should be sending out keepalives anyway since i am running the 12.2SE based ios.  Thanks for whatever input you may have.

Switch A
C3750E Boot Loader (C3750X-HBOOT-M) Version 12.2(53r)SE2, RELEASE SOFTWARE (fc1)
System image file is "flash:/c3750e-universalk9-mz.122-55.SE3/c3750e-universalk9-mz.122-55.SE3.bin"
cisco WS-C3750X-48P

Port-channels in the group:
                ---------------------------

Port-channel: Po52
------------

Age of the Port-channel   = 219d:04h:32m:49s
Logical slot/port   = 10/39          Number of ports = 4
GC                  = 0x00000000      HotStandBy port = null
Port state          = Port-channel Ag-Inuse
Protocol            =    -
Port security       = Disabled
         
Ports in the Port-channel:

Index   Load   Port     EC state        No of bits
------+------+------+------------------+-----------
  0     00     Gi1/0/35 On                 0
  0     00     Gi1/0/36 On                 0
  0     00     Gi2/0/45 On                 0
  0     00     Gi2/0/46 On                 0

%ETHCNTR-3-LOOP_BACK_DETECTED: Loop-back detected on GigabitEthernet1/0/35.
%PM-4-ERR_DISABLE: loopback error detected on Gi1/0/35, putting Gi1/0/35 in err-disable state
%LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/35, changed state to down
%LINEPROTO-5-UPDOWN: Line protocol on Interface Port-channel39, changed state to down
%LINK-3-UPDOWN: Interface Port-channel39, changed state to down

Switch B
C3750E Boot Loader (C3750X-HBOOT-M) Version 12.2(53r)SE2, RELEASE SOFTWARE (fc1)
System image file is "flash:/c3750e-universalk9-mz.122-58.SE2/c3750e-universalk9-mz.122-58.SE2.bin"
cisco WS-C3750X-48

Port-channels in the group:
                ---------------------------

Port-channel: Po52
------------

Age of the Port-channel   = 443d:18h:43m:06s
Logical slot/port   = 10/39          Number of ports = 4
GC                  = 0x00000000      HotStandBy port = null
Port state          = Port-channel Ag-Inuse
Protocol            =    -
Port security       = Disabled

Ports in the Port-channel:

Index   Load   Port     EC state        No of bits
------+------+------+------------------+-----------
  0     00     Gi1/0/35 On                 0
  0     00     Gi1/0/36 On                 0
  0     00     Gi1/0/45 On                 0
  0     00     Gi1/0/46 On                 0

[Rolf Fischer]

Hi,

I never had to disable keepalives on port-channel interfaces. Where did you find this advise?
What I'd recommend is to use a negotiation protocol (PAgP or LACP) instead of the on-mode and, if the links are fiber, UDLD.

HTH
Rolf

Sent from Cisco Technical Support Android App

[Drew Browning]

PER CISCO

Symptom:

An interface on a Catalyst switch is errordisabled after detecting a loopback.

Mar 7 03:20:40: %ETHCNTR-3-LOOP_BACK_DETECTED: Loop-back detected on

GigabitEthernet0/2. The port is forced to linkdown.

Mar 7 03:20:42: %LINK-5-CHANGED: Interface GigabitEthernet0/2, changed state

to administratively down

Mar 7 03:20:43: %LINEPROTO-5-UPDOWN: Line protocol on Interface

GigabitEthernet0/2, changed state to down

Conditions:

This might be seen on a Catalyst 2940, 2950, 2950-LRE, 2955, 2970, 3550, 3560

or 3750 switch running 12.1EA or 12.2SE based code.

Workaround:

Disable keepalives by using the no keepalive interface command. This

will prevent the port from being errdisabled, but it does not resolve the root

cause of the problem. Please see section below for more information.

Additional Information:

The problem occurs because the keepalive packet is looped back to the port that

sent the keepalive. There is a loop in the network. Although disabling the

keepalive will prevent the interface from being errdisabled, it will not remove

the loop.

The problem is aggravated if there are a large number of Topology Change

Notifications on the network. When a switch receives a BPDU with the Topology

Change bit set, the switch will fast age the MAC Address table. When this

happens, the number of flooded packets increases because the MAC Address table

is empty.

[Richard Burts]

When you look in the additional information section of the link that you reference it says that the fundamental problem is that there is a loop in the network. I suspect that there is a loop in your network which is the fundamental cause of your problem. I would suggest checking some obvious things such as are the connections really the way that you think that they are: is 1/0/35 really connected to 1/0/35, 1/0/36 to 1/0/36 etc. And I agree with Rolf that using a negotiation protocol (and perhaps UDLD) might be beneficial.

I had a similar problem a while back. I had ports that kept going error disabled because of loop back detected. After a bunch of troubleshooting I did find that there was a loop - in a different part of the network. So I suggest that you check  not only on these two switches but on any other switch that might be part of this network. Ordinarily you would think that Spanning Tree shoud detect the loop and prevent it. In my case the loop problem was aggravated by the fact that there was a vlan mismatch on a connection between two switches in another part of the network. One switch assigned the port to vlan 5 but the other switch had the port in vlan 1. Since there is a separate instance of Spanning Tree per vlan each switch received a BPDU from its neighbor but ignored the BPDU since it did not match the local vlan. When I corrected the vlan mismatch, then Spanning Tree detected the loop, a port went into blocking state, and the original ports no longer went into error disabled. I suggest that you might look for a similar issue in your network.

HTH

Rick