MQC Weighted Random Early Detection


You are the VoIP specialist at the ISP you are working for. To ensure all VoIP traffic has enough bandwidth and low delay you have to implement some Quality of Service settings. You read some information about TCP synchronization and windowing. You have a lot of HTTP traffic on your network and you are wondering if random early detection could help you to slow down those HTTP packets…let’s kick some IP packets in the bucket!


  • All IP addresses have been preconfigured for you.
  • Configure an inbound policy on router Prio to classify and mark HTTP packets with the DSCP AF41 value.
  • Configure an outbound policy on router Line to start dropping HTTP packets when the queue size is between 8 and 32 packets. Once the queue is reaching the maximum you should drop 1 out of every 8 packets.




Weighted Random Early Detection

Video Solution:

Configuration Files

You need to register to download the GNS3 topology file. (Registration is free!)

Once you are logged in you will find the configuration files right here.

Opt In Image
Do you want your CCNA or CCNP Certificate?

The How to Master series helps you to understand complex topics like spanning-tree, VLANs, trunks, OSPF, EIGRP, BGP and more.

Written by René Molenaar - CCIE #41726

You May Also Like

About the Author: Rene Molenaar

René - CCIE #41726 is the creator of where he shares CCNA, CCNP and CCIE R&S labs. He also blogs about networking on


  1. I used the access-list because a match on port 80 will be enough to match the class-map. NBAR and ‘match protocol http’ will also work but the problem will be the payload. If you telnet to port 80 you’ll have a different payload than a real user with a web browser so yes your suspicion is correct 🙂

    In my labs I like to use access-lists because they always work.

  2. I noticed that you use ACL’s to match on TCP info when classifying the traffic.

    I tried to use “match protocol http” instead but my http traffic wasn’t being recognized when I checked my policy-map. However, it was recognized when i checked “ip nbar protocol-discovery”.

    I’m wondering the class-map didnt recognize it. I’m thinking GNS3 doesn’t create payload traffic. What do you think?

    1. The command to increase the amount of bandwidth available for QoS allocation is "max-reserved-bandwidth" configured under an interface. Default is 75% and Cisco does not recommend increasing it. So there are really three solutions to your bandwidth conflict (I got the same error for the same reason):

      1. Increase interface BW
      2. Reduce policy-map BW
      3. Increase max-reserved-bandwidth

  3. To generate congestion you needn’t use real hardware routers with serial links between them. You could use a shaper with small CIR and also you could connect your GNS3 to your PC and generate a real large traffic. For example I implemented two virtual PC and GNS-network was between those virtual machines. One of them had HTTP-server and another PC started download large-size file as a result congested was occured and WRED was starting to drop packets. If you want to watch how tail drop works you should reduce queue size to min 1 max 2 packets.

Comments are closed.