"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....
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
This document gives several answers on frequently asked questions for PFRv3 channel state behavior.
Q1: What are all the channel operational states from a BR (border role) perspective and what are the rules/conditions to be in each st...
The need was to reach an host inside a LAN through a VPN connection managed by the LAN gateway (Cisco 1921).
The LAN gateway performs NAT and there was a dedicate nat rule for the host i wanted to reach through VPN.
I couldn't connect to the hos...