04-02-2009 08:53 AM - edited 03-06-2019 04:57 AM
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
04-02-2009 09:56 AM
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>
04-02-2009 10:34 AM
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
04-15-2009 07:57 AM
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?
04-15-2009 08:38 AM
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
04-15-2009 11:55 PM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide