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-boun...@puck.nether.net> On Behalf Of > Mark Tinka via juniper-nsp > Sent: Friday, May 6, 2022 7:49 AM > To: juniper-nsp@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@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp