Matiaz hi!
I assume that the context for your question is the following scenario:
1. A static route with a directly connected Next Hop has been configured
on your system
2. The Next Hop IP address has been successfully resolved to MAC address
3. A 1-hop BFD session is set up and used to monitor liveness of the Next
Hop.
a. When the session fails, the static route is declared inactive
b. However, the entry in the ARP cache (that is subject to its own aging
process) remains valid for some time.
4. What happens when connectivity to the Next Hop is restored? From my
POV there are three possible situations:
a. The connectivity has originally failed because the interface (in the
adjacent router) carrying the Next Hop IP address has failed. In this case:
i. When the
connectivity is restored, MAC address of this interface may change (e.g., if
the NIC supporting this interface has been replaced)
ii. However,
in this case I would expect the interface to issue a gratuitous ARP request for
its own IP address using the new MAC address. As per RFC 826, upon receiving
this ARP request your system should update its ARP cache entry for the Next Hop
IP address with the new MAC address, so that your BFD session could continue
using the updated ARP cache entry
b. The connectivity has failed for some other reason (your interface has
failed, or some intermediate switch has failed etc.) In this case there is no
reason for the MAC address to which the Next Hop IP address has been resolved
to change, so your BFD session can safely continue using the old ARP cache entry
c. There also a possible combination of cases (a) and (b) above that
could result in your system not receiving the gratuitous ARP request issued by
the adjacent system. In this case you would have to wait until your ARP entry
would be removed by aging until your BFD session comes up. This seems to be the
only scenario when removing the ARP cache entry based on the BFD session
failure would help, but combination scenarios are rare enough to justify such
enhancements IMHO.
Hopefully this helps.
Regards,
Sasha
Office: +972-39266302
Cell: +972-549266302
Email: [email protected]
-----Original Message-----
From: Rtg-bfd [mailto:[email protected]] On Behalf Of Matjaz Straus
Istenic
Sent: Tuesday, February 09, 2016 2:07 PM
To: [email protected]
Subject: BFD for IPv4 next-hop and ARP
Dear WG,
I’m looking for some help regarding the BFD influence to ARP. The question is -
Is it wise from an operational perspective or, on the other hand, wrong if a
failed BFD check that monitors IPv4 reachability (for a static route, for
example), makes changes in the ARP table, for example, by removing the ARP
entry for a BFD-failed IPv4 address?
In my humble opinion, BFD should not influence ARP in any way, ‘cause this
might be a recipe for disaster in case of BFD code malfunction or configuration
error. I would appreciate your feedback on this.
Kind regards,
Matjaž