Subject: BFD for IPv4 next-hop and ARP

From: Matjaz Straus Istenic <[email-masked]>
Date: Tue, 9 Feb 2016 13:06:38 +0100

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ž

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 9 Feb 2016 13:05:28 +0000

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-masked]

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Matjaz Straus Istenic
Sent: Tuesday, February 09, 2016 2:07 PM
To: [email-masked]
Subject: BFD for IPv4 next-hop and ARP

Dear WG,

Kind regards,

                Matjaž

---

From: Matjaz Straus Istenic <[email-masked]>
Date: Tue, 9 Feb 2016 14:38:11 +0100

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-masked]> wrote:
> 
> Matiaz hi!

> 
> Regards,
> Sasha
> 
> Office: +972-39266302
> Cell:      +972-549266302
> Email:   [email-masked] <mailto:[email-masked]>
> 
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 9 Feb 2016 13:43:12 +0000

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

From: Matjaz Straus Istenic [mailto:[email-masked]]
Sent: Tuesday, February 09, 2016 3:38 PM
To: Alexander Vainshtein
Cc: Matjaž Straus Istenič; [email-masked]
Subject: Re: BFD for IPv4 next-hop and ARP

Thanks again,
best regards,

            Matjaž

On 9. feb. 2016, at 14:05, Alexander Vainshtein <[email-masked]<mailto:[email-masked]>> wrote:

Matiaz hi!

Hopefully this helps.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]<mailto:[email-masked]>

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Matjaz Straus Istenic
Sent: Tuesday, February 09, 2016 2:07 PM
To: [email-masked]<mailto:[email-masked]>
Subject: BFD for IPv4 next-hop and ARP

Dear WG,

Kind regards,
                Matjaž