cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1291
Views
5
Helpful
5
Replies

Disabling keepalives

darrenriley5
Level 1
Level 1

We've had a problem on our network recently with trunk ports error disabling on our switch stacks with the following error.

45w5d: %ETHCNTR-3-LOOP_BACK_DETECTED: Keepalive packet loop-back detected on Gig

abitEthernet0/2.

45w5d: %PM-4-ERR_DISABLE: loopback error detected on Gi0/2, putting Gi0/2 in err

-disable state

45w5d: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/2, chang

ed state to down

I plan to disable keepalives on the uplinks to solve the problem (we are using 12.1(14)EA1a IOS). Can anyone see any potential issues with this? Also should I do this from both sides (access and core)?

Thanks

5 Replies 5

andrew.prince
Level 10
Level 10

If you are getting those errors you should be checking your physical cabling.

If these are false positives, then configure your err-disable recovery time to something acceptable, that does not cause your STP to slowly re-converge/flap.

HTH>

Giuseppe Larosa
Hall of Fame
Hall of Fame

Hello Darren,

there is a bug that affects some switch models and IOS versions that cause some false positive on fiber based links.

the suggested workaround is to disable the keepalive on the links.

Note: ethernet keepalives work exactly in this way: they are special frames with destination= source = port MAC address and it is correct to receive them back on the same port.

I guess this device can be a 2950 from the IOS version you have mentioned it should be among the affected platforms.

Hope to help

Giuseppe

Hi,

This is still confusing me as there seems to be conflicting information. From my understanding keepalives are sent out of interfaces as layer 2 frames with source and destination of the port MAC address, therefore the port should receive the keepalive back after sending it. From my understanding they are used to test the physical link of the network?

What I don't understand is why I have just read from Cisco's site that they are in fact used to prevent loops in the network and that the problem occurs because the keepalive packet is looped back to the port that sent the keepalive. I thought that was the whole point of them so why would the port error disable?

Hello Darren,

it is a question of a software bug:

someone implemented the SW routine wrongly thinking of the correct event (receiving back your own messages) as a sign of a problem and so reacting badly.

This affects some IOS versions on some platforms.

keepalives are used to say

interface up line protocol up

that line protocol up comes from keepalives.

In old times I could pretend to have ethernet ports up/up just by disabling keepalive on them for testing and I could also ping them.

keepalives shouldn't be a way to check for loops actually the frame is a request for send back

see the following link

http://www.groupstudy.com/archives/cisco/200112/msg01021.html

or try to capture them with a sniffer on an FE port.

Hope to help

Giuseppe

Thanks for the explanation. One final question, do you have any idea as to why we would only experience this problem occasionally (once or twice week). As mentioned in earlier posts we are using fiber based links and it is only affecting our 3550 switches with 12.1(14)EA1a IOS. I have now disabled keepalives so this shouldn't be a problem now but I'm just curious.

Many Thanks

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco