QoS Traffic Shaping Explained

Lessons Discussion
83

Hello Ahmedlamad

What you have shared in your post is an image of several indicators that pertain to a particular PRTG sensor. Because PRTG has hundreds of sensors, and because they sometimes uses somewhat different terminology from Cisco, I can’t definitively tell you the meaning of these indicators without telling me the specific sensor that you are using here.

In any case, it looks like it’s a sensor that displays information about a particular policy that has been applied to specific traffic. If this is the case, then the meaning of each of these indicators are as follows:

  • Pre Policy Size: This likely represents the volume of traffic entering the network device before any policies are applied. The value of 8,301 Mbit/s indicates the current incoming traffic rate before any rules or limits are enforced.
  • Post Policy Size: This shows the volume of traffic after the application of the policies. The value here is the same, so it seems that the policies have not affected traffic at all. It could be that any configured thresholds have not been reached, so traffic is traversing the network device unaffected by the configured policies.
  • Drop Packets: This refers to packets that have been intentionally dropped as a result of the configured policies. The fact that there are zero dropped packets simply indicates that no policies have been triggered that cause a packet drop. This is in accordance with the fact that the pre and post policy sizes are the same. The unit of measure here is the number of packets per second.
  • Drop Size: Where Drop Packets indicates the number of packets dropped per second, the Drop Size indicates the total size of data dropped within those packets per second, measured in Mbit/s.

So the indicators here show the behavior of traffic based on the configured policies.

I hope this has been helpful!

Laz

1 Like
84

Thanks, indeed your explanation is very Helpful as usual,
But as conclusion, should we have drop packets here, cuz as i have mentioned i use shaping technic to limit the interface as policy shared as follows, it will be buffered or dropped?

policy-map TEST
 class class-default
  shape average 11800 mbps 
 ! 
 end-policy-map
!
85

Hello Ahmedlmad

If you are using shaping, the device will attempt to buffer all traffic that exceeds an average throughput of 11800Mbps. Packets will not be dropped but will be buffered. If you were using policing, then exceeding traffic would be dropped.

Just a comment on the syntax you’re using. Unless you’re on another platform I am unaware of, the shape average command requires this syntax:

R1(config-pmap-c)#shape average ?
  <1000-1000000000>  Target Bit Rate (bits/sec). (postfix k, m, g optional; decimal point allowed)
  percent            % of interface bandwidth for Committed information rate

The value is in bits unless you add a “k” (for Kilobits/s), an “m” (For Megabits/s), or a “g” (for Gigabits/s). Your syntax would not be accepted. Even if it were, 11800 Mbps is 11.8 Gbps.

So even though the shaping command is implemented, at a pre-policy size of 8301 Mbit/s, the shaping will not kick in if it is set to 11.8Gbps. Does that make sense?

I hope this has been helpful!

Laz

1 Like
86

Hello Dear laz,

yes here the M stand for megabit, the image or the platform i use is Cisco, as showing following syntax,

image
image1322×158 3.99 KB

regarding the pre policy rates i have shared earlier that was because the traffic was not loaded at full capacity, while at peak hours it reached more than 11800 and that’s why i was wondering about the exceeded packets .

Ahmed.

87

Hello Ahmedlmad

Ah that’s interesting. I’m using the IOSv 15.9(3)M6 on Cisco’s CML. The syntax is slightly different on your platform. What are you using?

Indeed, because your traffic only reached around 8Gbps while your shaping policy was set to 11.8Gbps, the pre and post-policy rates were the same, because you didn’t reach the threshold, and that makes sense.

Thanks again!

Laz

1 Like
88

Thanks Dear, yes it is cisco image called third party IOS XR 7.2.2 software.

Thanks fur your usual support.
Ahmed.

1 Like
89

Hello,

Very good lesson. However, I am not sure if there is some error in the formulas specified:

In the example that Rene uses, luckily , he is using kbps on the CIR, and he presents the formula: Bc = Tc * CIR. However, in reality the formula should be:

CIR (bps) = (1000 ms / Tc ms ) *Bc bits
or
CIR (bps) = (1 s / Tc s ) *Bc bits → CIR (bps) = (Bc bits/ Tc s)

so

Bc bits = (CIR bps * Tc ms) / 1000 ms
or
Bc bits = CIR bps * Tc s

because look at the following example:

CIR = 64 Mbps (64,000,000 bps)
Tc = 125 ms
Bc = ?

With Rene Formula:
Bc = Tc * CIR → Bc = 125 x 64 = 8000 (same as for CIR = 64 kbps??? not right) wihout specifying correct UNITS is impossible to get it right

the correct form of this will be:
Bc = Tc * CIR → Bc = 0.125 s x 64 Mbps = 8 Mbits

With proposed formula:
Bc bits = (CIR bps * Tc ms) / 1000 ms → Bc = (64,000,000 x 125) / 1000 = 8,000,000 bits or 8 Mbits.

Since the lesson says Cisco uses by default 125 ms, then the formula should be using ms, sothe above formula would be the correct one.

Like I said, in the lesson Rene is luckily using kbps, so:
Bc bits = (CIR bps * Tc ms) / 1000 ms → Bc = (64,000 x 125) / 1000 = 8,000 bits or 8 Kbits

Is important to include the UNITS in the formulas, otherwise it can be confusing.
Please correct me if I am wrong.

Thanks,
Jose

90

Hello Jose

Yes you are correct, getting the right units is important when calculating these formulas. The numbers as you suggested are correct in the lesson, but it may be helpful to explicitly write out the units that Rene is using. I will let Rene know to take a look and consider revising.

Thanks for your feedback, it is always valuable!

Laz

1 Like
91

Hello, everyone.

This is specified as one of the reasons to use shaping.

To prevent egress blocking. When you go from a high-speed interface to a low-speed interface you might get packet loss (tail drop) in your outgoing queue. We can use shaping to ensure everything will be sent (until its buffer is full).

Could someone please clarify this one more for me?

obrázok
obrázok799×343 3.24 KB

How will shaping prevent tail drop? If we’re receiving a gig worth of traffic, the 10 Mbit interface won’t be quick enough to send it all so it will be queued. If the queue fills up, it will be dropped.

Where exactly would we apply shaping here and what would it solve?

My second question is, what exactly is percentage-based shaping? It’s when we configure shaping by not specifically listing the bandwidth but only specifying a % value instead?

R2(config-pmap-c)#shape average percent 60

Does this work exactly the same as with classic shaping or are there any differences?

Thank you.
David

92

Hello David

The example you are sharing is an extreme case, which would result in a full buffer and many dropped packets. No amount of shaping will resolve this problem. Shaping doesn’t magically produce higher throughputs, but it takes advantage of the intermittent and bursty nature of traffic flow, and “smooths” it out so that all of the “idle time” is taken advantage of.

A more appropriate example would be a 24 port FastEthernet switch with a single GigabitEthernet uplink. If all 24 FastEthernet ports were receiving data and directing it to the uplink, that would result in 2.4 Gbps trying to use the 1Gbps uplink. But they don’t send data all the time. Sometimes they may send an aggregate rate of 1.5Gbps, other times 250 Mbps, other times 10 Mbps. Shaping takes advantage of these idle times by buffering excess traffic, and sending it when there is less traffic on the link. That’s the idea behind this statement.

This works exactly the same way as with classic shaping. It provides more flexibility in the way that it is applied.

For example, the percentage used is the percentage of the configured bandwidth parameter on the interface itself, so depending upon what you have configured there, the percentage is calculated. Also, you can use the same policy map for multiple interfaces with differing amounts of bandwidth instead of specifying a different policy map for such interfaces.

More info about this can be found here:

https://www.cisco.com/c/en/us/td/docs/ios/qos/command/reference/qos_book/qos_s1.html#wp1075917

and here:

I hope this has been helpful!

Laz