Meaning of keepalive packets used by catalyst switches

Unanswered Question
Jun 18th, 2007


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

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 3.5 (2 ratings)
thorsten.steffen Mon, 06/18/2007 - 06:14

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


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.


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.


thorsten.steffen Wed, 06/20/2007 - 03:53


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,


Konstantin Dunaev Wed, 06/20/2007 - 04:20


1. the "loopback" it's like a standart feature of Ethernet see

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


This Discussion