01-13-2014 11:47 AM - edited 03-04-2019 10:03 PM
Hi there,
i have a question regarding the drop behavior in my QoS setup, especially because i want to implement a Scavenger queue for some big file transfers to protect some other critical applications.
Here is the configuration for the outgoing direction (incoming marking is done correctly and the right pakets/applications are in the right queue and are not part of this question):
----------------------------------
class-map match-any voice_rw
match dscp ef
class-map match-any gold_rw
match dscp af42
class-map match-any silber_rw
match dscp af32
class-map match-any scavenger_rw
match dscp af13
policy-map egress_queue_rw
class voice_rw
priority percent 25
class gold_rw
bandwidth percent 15
class silber_rw
bandwidth percent 30
class scavenger_rw
bandwidth percent 1
class class-default
bandwidth percent 29
interface Serial0/0/1
bandwidth 1024
service-policy output egress_queue_rw
----------------------------------
Traffic in the queue "silber_rw" (30%) should be protected from traffic in the queue "scavenger_rw" (1%).
As you can see in the following output of the outgoing policy there is congestion on the serial interface and traffic in both queues is more than the configured guaranteed minimum bandwidth.
Why are there drops in the queue "silber_rw" and NO drops in the queue "scavenger_rw"?
sh policy-map inter s0/0/1
Serial0/0/1
Service-policy output: egress_queue_rw
queue stats for all priority classes:
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0
Class-map: voice_rw (match-any)
0 packets, 0 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: dscp ef (46)
0 packets, 0 bytes
30 second rate 0 bps
Priority: 25% (256 kbps), burst bytes 6400, b/w exceed drops: 0
Class-map: gold_rw (match-any)
0 packets, 0 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: dscp af42 (36)
0 packets, 0 bytes
30 second rate 0 bps
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0
bandwidth 15% (153 kbps)
Class-map: silber_rw (match-any)
44974 packets, 47207246 bytes
30 second offered rate 599000 bps, drop rate 5000 bps
Match: dscp af32 (28)
44974 packets, 47207246 bytes
30 second rate 599000 bps
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 39/841/0
(pkts output/bytes output) 44133/46028582
bandwidth 30% (307 kbps)
Class-map: scavenger_rw (match-any)
8968 packets, 8906597 bytes
30 second offered rate 362000 bps, drop rate 0 bps
Match: dscp af13 (14)
8968 packets, 8906597 bytes
30 second rate 362000 bps
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 53/0/0
(pkts output/bytes output) 8968/8906597
bandwidth 1% (10 kbps)
Class-map: class-default (match-any)
33442 packets, 8655798 bytes
30 second offered rate 55000 bps, drop rate 0 bps
Match: any
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 33555/8657634
bandwidth 29% (296 kbps)
Many thx for your answers.
Norbert
01-13-2014 04:58 PM
Disclaimer
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.
Liability Disclaimer
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.
Posting
It could be the behavior of the silber_rw traffic. I.e. more "bursty".
Silber_rw also has about the same bandwidth allocation as class-default. Although the latter isn't using much bandwidth, they would compete equally for bandwidth. So, again, if silber_rw is more bursty, and queued class-default traffic would delay how fast silber_rw dequeues a burst.
You might try increasing silber_rw's queue allocation.
01-15-2014 01:42 AM
The bursty traffic was also my first thoughts, but why is it over a "longer" period of time (up to 20 seconds i think).
I will try to reproduce the problem in a lab scenario.
Maybe i should implement WRED to worse the scavenger queue...
01-15-2014 03:20 AM
Disclaimer
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.
Liability Disclaimer
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.
Posting
Well realize what might be happening. For example, silber_wr bursts so quickly, the bandwidth, with or without scavenger traffic, is insufficient to handle the burst before there are tail drops. If the silber_wr traffic is rate adaptive, if will then slow its transmission rate. The former would then account for the drops and the later the lower average transmission rate. The way to test this, would be to not have any scavenger traffic.
The scavenger traffic's bandwidth demand is such that its transmission rate and queues are such it doesn't overflow. Also, depending on the client's TCP stack, it might be adjusting its transmission rate based on RTT.
If you look carefully at your OP stats, you'll see both silber_wr and scavenger have queued packets, 39 and 53 respectively. With such queue depths, especially for scavenger, it's actually more surpising the latter hasn't recorded any drops.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide