[j-nsp] Network-control queue counter increases on ccc-configured interface

[Keegan Holley]

>
>> That's not exactly accurate. Cisco's kit also has some queuing setup
>> by default.  The details vary by platform.  Every cisco router I've
>> worked with defaults to trusting incoming markings rather then
>> rewriting them to best effort.  So the cisco default is vaguely
>> similar. Also, in order for someone to take advantage of this queue
>
> No cisco router does this to my understanding, some cisco routers use TOS
> values in punt path by default in attempt for rudimentary CoPP. But no
> Cisco that I know or have tested has different transit scheduling per class

The 6509 and the other L3 switch platforms (not sure about the nexus)
come to mind here.  Not sure about the CRS and ASR-9k though.
>
>> network control so I doubt someone is being malicious.  They look like
>> periodic hello's from something which is why I cautioned against
>> flattening the network.
>
> Either you control who can congest this class, or you shouldn't use it. As
> if it is not used, then dossing the service relying on the 5% NC is
> trivial, compared to all traffic being BE.

I agree it's best practice to control it.  I was just saying it's not
much of an attack vector.

>
>> I can't see this being a huge risk.  Most of your upstreams will
>> remark on ingress and not hand you traffic tagged with NC.  If you are
>
> I know that we don't do it, we never touch or trust TOS, we view it as
> customer property and cleanly pass it over INET (maybe customer wants to
> use them inside their LAN and signal it still over INET).

You can't not touch and not trust traffic at the same time.  You trust
it, in which case you're doing the same thing you suggest the OP
avoid, in that you can't control who's putting what traffic in your
queues.  If you don't trust then you have to remark to control what
queues each type of traffic is placed in.  You can also map all
markings to a single queue but that would defeat the purpose of
marking traffic in the first place.
>
> If you run MPLS network this is easy, if you don't have labeled forwarding,
> there is no option but to reset incoming TOS value in peering/transit, if
> you are doing any Qos (which in case of JNPR default you are).

You can always re-write the QOS bits incoming no matter what protocol you use.