ethernet keepalive

CARLO CIANFARANI · ‎11-02-2011

Hi,

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 ?

Thanks.

Giuseppe Larosa · ‎11-02-2011

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

see

http://www.groupstudy.com/archives/cisco/200112/msg01021.html

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

Hope to help

Giuseppe

CARLO CIANFARANI · ‎11-02-2011

Hello,

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

Giuseppe Larosa · ‎11-02-2011

Hello,

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

Giuseppe

Peter Paluch · ‎11-02-2011

Giuseppe,

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,

Peter

CARLO CIANFARANI · ‎11-07-2011

Hi,

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

R1-----fastethernet------------SWITCH

C3725#sh run int f1/0

Building configuration...

Current configuration : 87 bytes

!

interface FastEthernet1/0

no ip address

speed 100

full-duplex

no cdp enable

end

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

end

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

Nettuno#

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

DIST ROUTE ENABLED: 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

tx_limited=0(64)

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 ?

thanks

fly · ‎04-17-2014

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!

Tom