[nsp] error on ethernet controller cisco 3550

[sthaug at nethelp.no]

> I am getting the same error message and my conditions are about the same.
> Did you find out what is causing this?
> 
> %ETHCNTR-3-LOOP_BACK_DETECTED: Loop-back detected on [chars]. The port is
> forced to linkdown

I posted the article below to comp.dcom.sys.cisco - it might be of
interest here too.

I think the ETHCNTR-3-LOOP_BACK_DETECTED is a serious problem on 3550,
and Cisco needs to fix it.

Steinar Haug, Nethelp consulting, sthaug at nethelp.no
----------------------------------------------------------------------
From: sthaug at nethelp.no (Steinar Haug)
Subject: Re: 3550 "self killing"
Date: 26 Jun 2003 20:09:13 GMT
Message-ID: <bdfjt9.2thn.1 at verdi.nethelp.no>

["Will Plaice"]

|  after some STP changes on our switch core a 3550 SMI that's attached to 2 of
|  the 4 6500's at gbic detects an STP loop and shuts down one of the gbic
|  trunks... 6 seconds later it detects another loop and shuts down the other
|  one... efectivly this switch is now isolated from the network... not good...

We haven't seen this particular problem - however, we've had multiple
cases of 3550 GE ports shutting down with "ETHCNTR-3-LOOP_BACK_DETECTED"
for no good reason (and very definitely *not* a loop). The explanation
at the Cisco web site very unhelpfully suggests

"Check the cables. If a balun cable is connected and the loopback
condition is desired, no action is required. Otherwise, connect the
correct cable, and bring the port up by entering the no shutdown
interface configuration command."

In 12.1(13)EA1a it's possible to get the switch to attempt to recover
from this condition using "errdisable recovery cause loopback" - we
have now included this in our standard configuration template. The
Cisco default behavior of leaving the port shutdown (until the switch
is rebooted, or somebody does a manual "no shut") is hopeless, since
the port that was shut down may have been the only connection to the
outside world.

Note that it's possible to provoke the "ETHCNTR-3-LOOP_BACK_DETECTED"
condition by actually creating a loop - connecting TX and RX on the
GBIC with a single fibre. However, 6500 with native IOS simply sees
itself via CDP in the same situation, and does *not* shutdown the
interface. The 6500 behavior is much more helpful, IMHO.

Steinar Haug, Nethelp consulting, sthaug at nethelp.no