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

[Keegan Holley]

2012/1/26 Saku Ytti <saku at ytti.fi>:
> On (2012-01-26 10:52 -0500), Keegan Holley wrote:
>
>> stable.  I wouldn't use the NC queue for other traffic if you can
>> avoid it and I wouldn't make this traffic best effort without figuring
>
> Yet in INET facing router, jnpr default 95/5 split causes just that, any
> user in Internet can get special 5% of privileged capacity from your
> network.
> Which is strictly different from csco default, which is 100% BE.

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
they would have to get across you're upstreams which means they are
doing the same thing.  It would then be your fault for not remarking
traffic on ingress.  It looked like only 832 packets came in as
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.

I would still hesitate to do a way with queueing all together on the
interface.  The NC queue doesn't use any bw when it's empty and it may
save you from problems if there is congestion in the future.
Admittedly, this practice was started when the world had much lower
bandwidth links.
>
> Now one could argue, that if you care about QoS enough to change the
> config, more planned approach than jnpr or csco default should be pursued.
> But at very least you'd probably want to to guarantee that transit and
> peering interfaces cannot inject arbitrary amount of traffic to your !BE
> queue.

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
large enough not to have upstreams then you shouldn't be getting your
QOS policy from a news group.  I think marking most traffic down to BE
and leaving the default queues would be fine for most networks unless
you have a specific plan.  Most networks should have a specific plan
here, but ymmv.  I would hesitate to flatten everything to BE though
for the reasons stated above.

>
> Given that I'd need to implement QoS strategy from scratch, and that I'd
> want to use only 8 values, so I can carry my QoS in EXP/801.1p, I'd do
> something like this in core (SP focused):
>
> 0 -> normal INET       (e.g. transit customer traffic)
> 1 -> worse than normal (e.g. offsite tape backup)
> 2 -> important INET    (e.g. traffic to own ASN, instead of transit customer)
> 3 -> normal VPN        (e.g. 0 received from CPE is reset to 2)
> 4 -> preferred         (e.g. software required to work at office)
> 5 -> priority          (e.g. voice+video, [5 is default in many phones])
> 6 -> high demand       (e.g. internal pstn trunks etc)
> 7 -> network control   (e.g. IGP, LDP, iBGP, MGMT)
>
> 0         received from INET customer CPE is reset to 2
> 0         received from VPN/ customer CPE is reset to 3
> 7,6       received from INET/VPN customer is reset to 5
> 2,3       received from iNET/VPN customer is reset to 4
>


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.