cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4052
Views
7
Helpful
7
Replies

Meaning of keepalive packets used by catalyst switches

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

7 Replies 7

Edison Ortiz
Hall of Fame
Hall of Fame

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

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

URL: http://www.cisco.com/en/US/products/hw/switches/ps700/products_tech_note09186a00801b42bf.shtml#prob1b

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.

=================================

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

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.

Laith9Sky
Level 1
Level 1

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

marce1000
VIP
VIP

 

 - 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.



-- ' 'Good body every evening' ' this sentence was once spotted on a logo at the entrance of a Weight Watchers Club !
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: