I'm pulling my hair out trying to figure out why my priority queue is dropping traffic.
I have what I believe is a very simple QoS configuration. I have a 2821 running 12.4(22)T with the following policy map:
class-map match-all bearer
match ip dscp ef
class-map match-all signal
match ip dscp cs3
priority percent 15
bandwidth percent 10
This policy map is applied as an outbound service policy on a T-1 interface.
I flood the T-1 with 10 Mb/s of unmarked UDP traffic while I have a couple of pings running that are sending 60 byte CS3 and EF marked ICMP echo requests to a device on the far end of the T-1. There is no other marked traffic being sent.
What I expect is for the marked traffic to get through the congested link (with some added delay due to serialization). But virtually all of the marked traffic is dropped.
The CPU on the 2821 is near idle. There are no input queue drops.
Here's a picture (fixed-width font required) of the topology:
Sorry, those stats included marked traffic that was sent went the link wasn't congested. Here's is what it looks like for a two minute run. Drops in the priority queue are about 85%.
I must be misunderstanding how this is supposed to work. I thought that the system would protect buffers for the priority queue to insure that 15% of the T-1 bandwidth would be available for EF-marked packets. That doesn't seem to be the case.
Ok, do see the high drop rate, but they're still seem to all be no-buffer drops.
QoS should insure your EF and CS3 packets get sent if they're within their bandwidth allocations, but the no-buffer drops, I believe, is precluding them from making it to their outbound queue.
From you prior stats, your class-default FQ is likely using up all your buffers. For testing purposes, you might try changing class-default to FIFO or tuning your buffers. The latter might not work well since you're sending such a high rate of UDP packets. Any rate over your T-1 line rate is going to fill buffers. The former, FIFO, might not use as many buffers and keep from staving the EF and CS3.
Thanks very much for the response Joseph. You've hit upon the place my understanding is completely lacking.
I thought the creation of a policy map with separate classes created separate output queues. Specifically, I was expecting that there was a priority queue with some set of dedicated buffers that can't be drawn on by other classes.
If the priority queue draws from a common buffer pool and there is no restriction on who can draw from that pool (or how much), then any high rate spew (think DoS) can exhaust the pool and trash the traffic in the priority queue.
I thought this was exactly what QoS was supposed to prevent.
Yes, I too believe that different classes define separate output queues, but as for them having dedicated buffers, don't recall seeing documentation that notes they do and suspect they don't. If they don't, you're correct about the exposure to a DoS attack, but there are things we could do to protect the resource. For instance, we could police the inbound interface traffic that's going toward the WAN interface. The policer could be targeted to certain traffic types, like non-TCP, that can also generate this type of situation even when not an intentional DoS attack.
From your original post:
Class-map: class-default (match-any)
168667 packets, 213899049 bytes
5 minute offered rate 3052000 bps, drop rate 1629000 bps
This problem has been resolved. Happily, QoS does work as expected. The problem I was having is due to a bug in 12.4(22)T. A bug id has been filed: CSCsw98427
I dropped back to 12.4(15)T1 and the QoS behavior was as I had hoped: marked packets are given priority over unmarked packets such that there is no packet loss with marked packets when the serial link is flooded with unmarked UDP traffic.
Thanks to joseph for his responses. I'm trying to glue the remaining hair back in.
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...
This is actually a pretty cool feature, i didn't even know it existed until I was looking for a solution to advertise a subnet (prefix in BGP talk), only if a certain condition existed. This is exactly what conditional advertisements does
j ai une question j ai achete un routeur cisco 887VA-k9 , je le configuré avec la configuration ci- dessous
si je le lier avec mon pc portable sur l un de ses ports directement ça marche toute est bien ( la connexion internet + m...