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

[Saku Ytti]

On (2012-01-26 12:32 -0500), Keegan Holley wrote:
 
> 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

> 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 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).

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).

> This is good for some, but it's hard to recommend a queuing policy to
> someone without understanding what they do with their network.  I've
> made due in the past with only 4 queues, especially when juniper pic's
> only had 4.

Yeah it maybe be more complex than absolutely needed, you can do lot with
4. And frankly if you need to start dropping in many classes, maybe you
should just upgrade your links.
Mainly what I'm driving for is that during INET sourced DoS most services
continue work. So even two classes can be good for most. But then, maybe
during this INET sourced DoS you want some INET stuff to continue working,
and via SCU/DCU it's easy to use like bgp community signalled recolouring
(say important/low risk customer will get better TOS and keeps working when
low importance/high risk INET sourced DoS)


-- 
  ++ytti