06-18-2007 06:01 AM - edited 03-05-2019 04:47 PM
Hi,
some days ago we had a layer2 loop in our network and several switches announced the following messages:
Jun 14 20:17:37.965 MESZ: %ETHCNTR-3-LOOP_BACK_DETECTED: Keepalive packet loop-back detected on GigabitEthernet0/1.
Jun 14 20:17:37.965 MESZ: %PM-4-ERR_DISABLE: loopback error detected on Gi0/1, putting Gi0/1 in err-disable state
While troubleshooting this issue we asked ourselves what is the sense of keepalive packets but we did not found any documentation in cco.
So it would be very fine if somebody could give me a detailed explanation:
- What is the meaning of this keepalive packets?
- What is the structure and content of keepalive packets?
- What is the destination address?
- How does a cisco neighbor switch handle this keepalive packets?
- How does a non-cisco neighbor switch handle this keepalive packets?
- How does a end devices (e.g. pc) handle this keepalive packets?
Best regards,
Thorsten Steffen
06-18-2007 06:08 AM
The error you received is etherchannel related, and etherchannels send keepalive packets to/from the member of its links.
Read more about etherchanneling on:
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat3560/12225see/scg/swethchl.htm
06-18-2007 06:14 AM
In my understanding the messages does not refer to etherchannel ports.
The ports on which we got this messages also were no etherchannel ports but single uplink vlan trunk ports.
Concerning the both syslog messages I already found the following information on cco:
=================================
%ETHCNTR-3-LOOP_BACK_DETECTED : Keepalive packet loop-back detected on [chars] Problem
The switch reports this error message, and the port is forced to linkdown:
%ETHCNTR-3-LOOP_BACK_DETECTED : Keepalive packet loop-back detected on [chars]
This example shows the console output that is displayed when this problem occurs:
Oct 2 10:40:13: %ETHCNTR-3-LOOP_BACK_DETECTED: Keepalive packet loop-back detected on GigabitEthernet0/1
Oct 2 10:40:13: %PM-4-ERR_DISABLE: loopback error detected on Gi0/1, putting Gi0/1 in err-disable state
Description
The problem occurs because the keepalive packet is looped back to the port that sent the keepalive. Keepalives are sent on the Catalyst switches in order to prevent loops in the network. Keepalives are enabled by default on all interfaces. You see this problem on the device that detects and breaks the loop, but not on the device that causes the loop.
Workaround
Issue the no keepalive interface command in order to disable keepalives. A disablement of the keepalive prevents errdisablement of the interface, but it does not remove the loop.
Note: In Cisco IOS Software Release 12.2(x)SE-based releases and later, keepalives are not sent on fiber and uplink interfaces by default.
=================================
06-20-2007 02:58 AM
hi,
look into this conversation:
ftallet gave there a very good explanation how it works.
06-20-2007 03:53 AM
Hi,
many thanks for your hint which was very helpful.
But now after understanding keepalive packets there are still some open questions:
- Are keepalives and loopback detection cisco proprietary features or are they common features used also by other switch manufacturers?
- Is the loopback detection the only function of keepalive packets or are they also used for other purposes?
- Is my understanding correct that spanning tree topology changes (with cam table flushing) could cause ports which use keepalives and loopback detection to go in error disabled state?
- If this is the case, is this also the reason that keepalives are disabled by default on fiber and uplink ports since ios versions 12.2SE?
Best regards,
Thorsten
06-20-2007 04:20 AM
hi.
1. the "loopback" it's like a standart feature of Ethernet see
http://www.mit.edu/~jhawk/ctp.pdf
"Ether Type" is 0x9000,
SRC and DEST MAC address is the same, address of interface
2. actually the idea behind was to check the avaiability of ethernet connection, Cisco uses keepalive in a different way - for loop detection.
3. if spanning tree convergence is not fast enough then keepalive can block some ports. (see my case). But usually STP converges much more faster then 10 sec (default for keepalive) and if some ports were err-disabled it usually means that STP configuration was wrong and it couldn't correctly block the links which built a loop.
4. it seems yes, because loopback detection reacts a little bit too hard on loopbacks.
02-14-2022 07:19 AM
I have the same problem too, but had to solve it partially by the no keepalive command and check the neighbor on the interface. I can only solve the problem if the whole network is reachable by me.
Hope this was helpful
02-14-2022 08:01 AM
- What is your switch model and or review these bug reports accordingly : https://bst.cloudapps.cisco.com/bugsearch?pf=prdNm&sb=anfr&kw=ETHCNTR-3-LOOP_BACK_DETECTED&bt=custV
M.
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