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.
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
!
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?
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 .
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.
