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
"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?
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.