This is very helpful, thank you :-). You assumption on the scenario in question is perfectly right, I was referring to a statically configured route for which the next-hop is being monitored by a single hop BFD.
Apart from the scenario you are describing in 4c I find no benefit of “messing"
with ARP. Moreover, other complications might evolve from such an (I would say
- dirty) “enhancement”. For example, what happens if static ARP entry is
configured. Will we remove it as well?
Thanks again,
best regards,
Matjaž
> On 9. feb. 2016, at 14:05, Alexander Vainshtein
> <[email protected]> wrote:
>
> 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]
> <mailto:[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ž
signature.asc
Description: Message signed with OpenPGP using GPGMail
