On 5/3/24 19:54, Lee Starnes wrote:
Hello Mark,
Thanks for asking. This is eBGP and the issue is that there have been
failures whereby the link does not fail, and thus can't track that
routes should be removed. BGP session has stayed up in some cases as
well, yet no traffic.
Yeah, if
Hello Mark,
Thanks for asking. This is eBGP and the issue is that there have been
failures whereby the link does not fail, and thus can't track that routes
should be removed. BGP session has stayed up in some cases as well, yet no
traffic.
On Mon, Apr 29, 2024 at 9:31 AM Mark Tinka via
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
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
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
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.
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.
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,
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%,
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.
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
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
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
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 motivation for BGP BFD strict:
On 2024-04-27 09:44, Lee Starnes via juniper-nsp wrote:
> Having difficulty finding a way to prevent BGP from re-establishing after a
> BFD down detect. I am looking for a way to keep the session from
> re-establishing for a configured amount of time (say 5 minutes) to ensure
> we don't have a
On Sat, 27 Apr 2024 at 14:29, Rolf Hanßen via juniper-nsp
wrote:
> at least for link flapping issues (but not other session flapping reasons)
> you could set the hold-time:
> set interfaces xy hold-time up 30
Since Junos 14.1 it has caught up with Cisco, and it has implemented
exponential
>
> I also find that BFD can cause more problems than it fixes if you go too
> aggressive with it !
>
Concur here. BFD has its uses in specific circumstances, but it's almost
always much better to rely on interface state change and hold-time up FOO.
On Sat, Apr 27, 2024 at 6:34 AM Sean Clarke
Only way to achieve something like this is either link hold-timer or event
script- depending on your requirement you can use one of the options
On Sat, Apr 27, 2024 at 12:45 AM Lee Starnes via juniper-nsp <
juniper-nsp@puck.nether.net> wrote:
> Hello everyone,
>
> Having difficulty finding a way
Hello Lee,
at least for link flapping issues (but not other session flapping reasons) you
could set the hold-time:
set interfaces xy hold-time up 30
This would delay the link to come up.
kind regards
Rolf
On 27/04/2024 12:34, Sean Clarke via juniper-nsp wrote:
Hi Lee
Would Flap
Hi Lee
Would Flap Damping fix it for you ?
I also find that BFD can cause more problems than it fixes if you go too
aggressive with it !
regards
Sean
On 27-Apr-24 9:44 AM, Lee Starnes via juniper-nsp wrote:
Hello everyone,
Having difficulty finding a way to prevent BGP from
Hello everyone,
Having difficulty finding a way to prevent BGP from re-establishing after a
BFD down detect. I am looking for a way to keep the session from
re-establishing for a configured amount of time (say 5 minutes) to ensure
we don't have a flapping session for a. link having issues.
We
21 matches
Mail list logo
