Scenario:
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!
Goal:
- 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.
IOS:
c3640-jk9s-mz.124-16.bin
Topology:
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.
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
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.
Great! Thanks for the info!
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?
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
Hi ReneMolenaar !
I saw you to config WRED. i think you config is ok, but you can not test it because if you replace fastethernet by serial, then WRED will still not operate. The reason for WRED can not run, because in GNS 3 you can not test QoS in some case.
Please read the article : http://cisconinja.wordpress.com/2009/01/19/testing-queueing-strategies-with-dynamips/
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.
Final config points to startup config.