[j-nsp] BGP timer

Lee Starnes lee.t.starnes at gmail.com
Mon Apr 29 11:42:37 EDT 2024


Thank you everyone for the replies on this topic. For us, we would rather
keep a link down longer when it has an issue and goes down than to have it
come back up and then go down again. This is because the flapping is very
destructive to live video and VoIP. Having several diverse backbone
connections, we can tolerate having one down. This topic came up because we
have had one of our backbone carriers become problematic and the flapping
caused by their issues caused a lot of damage in terms of customer
relations. So certainly would want to let a failed link sit failed for a
little bit after it restores before bringing BGP back up.

As for BFD and stability with aggressive settings, we don't run too
aggressive on this, but certainly do require it because the physical links
have not gone down in our cases when we have had issues, causing a larger
delay in killing the routes for that path. Not being able to rely on link
state failure leaves us with requiring the use of BFD.

Again, thanks for all the replies everyone. I will check out the BFD
holddown.

-Lee

On Mon, Apr 29, 2024 at 5:43 AM Jeff Haas via juniper-nsp <
juniper-nsp at puck.nether.net> wrote:

>
> Juniper Business Use Only
> On 4/29/24, 02:41, "Saku Ytti" <saku at ytti.fi <mailto:saku at ytti.fi>> wrote:
> > On Sun, 28 Apr 2024 at 21:20, Jeff Haas via juniper-nsp
> > > BFD holddown is the right feature for this.
> >
> > But why is this desirable? Why do I want to prioritise stability
> > always, instead of prioritising convergence on well-behaved interfaces
> > and stability on poorly behaved interfaces?
>
> This feature is "don't bring up BGP on interfaces that aren't stable
> enough to
> let BFD stay up".  The intended use case is when you have an interface
> noisy
> enough that TCP can fight its way through keeping BGP up... enough, but not
> stable enough that you'd really want to forward over it.  The assessment
> for
> that is "BFD will go down in short order".
>
> > That is, if I cannot have exponential back-off, I won't kill
> > convergence 'just in case', because it's not me who will feel the pain
> > of my decisions, it's my customers. Netengs and particularly infosec
> > people quite often are unnecessarily conservative in their policies,
> > because they don't have skin in the game, they feel the upside, but
> > not the downside.
>
> People make decisions that are appropriate for their networks.  Using BFD
> on
> your BGP sessions is probably overkill *for you*.  Don't do that then.
>
> -- Jeff
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>


More information about the juniper-nsp mailing list