LOOP_BACK_DETECTED - some questions

[LucaSalvatore_2]

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?

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.

[LucaSalvatore_2]

The theory of these keepalives is doing my head in.

Does the interface that sends the keepalive expect to see the keepalive back or not?

From what i have read keepalives are sent with the source and destination MAC address of the interface that sent it.

If this is the case then the interface should expect to receive the keepalive back.... right?

Now if a downstream switch does not have the mac-address of the source interface in its mac table it will broadcast the keepalive out all intefaces except the one it was receive on. So if there is a loop in the network it is this behaviour that could cause the source interface to recieve the packect twice.... right?

[johgill]

Hey Luca,

I will take a look at the configs when I get a chance by the way - but generally they look okay.

The interface that sends the keepalive will definitely see it via it's loopback once. However, it should not see it again.

If a downstream switch does not have the mac of the source and it receives this loop reply frame - it *now* does, since smac and dmac are the same.

If there is a loop in the network, mac addresses will flap very quickly as the packets storm around both directions.

Essentially the rules of sending a frame out all ports except the source interface cannot really be followed, since the mac address is in constant flux. What you get is frames being duplicated in the storm and sent out all directions. Eventually, you can see your own loop frame.

[Pranjal Bharadwaj]

Hello Everyone,
I have a little query related to this loopback error issue causing SW port in err-disable state.
My SW version is as below which states keepalives are not sent by default on the fibre and uplink ports as per CISCO.
krse510
Switch Ports Model              SW Version            SW Image
------ ----- -----              ----------            ----------
*    1 28    WS-C3750G-24TS-1U  12.2(46)SE            C3750-IPBASE-M
 
PE------SW------(Carrier)----CE
Gi1/0/27 -- pointing towards PE
Gi1/0/23 -- pointing towards Carrier.
 
However, I got the below logs and made our Customer facing port to Err-Disable state.
 
 
Dec 16 19:15:42.885 UTC: %SW_MATM-4-MACFLAP_NOTIF: Host 7c0e.cec1.8b04 in vlan 326 is flapping between port Gi1/0/23 and port Gi1/0/27
Dec 16 19:15:45.100 UTC: %ETHCNTR-3-LOOP_BACK_DETECTED: Loop-back detected on GigabitEthernet1/0/23.
Dec 16 19:15:45.100 UTC: %PM-4-ERR_DISABLE: loopback error detected on Gi1/0/23, putting Gi1/0/23 in err-disable state
 
 
My questions are as below:
1. Could somebody please let me know is this possible getting ETHCNTR-3-LOOP_BACK_DETECTED on this port as we are on Version 12.2(46)SE ??
2. How can I overcome this situation as each time it went to err-disable mode once any logs come for mac-flap between Gi1/0/23 and port Gi1/0/27?
3. What are the possible causes that generated these logs?
 
 
krse510#sh run int Gi1/0/23
Building configuration...
Current configuration : 315 bytes
!
interface GigabitEthernet1/0/23
 description ---To XXXX
 switchport trunk encapsulation dot1q
 switchport trunk native vlan 326
 switchport trunk allowed vlan 326,3123
 switchport mode trunk
 switchport nonegotiate
 speed 100
 duplex full
 mls qos trust cos
 no mdix auto
 spanning-tree bpdufilter enable
end