Network traffic limitation is very useful concept, because it gives you the control of what critical application/traffic must be prioritized over others router ingress/egress. However it's a challenge to define traffic limitation rules and it's even more tricky to understand how they are applied on a real network. Show of hands...how many of you had to solve a problem with server, protocol or application performance even though overall switch/router interface utilization wasn't a problem? In such situation you're looking at QoS class packet drops in order to understand what's limited. That's certainly useful, but then you have to figure out how much you need to increase it, which turns into indirect mathematical formula: new QoS class % limitation = ((dropped packets/s + class speed limitation)/ class speed limitation) *100. Instead of wrestling with math- try out new NTA 4.1.1 Beta which displays QoS policing and shaping class utilization.

 

Before we jump to the beta, let me briefly go over QoS policing and shaping theory.

 

QoS Policing ("police" command)

 

Defines router interface Inbound and Outbound limitation and in case data is over limit it drops excess packets. Doesn't do any packet buffering. Configuration limit is in bytes.

 

Advantages: As it drops packets, it doesn't cause any packet delays in queue.

Disadvantages: Simply drops excess packet = data loss, affect TCP window sizes and reduce overall output rate capacity of impacted data streams with this policy (classes with drops in NTA).

 

Let's assume you've 75 MB/s limit on your bandwidth from ISP. The result of applying "police" command may looks like this:

 

Stream before limitationPolicingStream after the limitation
QoS with policing and shaping-original.pngarrow.pngQoS with policing and shaping-policing.png

QoS Shaping ("shape or traffic-shape" command)

 

Defines router interface (only) Outbound limitation and it buffers and queues excess packets.Configuration limit is in bits/s.

 

Advantages: less prone to data loss because of buffering.

Disadvantages: Likely to introduce packet delay because of buffering and queuing.

 

And the result of shaping policy may looks like this:

 

Stream before limitationShapingStream after the limitation
QoS with policing and shaping-original.pngarrow.pngQoS with policing and shaping-shaping.png

 

If you interested in more details (how to configure policing and shaping, Cisco has a good overview here: Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.2 - Policing and Shaping Overview [Cisco IOS Soft… ).

 

Now, how can you get that right hand part from the charts above? Well, NTA 4.1.1 beta brings support of QoS policy polling on Cisco devices. You may see not only limitation applied on your classes (bits or %) but NTA also tracks historical utilization of the post-policy class utilization in respect to the class limitation.

 

1) Install your NTA 4.1.1 beta - NOT ON YOUR PRODUCTION SERVER (we don't support upgrades from beta)

2) Add your CBQoS devices/nodes

3) Go to the CBQoS detail page.

 

What's new in NTA?

 

Limitations in QoS policy resources

beta_cbqos-limits.png

 

Post-Policy Class % utilization in respect to the policy settings

Go to the Edit of the "post-policy" resource and select "% of class utilization" from "Data Units" options:

beta_cbqos-limits-setting.png

 

Submit changes and the "Post-Policy" resource changes into this:

beta_cbqos-limits-history.png

 

What it tells you is your class "host_10.140.46.119" is in spike reaching to 60% of it's QoS limit. We also prepared the OOTB report "post-policy QoS" which contains the QoS utilization.

 

Many of you are certainly interested in running this on your network prior NTA 4.1.1 GA and that's why we have Beta program. Simply click on the enrollment button below and you'll get your NTA beta today.

 

button.png

As always, your feedback is more than appreciated (contact me directly michal.hrncirik Product Management)