[j-nsp] bgp graceful-shutdown receiver

[Michael Hare]

Mark,

I was told by JTAC that the 19.1 default "'set protocols bgp graceful-shutdown receiver" does exactly that [blindly trusts 65535:0 as zero] for iBGP learned routes, but not eBGP.  Unless I'm daft that's not what their public documentation implies.

A set command that means "no really, I want 65535:0 to mean localpref=X for whatever group hierarchy I configure said feature" might be neat.  It would have saved me a few hours as I am a tool assisted CLI jockey, not fully pushing from a database.  But the ship has long since sailed as I ended up changing my import/export policies instead.  It was a worthwhile endeavor anyway as I also incorporated prepending and MEDs as part of our outbound shutdown approach.

Thanks for the reply,
-Michael

> -----Original Message-----
> From: juniper-nsp <juniper-nsp-bounces at puck.nether.net> On Behalf Of
> Mark Tinka via juniper-nsp
> Sent: Friday, May 6, 2022 7:49 AM
> To: juniper-nsp at puck.nether.net
> Subject: Re: [j-nsp] bgp graceful-shutdown receiver
> 
> 
> 
> On 4/18/22 17:24, Michael Hare via juniper-nsp wrote:
> > Hello,
> >
> > Is anyone using "bgp graceful-shutdown receiver" successfully out-of-the-
> box for eBGP peers without modifying their import policies to account for
> 65535:0?
> >
> > For example our production AS peers with lab AS over eBGP.  Import policy
> on the production side sets local preference.  "I was assuming" that the
> reception of 65535:0 would set localpref to 0 and that's not what I see.  JTAC
> is claiming this is expected and that any import policy that sets local
> preference will override having graceful-shutdown receiver enabled.
> >
> > Yes, I have confirmed gshut is enabled and I am indeed receiving 65535:0.
> If I change my import policy to match 65535:0 and set local pref to 0, it
> unsurprisingly works.  Thankfully I have disaggregated the terms that accept
> a route from those that set local preference so I'm just looking at a major
> annoyance instead of major pain, but I find this a bit unbelievable as a default
> behavior.  But perhaps I'm missing the concept of why the hook to set
> localpref appears to be at start of policy evaluation and not after route
> acceptance inside RPD.
> 
> My understanding is that 65535:0 is "universally" accepted across eBGP
> neighbors to signal LOCAL_PREF=0. However, receiving operators need to
> setup the policy infrastructure to make that happen.
> 
> I'd find it rather odd if a vendor automatically changed the LOCAL_PREF
> to 0 for a route that shipped with 65535:0, without the operator
> specifically pre-defining the policy infrastructure to support that. I
> certainly wouldn't want that from my vendor.
> 
> Unless I am missing something...
> 
> Mark.
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp