HI Rene,
Is this part of the ENCOR course? Although it was linked from the Intro to QoS page, this page isn’t included in the section under Services > QoS. Thought you’d like to know in case you wantedt o add a bookmark.
Thanks,
Hello Bhawandeep
If you take a look at the Cisco exam topics list for ENCOR, you’ll see that WRED and any type of specific queuing is not included in the ENCOR exam, so it hasn’t been included in the ENCOR course on the site. But thank you for mentioning it and having us check it out.
Laz
In the example below: If the packet transmitted is 47 which is above the min threshold of 20 why did it not drop packets?
class Transmitted Random drop Tail drop Minimum Maximum Mark
pkts/bytes pkts/bytes pkts/bytes thresh thresh prob
0 47/4972 0/0 0/0 20 40 1/10
1 0/0 0/0 0/0 22 40 1/10
2 0/0 0/0 0/0 24 40 1/10
3 0/0 0/0 0/0 26 40 1/10
4 0/0 0/0 0/0 28 40 1/10
5 0/0 0/0 0/0 30 40 1/10
6 0/0 0/0 0/0 32 40 1/10
7 0/0 0/0 0/0 34 40 1/10
Hello Network23
The value that appears in the first column, which is 47/4972 indicates the number of packets that have been transmitted and not the number of packets within the queue. Remember, a queue will begin to be used only when there is congestion. In this case, there is no congestion, thus there are no packets entering the queue, and thus there are no tail drops on the queue.
The numbers found in the first column are cumulative, and will continue to increase over time. Later in the lesson, you see there were a total of 14268 packets of which 23 experienced random drops.
I hope this has been helpful!
Laz
Got it. Makes sense. Also, Wred randomly drops packets when there is congestion but I thought it also does it as a proactive measure to avoid congestion. When documentation talks about a queue filling up I thought that even if the link is not congested but a particular class/queue is getting a good amount of traffic it would randomly drop packets as it starts to exceed the minimum thresholds and when it hits the maximum threshold. For example, let’s say we have a 1G link on a router interface and there is a class-map for bulk data traffic. The link is not congested but there is bulk data traffic exceeding the minimum threshold. In this scenario would WRED begin to randomly drop traffic in order to avoid possible congestion?
Thank you
Hello Network23
WRED is used as a proactive measure to avoid queue exhaustion, not congestion. When a packet arrives at an interface, if the interface is not yet at capacity, the packet will be served immediately. It will not enter the queue. A packet will enter the queue only if there is already congestion on the link.
Now documentation does use the term “congestion avoidance” but in actual fact, it’s “tail drop avoidance” that we are performing, for the purpose of ensuring that TCP connections will not go into slow start, thus slowing traffic down in general.
If you use a class map to limit traffic of a certain type on an interface, such as bulk traffic as you mention, then you are creating in essence, a situation where congestion would take place. It may not be congestion because you reach the physical limit of the interface, but the configured limitation you set yourself. If that takes place, then yes you can then configure WRED to function simultaneously. But again, congestion must occur before a queue begins to fill up.
I hope this has been helpful!
Laz
Appreciate the follow up and thanks for clarifying this. Always thought WRED was at work when there was no congestion in order to avoid it. I’m not sure if the term proactive should even be used since it only begins to randomly drop when congestion is already present. So the way I understand it congestion is considered to be that the either the physical TX or RX queue of the interface is at 100% utilized. Is that necessarily the case? Because if it’s avoidance then I’m thinking that it may be considering congestion to be nearing 100%. What are your thoughts?
Hello Network23
Yes, congestion will take place if you reach the TX or RX rate of the physical interface. But congestion will also take place if you yourself limit the allowable bandwidth using either policing or shaping. As I mentioned in my previous post, this too will cause a queue to begin to fill up… and in such cases, you can apply WRED.
What you are actually avoiding is the breakdown of TCP sessions, which can lead to extensive use of slow start, which in turn will cause network delay, which users may be perceived as network congestion. Remember WRED is only useful for TCP sessions and will help in alleviating TCP-induced network slowdowns…
The terminology used is not always clear, but if you understand the mechanisms behind the feature, and the reasoning as well, you can more clearly understand what is occuring.
I hope this has been helpful!
Laz
Got it. So just to sum up in my head what you are saying, when congestion hits even though one may have bandwidth guarantees configured on the policy taildrop will occur for that configured queue if it begins to exceed the configured bandwidth. However, wred can minimize the pain for that queue by randomly dropping packets as it exceeds the minimum threshold and when it hits the maximum.
Hello Network23
Not quite. Taildrop will occur only when the average queue depth reaches the minimum threshold.
Remember that a queue will only begin to fill up if congestion occurs on the link. Congestion will occur if traffic surpasses the physical speed of the interface or it reaches some policy that limits traffic on that link. Only then will the queue begin to fill up, and only when it reaches the minimum threshold will random drops start to occur…
Does that make sense?
I hope this has been helpful!
Laz
Yes it does and thanks again!
1 Like
I wanted to share this snippet of a policy that is applied to a 10G interface. This interface has never hit a congestion and it resides in a site that serves a backup. I was applying a new policy on this device on another interface and ran show policy-map interface on a different one because I wanted to see the output and noticed that there were random drop and tail drops for class default. This is strange because it has never been congested. Any thoughts on this? Below is the configuration for the policy-map. I scrubbed the name of the policy-map:
policy-map xxx
class realtime
priority percent 38
class call_signaling
bandwidth percent 2
class network_mgmt
bandwidth percent 5
class critical_data_1
bandwidth percent 15
random-detect dscp-based
class critical_data_2
bandwidth percent 10
class scavenger
bandwidth percent 1
class bulk_data_1
bandwidth percent 5
random-detect dscp-based
class class-default
bandwidth percent 24
random-detect
Hello Network 23
“Congestion” can be considered one of two things:
- When there are no QoS thresholds configured, congestion will occur when the traffic approaches and attempts to exceed the physical data rate of the interface itself.
- When there are QoS thresholds configured (such as the
bandwidth percent 24command in the class-default config in your post), and those thresholds are approached and exceeded, we can consider this “congestion” although it is based on a limitation that you have administratively defined.
So in your case, this 10G port may never have reached its physical threshold, but it will have reached one or more of the thresholds set up in some of the classes in your policy-map configuration shown in your post. When it does reach those percentages, WRED will indeed kick in.
I hope this has been helpful!
Laz
Hello,
That could explain why there were still drops with no link congestion. The other strange thing is that I would have expected that class to pull from other classes since the bandwidth is available.
Hello Network23
According to this Cisco documentation, the random-detect command will start packet dropping based on the maximum count configured within the class. WRED does not “borrow” bandwidth from other classes, even if it is available.
I hope this has been helpful!
Laz
What I meant to say is that a class can use bandwidth from other classes if there is available bandwidth but that would only occur during times of congestion.
Thanks for following up on the documentation. Could you send me the link to that doc? Appreciate it and have a great weekend!!!
Hello Network
I apologize, I forgot to add the link! I was looking for it but was unable to find it. I think I may have found it somewhere in this command reference but I was unsuccessful in locating it…
I’ll keep looking, and let you know if I find it…
Laz
Hi ,
There is one sentence that’s a bit confusing, you mentioned :
The MPD (25%) is the number of packets that WRED drops when we hit the maximum threshold (45)
As per my understanding, if we hit the maximum threshold … all packets will be dropped, so what exactly is the function of MPD here ?
Thanks
Hisham
Hello Hisham
Yes, I see your confusion. I believe that this will clarify what is meant by this sentence:
For the specific example in the lesson:
- for average queue depth values between 0 and 20, there are zero drops.
- for average queue depth values between 20 and 45 there is an increasing number of drops depending upon the queue depth.
- for average queue depth values exceeding 45, all packets are dropped.
For queue depth values between 20 and 45, the percentage of dropped packets goes from 0 to a maximum of 25%. The MPD is that value of 25%. This is also illustrated in the diagram in the lesson:
Indeed, as you say, for any value that exceeds an average queue depth of 45, all packets will be dropped.
I hope this has been helpful!
Laz
1 Like
I’ve read elsewhere where it seems to suggest that the bandwidth used when enabling WRED somehow influences the weight of the traffic matched in that policy-map, which seems to indicate that the more bandwidth is reserved, the less likely that matched traffic is to be dropped.
To put it into an example, if I were to match 2 classes of traffic in a policy-map: class A getting: bandwidth percent 50 & random-detect and class B gets bandwidth percent 30 & random-detect
Everything else equal, will traffic matched in class A be less likely to be dropped?