err-disable state in Cisco 3750 switch

[kevintang]

Hi, I have a brand new Cisco 3750 switch with the latest IOS software

The port 24 is disabled because the loopback error detected. Here is the error message in the log.

*Mar 1 19:03:17: %ETHCNTR-3-LOOP_BACK_DETECTED: Loop-back detected on FastEther

net1/0/24.

*Mar 1 19:03:17: %PM-4-ERR_DISABLE: loopback error detected on Fa1/0/24, puttin

g Fa1/0/24 in err-disable state

By default the port recovery will be attempted after five minutes. But this did not happen. I have to manuuly do it by shut and no shut that interface.

Do you thinks it is a bug?

Any body have the tools to generate the Loop-back traffic, so I can test it in my LAB?

S1#sh errdisable recovery

ErrDisable Reason Timer Status

----------------- --------------

udld Disabled

bpduguard Disabled

security-violatio Disabled

channel-misconfig Disabled

vmps Disabled

pagp-flap Disabled

dtp-flap Disabled

link-flap Disabled

gbic-invalid Disabled

psecure-violation Disabled

gbic-invalid Disabled

dhcp-rate-limit Disabled

unicast-flood Disabled

loopback Disabled

Timer interval: 300 seconds

Interfaces that will be enabled at the next timeout:

S1#

[Prashanth Krishnappa · Accepted solution]

What connects to this interface? Probably it looped back keepalive.

There was a bug filed but it was junked, because it is mostly caused by a STP loop or bad cabling

http://www.cisco.com/cgi-bin/bugtool/onebug.pl?bugid=CSCea46385

http://www.cisco.com/univercd/cc/td/doc/product/lan/cat3750/12220se/3750smg/msg_desc.htm#wp98430

You have disabled err-disable recovery. You can enable it using

3750-A#conf t

Enter configuration commands, one per line. End with CNTL/Z.

3750-A(config)#errdisable recovery cause loopback

3750-A(config)#errdisable recovery cause a?

all arp-inspection

[Jan.Ferre]

I sincerely think it's a bug! Of course error recovery should be enabled, or you may want to disable 'err-disable':

3750-A(Config)# no errdisable cause loopback

In my case the 3750 gbic is connected to some foreign equipment my fiberprovider uses to connect distant sites (cwdm). In the other end is another 3750 gbic port. Occationally I get loopbacks with no evident cause. And the result is a network melt-down.

The switch in the other end stops working (even at interfaces not connected to the error-disabled port) and only a powercycle will restore the switch. This is BAD! (At the moment we don't have console access)

Nov 15 12:25:34: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/26, changed state to up

Nov 15 12:25:35: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/25, changed state to up

Nov 15 12:25:36: %ETHCNTR-3-LOOP_BACK_DETECTED: Loop-back detected on GigabitEthernet1/0/25.

Nov 15 12:25:36: %ETHCNTR-3-LOOP_BACK_DETECTED: Loop-back detected on GigabitEthernet1/0/26.

Nov 15 12:25:44: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/25, changed state to down

Nov 15 12:25:44: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/26, changed state to down

What kind of equipment should return a keepalive? Other than a loopback-cable which is certainly _not_ installed?

And how to turn it off?

[Jan.Ferre]

Do you use Trunk mode????? At https://secure.experts-exchange.com they've got a question:

- uplink port in access mode: works fine, no errors, nothing odd in logs

- uplink in (.1q) trunk mode: comes up for 30 seconds, logs a "loopback

detected" message and goes to errdisable on the 3750 side...the 6513

just sees it come up, become a trunk, then go back down

- uplink in trunk mode with keepalives off (TAC suggestion): comes up and

stays up, but gets constantly incrementing CRC errors on the 3750 side.

again the 6513 sees no problems of any kind.

Unfortunately they charge people to see the reply.....

Jan

[kevintang]

I think it is a bug, too.

the default should enable errors recovery. not disable.