Mailing List Archive

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

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@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

On 5/7/22 16:32, Michael Hare wrote:
> 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 feedback, MIchael. Most appreciated.

For me, this somewhat amounts to what Cisco do with RPKI in IOS XE,
where they automatically apply policy based on RPKI state. I don't like
that at all. Things can get tricky between code upgrades when this
"automation" is broken, or changes with little to no documentation.

Mark.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp