Sure, you could mitigate some of that with enforcing w/ever at the boundaries, but hopefully you are starting to see how a simple QoS policy design on a single node is blowing up into managing hundreds/thousands of ports and making sure you trust your VoIP telephone, but not the workstation behind it and so on. Then you have to make sure that all your cross connects, uplinks, etc. either trust your tags or inspect each packet and rewrite the tag (DSCP). Now you are managing QoS policies on every intermediary device if you decided to make uplink not trusted for w/ever reason. So in case of the single router that you want to apply your egress QoS onto if you chose not to manage your QoS downstream with trusted uplinks, inspection at boundary, etc, you’d have to classify on some other than DSCP info on ingress to your router and then make the egress decision. And thus, my original point is shown that you’ll be editing that policy every time your traffic patterns change or new application that needs a certain class of service is deployed. As usual, YMMV, but that’s my experience with QoS. Every time I tried it, it turned out to be more headache than just buying more BW.
Hope this helps Andrey On Thursday, November 10, 2016, Aaron <[email protected]> wrote: > Thanks Andrey, you mentioned ... "You could end up in a DoS situation > where some rouge source send 1gbps worth of packets matching your priority > class" > > Is this where a properly controlled QoS Trust Boundary comes into > play?...like not trusting what ingresses that boundary, classifying and > remarking... so that queue hijack can't occur ? > > - Aaron > > > > -- Sent from Gmail Mobile _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
