Error Disable due to Loopback

[Muhannad Abu Shamma]

Hello Expert,

I have a couple of questions about the "Error Disable due to Loopback" feature and I appreciate any reply may help in further understanding how this feature works.

I have the following topology:

Core 1 (Gig1/1/14) <--> (Gig1/1/1) SW2 {3750X,15.0(2)SE2} (Gig1/0/7)<-->(Gig1/0/7) SW1 {3750X,15.0(2)SE2}

Gig1/0/7 on SW1 went in error disable state due to loopback. This port is configured as trunk -and for sure the other side on SW2-. I did search about the error disable due to loopback and found this occurred due to looped back the keepalive packets back to the port which sent before.

My questions are:

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

1. Does the switch broadcast or forward the keepalive packet received from other switches in the network? In my case, does SW2 forward the keepalive message received from SW1/port Gig1/0/7 to any other device in the network? What is the ttl value for the keepalive packet?

2. I found a post on cisco forum mentioned that the life of the keepalive packet is just across one link. The receiving switch drops the keepalive packets. Is this correct? If yes, how the packet will looped back? see link:https://supportforums.cisco.com/thread/15515

3. Same post above mentioned that the keepalives are essentially used on layer 2 switches for detecting loops that Spanning Tree has not yet blocked, eg. due to lack of CPU resources. Are there any other possible reasons for this behavior? STP not blocked the loop while keepalive mechanism detect the loop?

4. If the keepalive packet sent from port Gig1/0/7 (SW1) return back to SW1 BUT through different port, does this will cause any port on SW1 to go in error disable state due to loopback?

5.What are the possible reasons for the keepalive packet to be looped back to the same port sent from before? other than logical loop?

6. Anyone can provide me with useful/detailed document about the mechanism of the keepalive? how it works?

[Richard Burts]

I will begin my response by reminding us that we need to be careful to distinguish between layer 3 processing of packets and layer 2 processing of frames. Several of your questions (especially 1 and 2) ask about TTL  and accross one line. These are layer 3 aspects of forwarding. But the keepalive that you are asking about is a layer 2 keepalive. And the layer 2 keepalive will be forwarded through out the broadcast domain - which is quite possibly through all of the switches in your network as it is described here.

I looked at the link that you posted (which dates back to 2004). I am not sure whether the behavior has changed or whether the person who posted that information was wrong. But I can tell you for sure that the Ethernet switch keepalive is not dropped at the first switch that it goes through. The keepalive is forwarded through the broadcast domain.

That article is correct that the Ethernet switch keepalive is used to detect loops that have not been detected by Spanning Tree. And there are cetainly reasons other than lack of CPU resources that may prevent Spanning Tree from detecting the loop. I recently had an experience with a switch port that was going into error disable because of the loopback detected. After a bunch of troubleshooting we did find that a physical loop did exist and that Spanning Tree was not detecting the loop. The issue was that on the segment that physically created the loop there was a mis configuration. One switch has its port configured to be in vlan 5 while the other switch still had its port in vlan 1. Since there is a separate instance of Spanning Tree for each vlan the switch with its port in vlan 5 was ignoring the BPDU sent from vlan 1 and the switch with its port in vlan 1 was ignoring the BPDU from vlan 5. When we corrected the configuration so that both switches had the connection in the same vlan then Spanning Tree did detect the loop and put a port into blocking state - and the original port no longer went into error disabled.

I am not sure if there are other reasons why the keepalive would be looped back other than a physical loop. But I can tell you for sure that symptoms such as you describe are very possible when a physical loop does exist.

HTH

Rick