I have a gigabit ethernet interface on a 2951 configured with 4x sub interfaces providing connectivity to our four WAN sites. Each sub interface services a 100mb connection to another site.
I have configured a QoS policy and attached to each sub interface with the primary function of limiting each sub interface to 100mbs. I am now seeing drops (total drops) on the class default and not sure why. I would not expect to see any drops on this interface as it never even reaches 15mb (15%) capacity.
Class-map: class-default (match-any) 175934881 packets, 95319007968 bytes 5 minute offered rate 23000 bps, drop rate 0000 bps Match: any
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
I would not expect to see any drops on this interface as it never even reaches 15mb (15%) capacity.
Your expectations might be incorrect. Often percentage of bandwidth capacity measurements are misunderstood.
Let's assume your ingress is 100 Mbps. Let's also assume your measuring over a five minute period. Lastly, assume the ingress transmits at 100% for 1 minute and then stops for 4 minutes. Bandwidth utilization across the 1 minute would be 100% and 0% for the other 4 minutes, but it would be 20% for the 5 minutes.
But if the 100 Mbps was sent at 100% for each 12 seconds, and not sent for each 48 seconds, 5 minute utilization would still be 20% but unlike the prior 1 minute stats of 100% and 0%, each minute would now also be 20%.
So these first two examples show how bandwidth utilization don't reveal what's happening within the measured time period.
Since ingress was same bandwidth as egress, in the above, there would be no queuing.
If ingress is gig, though, suppose gig ingress arrives for 6 seconds and stops for a remaining 4 minutes and 54 seconds. This too would measure as 20% usage across 5 minutes, but since it will take 60 seconds to transmit the same traffic at 100 Mbps, packets will need to be queued. If queuing buffers are insufficient to hold all the packets, some will be dropped.
The above is a long way of saying, if your ingress rate exceeds your egress rate, there can be a need to queue packets, and if queuing is insufficient, packets will be dropped, this even if utilization is "low". Most likely, you have occasional "bursts" if ingress bandwidth exceeds the egress bandwidth.
From your actual stats, the drop rate percentage is so low, you might not need to concern yourself with the few drops you're seeing. If it is a concern, you might be able to reduce the drop rate by increasing egress buffering, but doing so, also increases egress queuing delay.
This document gives several answers on frequently asked questions for PFRv3 channel state behavior.
Q1: What are all the channel operational states from a BR (border role) perspective and what are the rules/conditions to be in each st...
The need was to reach an host inside a LAN through a VPN connection managed by the LAN gateway (Cisco 1921).
The LAN gateway performs NAT and there was a dedicate nat rule for the host i wanted to reach through VPN.
I couldn't connect to the hos...
We have 3 identical switches configured by someone else and would like to claim some of the Gigabit ports(G1/G2/G3/G4) for use on servers. When we try to change the wiring and configuration, we run in to connectivity issues. Attached is a des...