We ran this very config in production while we still had asr9k. It is slightly confusing as 0, 1 and 2 on CLI are not same in Tomahawk, in HW they are well ordered. But in CLI unconfigured 0 is worst, 1 is best and 2 is middle, so can be confusing if you debug in HW level to see where packets are going. ++ytti ________________________________ Lähettäjä: Lukas Tribus <lukas@ltri.eu> Lähetetty: Wednesday, 05 August 2026 22:32:26 Vastaanottaja: Saku Ytti <saku@ytti.fi> Kopio: North American Network Operators Group <nanog@lists.nanog.org>; Job Snijders <job@bsd.nl> Aihe: Re: how about a well-known DOWNGRADE BGP Community? (Was: RTBH Support Across the Industry)
You set 'priority level 1' for NC+AF, 'priority level 2' for BE, and leave LE unset on the ingress policy.
This sets the fabric priority, and VoQ will honor it.
I am very glad this is possible on the 9k. Are you certain there are no negative consequences moving the entire BE traffic into a fabric priority queue (back-pressure, etc)?
Mind you, in your scenario, even without ASR9k priorities, the network is protected. [...] Even if ASR9k congests the victim (which it shouldn't with the right priority level), the rest of the core is protected, so the blast zone is still just the victim.
The *transit* network is technically protected. But the incentive for the *customer* network to actually announce the scavenger route is gone. If the transit network is injecting a scavenger route itself without involving the customer, sure, then this makes sense for the benefit of the transit network. But more likely the transit customer already switched to RTBH instead anyway. I'm happy to hear this is possible on the 9k. Lukas