Mind you, in your scenario, even without ASR9k priorities, the network is protected. DoS -> IngressPE -> Core1 -> Core2 -> ASR9k -> Victim As the victim prefix has community, IngressPE sets the LE QoS bits. Each hop egress side stops congesting the far end ingress side 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. Having said that, of course to do QoS, you need a device which has QoS. That feels tautology, but I think it needs to be said. If any reasonable definition of QoS works, this works. Your congestion scenario is reserved, as far as I understand - ASR9k does not have VoQ priorities set properly - There is speed step-down from core->victim Both of these need to be true, for the issue to happen. Bigger, imho, concern in ASR9k is that you cannot do volumetric egress ACL, and here priorities won't help you. If a customer gets bad traffic, which you can easily ACL off in egress direction, it does nothing for you. And while this is a fundamental problem in VoQ platforms, rest of the platforms, like PTX, actually return credits to ingress, if egress drops them. ASR9k you just need to exceed egress capacity by trivial percentage (not 2x) in PTX you need a large multiplier, before you congest the credit-return mechanism. ASR9k is basically a really cheap and stupid pipeline box disguised as an SP edge device, with software complexity that is too high for Cisco to manage. This is not hyperbole, I've repeatedly had to tell TAC how ASR9k works, because they've closed NOC tickets with obviously incorrect answers. One particular issue which TAC worked on for months, was us dropping customer BGP sessions, and TAC claiming the problem is our egress QoS, despite LPTS packets not being subject to either QoS or ACL. On Wed, 5 Aug 2026 at 09:22, Saku Ytti <saku@ytti.fi> wrote:
On Wed, 5 Aug 2026 at 00:01, Lukas Tribus <lukas@ltri.eu> wrote:
Take an ASR9000 for example. A basic implementation that sets a ingress qos-group/cos/dscp/exp bit for the attacked /32 and has an egress queue configurations which deprioritizes scavenger traffic can do nothing in a DoS situation.
I don't think this is true.
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.
-- ++ytti
-- ++ytti