Loop_back_detected - Some help.

rakem

Not an exam question here but im sure I can get some good advise here..

Today a college hooked up a new switch into our network. It was a 3560 being connected to a pair of 3750s in a stack, so one uplink went to Gi1/0/18 and the other went to Gi2/0/18.

When the second cable (Cat6) was connected a bunch of our switches went down. The uplink ports went into err-disabled and the error in the log was:

%ETHCNTR-3-LOOP_BACK_DETECTED: Loop-back detected on GigabitEthernet0/48.
%PM-4-ERR_DISABLE: loopback error detected on Gi0/48, putting Gi0/48 in err-disable state

Now the expected behaviour was for spanning tree to just block the second connection to Gi2/0/18 and for no outage at all.

In the end about 10 switches went down with the loopback error.

So I have been researching the loopback error and found this link: http://www.cisco.com/application/pdf/paws/69980/errdisable_recovery.pdf

Which says:
"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. 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 fibre and uplink interfaces. For more information, refer to Cisco bug ID CSCea46385"

So i have a few questions.
1) What are these keepalives for? (My research shows they are just the standard ethernet keepalives used to testing the line)

2) Why did the same keepalive get received and then multiple other switches get put in err-disabled? Spanning tree should have blocked the second port instantly (RSTP)

3) The link mentions that "In 12.2SE−based software and later, keepalives are not sent by default on fibre and uplink interfaces" By uplink I assume it means a trunk port?

Our switches are running 12.2(25)SED1, so not sure if that version has the 'bug' mentioned in the article.

So can anyone shed some light on why this loopback error occurred? And is there any adverse side affected to applying the 'no errdisable detect cause loopback' command.

Thanks.

CCIE_2011

can you provide us with configuration of both switches please ?

pastebin.com please

rakem

Ok.... so this is the config from the 3560 that was introduced into the network. Gi0/1 and Gi0/24 were connected to the 3750

pastebin - collaborative debugging tool

This is from the 3750
Ports Gi1/0/18 and Gi2/0/18 were connected to the 3560.

pastebin - collaborative debugging tool

The cables were connected while the ports were shutdown. Gi0/24 was enabled first, then 5 minutes later Gi0/1 was enabled. When that port was enabled was when the problem started.

Anyone got any comments on possible side efftects of disabling keepalives on ethernet ports?
They are disabled by default on Fibre and Uplink ports (from IOS 12.2SE and above) so I can't see an issue.
One guy on another forum said that it will force the interface to be 'UP' all the time, but in my testing i have not seen this happen.

rakem

err my pastebin things have gone....

configs are uploaded here

3750 - 3750.txt
3560 - 3560.txt

kryolla

do you have a layer 2 topology diagram w/the root switch and all spanning tree parameters?

rakem

Hmmm nothing that is up to date ufortunatly.... only got a logical topology diagram

wastedtime

My only question is how was that stuff recorded going on with port GigabitEthernet0/48 when neither of the switches have a port Gi0/48? Is it possible that you are misreading something?

rakem

wastedtime wrote: »

My only question is how was that stuff recorded going on with port GigabitEthernet0/48 when neither of the switches have a port Gi0/48? Is it possible that you are misreading something?

Because that error that mentions Gi0/48 was from a different switch.... It was the same error on all affected switches, but with their own interface