2012/1/26 Saku Ytti <[email protected]>: > 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. _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
