Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 
Community Member

ethernet keepalive


reading from CCO:

"Ethernet Keepalives:  On broadcast media like an Ethernet,  keepalives are slightly different. Since there are many possible  neighbors on the Ethernet, the keepalive is not designed to determine if  the path to any one particular neighbor on the wire is available. It is  only designed to check that the local system has read and write access  to the Ethernet wire itself. The router produces an Ethernet packet with  itself as the source and destination MAC-address and a special Ethernet  type code of 0x9000. The Ethernet hardware sends this packet onto the  Ethernet wire and then immediately receives this packet back again. This  checks the sending and receiving hardware on the Ethernet adapter and  the basic integrity of the wire "

my understanding is ethernet keepalive is a tool based on physical layer (layer 1) functions only. So, for example, I expect that in connecting a router ethernet interface to a hub (no switch) keepalive continue to work.

I guess something like ethernet loopback circuitery is involved in implementing ethernet keepalive....

Does it make sense ?


Hall of Fame Super Silver

Re: ethernet keepalive

Hello Carlo,

this time I do not agree ethernet keepalives are ethernet frames with LLC/SNAP encapsulation with protocol 0x9000 and with MAC SA = MAC DA = ethernet interface bia.

the objective is to understand if the port is plugged to something or not

speed negotiation at 10/100 uses pulses that are not ethernet frames

I have been able to capture them with wireshark out the port of a C3750ME with 12.2(25)SE


in half duplex mode circuitry is used to detect collisions during the process of sending one frame.

Hope to help


Community Member

Re: ethernet keepalive


so - also for half-duplex ethernet i/f connected to an hub port - the keepalive frames are sent on the wire and received back by the router interface it right ?

A doubt arises me if router ethernet i/f is connected to a switch: if i remember well the switch logic does not allow to forward a frame out of the port receiving the frame

thanks in advance.

Hall of Fame Super Silver

ethernet keepalive


the switch logic treats these frames as special frames, that is it will  cooperate with the connected device in correct detection of state, this is part of ethernet specifications.

see it as a loopback frame in other words it is sent back to the original sender

Hope to help


Cisco Employee

ethernet keepalive


Ummm... I may be annoying at this point with my obviously stubborn view, but are you really sure we should be looking at the LOOP frames (the "keepalive" frames) as something that should be reflected back to the original sender? In a discussion we had some time back, I have gone to a great length explaining and demonstrating that if such a frame is reflected back, it will be considered an error, not a proof of a workable network connection.

The LOOP protocol may have been a part of Ethernet specification in its early stages, but in my personal opinion, it formed a Layer2 version of an Ethernet PING frame, obviously allowing for the SourceMAC and DestinationMAC to be different. Cisco seems to be reusing this concept in a non-default setting, intending to detect self-looped ports on switches. On routers, receiving these frames or not does not make a difference.

Needless to say, I distrust the article from the CCO in this aspect

Best regards,


Community Member

Re: ethernet keepalive


just to better understand, I tried to connect R1 fa1/0 (c3725) to SWITCH fa0/16:


C3725#sh run int f1/0

Building configuration...

Current configuration : 87 bytes


interface FastEthernet1/0

no ip address

speed 100


no cdp enable


SWITCH#sh run int fa0/16

Building configuration...

Current configuration : 143 bytes


interface FastEthernet0/16

description test

switchport access vlan 199

switchport mode access

speed 100

duplex full

no cdp enable


in this scenario I can see outgoing pkts but none entering from f1/0:

Nettuno#sh int f1/0

FastEthernet1/0 is up, line protocol is up

  Hardware is AmdFE, address is 0007.b35b.d301 (bia 0007.b35b.d301)

  MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,

     reliability 255/255, txload 1/255, rxload 1/255

  Encapsulation ARPA, loopback not set

  Keepalive set (10 sec)

  Full-duplex, 100Mb/s, 100BaseTX/FX

  ARP type: ARPA, ARP Timeout 04:00:00

  Last input 01:38:49, output 00:00:06, output hang never

  Last clearing of "show interface" counters 00:00:35

  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

  Queueing strategy: fifo

  Output queue: 0/40 (size/max)

  5 minute input rate 0 bits/sec, 0 packets/sec

  5 minute output rate 0 bits/sec, 0 packets/sec

     0 packets input, 0 bytes

     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles

     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored

     0 watchdog

     0 input packets with dribble condition detected

     3 packets output, 180 bytes, 0 underruns  <---------------3 keepalive sent (60 byte each)

     0 output errors, 0 collisions, 1 interface resets

     0 babbles, 0 late collision, 0 deferred

     0 lost carrier, 0 no carrier

     0 output buffer failures, 0 output buffers swapped out


tx_head/tx_tail fa1/0 controller confirm this:

Nettuno#sh contr f1/0

Interface FastEthernet1/0

Hardware is AMD Am79c971

ADDR: 658367C8, FASTSEND: 60138458, MCI_INDEX: 0


Route Cache Flag: 11

LADRF=0x0000 0x0100 0x0000 0x0000

CSR0  =0x00000072, CSR3  =0x00001044, CSR4  =0x0000491D, CSR15 =0x00000180

CSR80 =0x00009900, CSR114=0x00000000, CRDA  =0x074008C0, CXDA  =0x07400D30

BCR9 =0x00000001 (full-duplex)

CSR5  =0x00000001, CSR7  =0x00000820, CSR100=0x0000F000, CSR125=0x00005C3C

BCR2  =0x00000000, BCR9  =0x00000001, BCR18 =0x000019E0, BCR22 =0x0000FF06

BCR25 =0x000000FF, BCR26 =0x00000080, BCR27 =0x00000010, BCR32 =0x00004480

HW filtering information:

  Promiscuous Mode Disabled, PHY Addr Enabled, Broadcast Addr Enabled

  PHY Addr=0007.B35B.D301, Multicast Filter=0x0000 0x0100 0x0000 0x0000

amdp2_instance=0x65838268, registers=0x3D100000, ib=0x7400860

rx ring entries=64, tx ring entries=128

rxring=0x74008C0, rxr shadow=0x658384F0, rx_head=0, rx_tail=0

txring=0x7400D00, txr shadow=0x65838624, tx_head=3, tx_tail=3, tx_count=0 <--------- 3 keepalive sent

Software MAC address filter(hash:length/addr/mask/hits):

  0xC0:  0  0100.0ccc.cccc  0000.0000.0000         0

spurious_idon=0, filtered_pak=0, throttled=0, enabled=0, disabled=0

rx_framing_err=0, rx_overflow_err=0, rx_buffer_err=0

rx_bpe_err=0, rx_soft_overflow_err=0, rx_no_enp=0, rx_discard=0

tx_one_col_err=0, tx_more_col_err=0, tx_no_enp=0, tx_deferred_err=0

tx_underrun_err=0, tx_late_collision_err=0, tx_loss_carrier_err=0

tx_exc_collision_err=0, tx_buff_err=0, fatal_tx_err=0

hsrp_conf=0, need_af_check=0


PHY registers:

  Register 0x00:   2100  780D  7810  0003  0101  0000  0000  0000

  Register 0x08:   0000  0000  0000  0000  0000  0000  0000  0000

  Register 0x10:   0000  0000  4000  0000  38C8  0010  0000  0002

  Register 0x18:   0001  0000  0000  0000  0000

so the question is: are keepalive handled by ethernet controller built-in logic without passing them towards CPU ?


Community Member

I am confusing at this

I am confusing at this keepalive question now.

I found one etherchannel port going to err disable state due to loopback on 3750. So i get to this thread.

   does keepalive just going out interface controller and reach transceiver and coming back directly at switch interface itself,

and doesn't expect to reach the other end switch.

    but this keepalive frame , I think can reach the other end switch , if there is a spanning tree loop. this frame can come back to original interface , and switch can find this ,so err disable.

   but i have question . how can switch recognize the frame come back directly from itself interface driver. or come from remote spanning tree loop segment, I think frame is same.

   Thank you!


CreatePlease to create content