Re: [j-nsp] BGP timer

2024-04-29 Thread Mark Tinka via juniper-nsp
On 4/29/24 17:42, Lee Starnes via juniper-nsp wrote: 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

Re: [j-nsp] BGP timer

2024-04-29 Thread Lee Starnes via juniper-nsp
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

Re: [j-nsp] BGP timer

2024-04-29 Thread Jeff Haas via juniper-nsp
Juniper Business Use Only On 4/29/24, 02:41, "Saku Ytti" mailto:s...@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

Re: [j-nsp] BGP timer

2024-04-29 Thread Mark Tinka via juniper-nsp
On 4/29/24 09:13, Saku Ytti wrote: 100%, what Mark implied was not what I was trying to communicate. Sure, go ahead and damp flapping interfaces, but to penalise on first down event, when most of them are just that, one event, to me, is just bad policy made by people who don't feel the cost.

Re: [j-nsp] BGP timer

2024-04-29 Thread Mark Tinka via juniper-nsp
On 4/29/24 09:15, Saku Ytti wrote: You are making this unnecessarily complicated. You could simply configure that first down event doesn't add enough points to damp, 2nd does. And you are wildly better off. Perfect is the enemy of done and kills all movement towards better. Fair enough.

Re: [j-nsp] BGP timer

2024-04-29 Thread Saku Ytti via juniper-nsp
On Mon, 29 Apr 2024 at 10:13, Mark Tinka via juniper-nsp wrote: > It comes down to how you classify stable (well-behaved) vs. unstable > (misbehaving) interfaces. You are making this unnecessarily complicated. You could simply configure that first down event doesn't add enough points to damp,

Re: [j-nsp] BGP timer

2024-04-29 Thread Saku Ytti via juniper-nsp
On Mon, 29 Apr 2024 at 10:07, Gert Doering via juniper-nsp wrote: > The interesting question is "how to react when underlay seems to be stable > again"? "bring up upper layers right away, with exponential decay flap > dampening" or "always wait 15 minutes to be SURE it's stable!!!"... 100%,

Re: [j-nsp] BGP timer

2024-04-29 Thread Mark Tinka via juniper-nsp
On 4/29/24 09:06, Gert Doering wrote: Yes, but that's a slightly different tangent. If the underlay is unstable, I think we're all in agremeent that higher layers should not send packets there. It comes down to how you classify stable (well-behaved) vs. unstable (misbehaving) interfaces.

Re: [j-nsp] BGP timer

2024-04-29 Thread Gert Doering via juniper-nsp
Hi, On Mon, Apr 29, 2024 at 08:52:17AM +0200, Mark Tinka via juniper-nsp wrote: > Protocols staying up despite the underlay being unstable means traffic dies > and users are not happy. It's really that simple. Yes, but that's a slightly different tangent. If the underlay is unstable, I think

Re: [j-nsp] BGP timer

2024-04-29 Thread Mark Tinka via juniper-nsp
On 4/29/24 08:31, Saku Ytti via juniper-nsp wrote: 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? If I can pick just one, I'll prioritise convergence every

Re: [j-nsp] BGP timer

2024-04-29 Thread Saku Ytti via juniper-nsp
On Sun, 28 Apr 2024 at 21:20, Jeff Haas via juniper-nsp wrote: > BFD holddown is the right feature for this. > WARNING: BFD holddown is known to be problematic between Juniper and Cisco > implementations due to where each start their state machines for BFD vs. BGP. > > It was a partial