RE: BFD for long haul circuit

[Harivishnu Abhilash <Harivishnu.Abhilash () mannai com qa>]

Classification:Internal

Hi Mark,

Thanks for the update. You have any backhauls, that is running over an L2 xconnect  ? I’m facing issue only on the 
backhaul link over a l2vpn ckt.

Ta,


From: NANOG <nanog-bounces+harivishnu.abhilash=mannai.com.qa () nanog org> On Behalf Of Mark Tinka
Sent: Thursday, July 16, 2020 8:35 PM
To: nanog () nanog org
Subject: Re: BFD for long haul circuit

EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.


On 16/Jul/20 05:51, Harivishnu Abhilash wrote:
Classification:Public

Guys, I’m looking for recommendation regarding BFD timers that we can use for long haul circuit. RTT is roughly around 
110 ms. In fact this is a l2vpn ckt provided by a telco.
Can you please advise the factors we can consider when setting the BFD timers (or any recommended values)? I have set 
10 ms dead time but this is causing BFD to go down occasionally.

We run different intervals and multipliers depending on whether the connection is LAN or WAN.

For LAN (so within the same data centre), intervals are set to 150ms and multipliers are set to 3.

For WAN (any backbone regardless of latency), intervals are set to 250ms and multipliers are set to 5.

Since our network spans multiple countries and continents, we wanted a uniform value for the WAN side of things, so we 
don't have too many customized configurations. We found these settings to work well in mixed environments where 
implementations vary between CPU and line card processing, and also to strike a balance between accuracy and false 
positives.

We've been running this on IOS XE, IOS XR and Junos platforms since 2014. The only issues we found were:

  *   BFD on LAG's on IOS XR platforms in a LAN environment don't work. A point-to-point mechanism is required, so we 
disabled it there. Junos and IOS XE have no problems running BFD on LAG's in LAN's, so we have it on there. This is for 
within the data centre.

  *   BFDv6 on the MX does not run in hardware. Since IS-IS (for us) ties in BFD for link state event detection, a 
transient lack of CPU resources to service BFDv6 traffic will result in not only BFDv6 going down, but also the entire 
IS-IS protocol flapping on the assumption that a link event has occurred. So if you run BFDv6 alongside BFDv4, 
recommend that you disable BFDv6 until Juniper introduce hardware support for it on the MX (and I'm guessing all other 
Junos platforms). We have an ER out for this since 2019, and we are told it should be appearing sometime between Q4'20 
- 1H'21.

  *   Syntax for BFD in Junos has changed to incorporate address families. So while the old syntax will commit, it will 
leave an annotation in the configuration about not being supported anymore. Recommend you convert your Junos BFD 
configurations to IPv4 and IPv6 specificity, if you haven't already done so. I can't remember when this came into 
effect, but it likely was Junos 16. We are on Junos 17 now.

Our longest circuit point-to-point is 140ms (Cape Town - London). These settings have been running fine on there since 
Day 1 (IOS XR-to-IOS XR), and overall detection and re-convergence of IS-IS + LFA leaves us happy and sleeping well at 
night.

Mark.


This email is classified as Internal by Harivishnu Abhilash
Disclaimer: This electronic message and all contents contain information from Mannai Corporation which may be 
privileged, confidential or otherwise protected from discloser. The information is intended to be for the addressee 
only. If you are not addressee, any disclosure, copy, distribution or use of the contents of this message is 
prohibited. If you have received this electronic message in error please notify the sender immediately and destroy the 
original and all copies.