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ž

Reply via email to