Loopback detected only on 2950 switches?

Unanswered Question
Sep 24th, 2008
User Badges:

Out networks is built by 6506, 3750 and 2950 swiches. For some weeks ago all uplink ports in the 2950 switches went into error-disable caused by loopback-detected. The strange thing is that none of the 3750 swiches where affected even it the same vlans are wide spread all over the different type of devices. Does anyone know if there are some bugs in this 12.1(19) software that triggers loopback-detected???

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Giuseppe Larosa Wed, 09/24/2008 - 11:43
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

Hello Per,

it looks like that your c2950 have spanning-tree loop-guard configured on their uplinks


see if the command

spanning-tree loop guard

is present on the uplinks of the c2950


if it is missing on the c3750 this could explain the different behaviour


Hope to help

Giuseppe


cyptic Thu, 09/25/2008 - 10:26
User Badges:

Thank's for your reply.

We have no loop-guard configured on any uplink ports in the network.

I think a loop where created somewhere in the network on a interface without bpdu-guard and flooded back the loopback-detected keep-alives to the source-switches.


glen.grant Wed, 09/24/2008 - 16:35
User Badges:
  • Purple, 4500 points or more

An explanation.


#


Loopback error


A loopback error occurs when the keepalive packet is looped back to the port that sent the keepalive. The switch sends keepalives out all the interfaces by default. A device can loop the packets back to the source interface, which usually occurs because there is a logical loop in the network that the spanning tree has not blocked. The source interface receives the keepalive packet that it sent out, and the switch disables the interface (errdisable). This message occurs because the keepalive packet is looped back to the port that sent the keepalive:


%PM-4-ERR_DISABLE: loopback error detected on Gi4/1, putting Gi4/1 in

err-disable state


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. For more information, refer to Cisco bug ID CSCea46385 ( registered customers only) .


The suggested workaround is to disable keepalives and upgrade to Cisco IOS Software Release 12.2SE or later.


Jason Fraioli Wed, 09/24/2008 - 16:37
User Badges:

The last time I had this problem it was due to a physical cabling problem.

cyptic Thu, 09/25/2008 - 11:12
User Badges:

Hi!


I can't really understand the reason why cisco where turning of the keepalives in default from software releases above 12.2SE?

Is there any other feature that replaces the errdisable casue by loopback for uplink-ports or is are doesn't the keepalive packets belong on these type of interfaces where we have other spanning-tres mechanism that keeps the network free from loops?

Giuseppe Larosa Thu, 09/25/2008 - 11:41
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

Hello Per,

I think Glen is meaning the interface keepalive that is not an STP message


an ethernet keepalive is a frame with SA = DA = port mac address that is sent out and expected to come back on the rx.


So I thought but the bug description says the opposite !


It is so:


ETHCNTR-3-LOOP_BACK_DETECTED: Loop-back detected on gig0/2

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.


Keepalives are sent on the Catalyst 2940, 2950, 2950-LRE, 2955, 2970, 3550, 3560

or 3750 switch to prevent loops in the network. The primary reason for the

keepalives

is to prevent loops as a result of Type 2 cabling. For more information, see:

http://www.cisco.com/en/US/netsol/ns340/ns394/ns74/ns149/networking_solutions_white_paper09186a00800a3e16.shtml


Keepalives are sent on ALL interfaces by default in 12.1EA based software.

Starting in 12.2SE based releases, keepalives are NO longer sent by default on fiber and

uplink interfaces.


rs Status

Terminated

(Junked)

Severity

3 - moderate



Product

Cisco IOS software


Technology



1st Found-In

12.1(12c)EA1



Component(s)



Hope to help

Giuseppe


Arp_Hiemstra Fri, 01/23/2009 - 00:42
User Badges:

Hi all,


I have seen this same issue occur on the network here. Uplink fiber trunk ports are err-disabled because of loopback and fastethernet ports are disabled because of loopback. So after checking the cables etc, i am very confident that there is no loop in the network. Can it be the use of old cable causing this errors to occur?

I have turned off keepalive on the uplink ports to at least keep the switches reachable in case of such events.

Any insights are greatly apreciated.


Actions

This Discussion