Matiaz, Lots of thanks for a prompt response. It looks as we are in sync, as I do not see much value in manipulating ARP due to failure of the BFD sessions either but I do see lots of complications.
Your reference to static ARP is a valid point – but, then, please note that this could be a problem even without any BFD sessions. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: [email protected] From: Matjaz Straus Istenic [mailto:[email protected]] Sent: Tuesday, February 09, 2016 3:38 PM To: Alexander Vainshtein Cc: Matjaž Straus Istenič; [email protected] Subject: Re: BFD for IPv4 next-hop and ARP 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]<mailto:[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]<mailto:[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ž
