Internet QoS

Congested Internet links are a common problem within many organizations. Because these Internet circuits carry business oriented traffic, as well as casual web surfing, we need to come up with a way to separate traffic into different queues as well as guarantee bandwidth minimums for the mission critical traffic. You can do this by purchasing an appliance, such as a Kentrox, or by using some features within your existing Cisco ISR router. I'd like to look at the latter because budgets are always tight, and this method is free!

One point before we get started, QoS policies should not be viewed as a solution for a sustained/regular lack of bandwidth. It is a solution for sporadic bouts of congestion.

Below is a common topology that exists in many small organizations. The key point to note is that our link is congested inbound, the drops are happening at the ISP interface, rather than our interface. Traditional thoughts and methods for QoS don't work here. You normally configure QoS on both sides of a link, but we don't have any influence on the ISP configuration.



The Internet connection to the ISP is the most common congestion point. For a little added complexity, let's assume this is an Ethernet interface where actual bandwidth purchased is not equal to the autonegotiated link speed of the interface. This adds complexity because we can't just make a QoS policy-map that allocates bandwidth minimums because the router will never think the link is congested to apply the bandwidth minimum, because the ISP is capping our bandwidth. For example, we have purchased a 10 mbps circuit, but the link has autonegotiated to 100 mbps. The router won't apply/enforce the bandwidth minimums until the link utilization hits 100 mbps, but the ISP will police our traffic at 10 mbps. We want to control the drops, so we can intelligently drop, rather than indiscriminately drop.

How do you control the dropped packets that happen at the ISP interface? This Internet circuit is a bottleneck, and we only control one end. What if we make a slightly smaller bottleneck, inside of our network, so we can control what is dropped? By creating this smaller bottleneck, our ISP circuit should normally be just under the purchased capacity of 10 mbps, this means they shouldn't need to drop anything. Yes, this will leave some bandwidth unused on the Internet link, but it will be insignificant when you consider the control you're gaining. This assumes that the primary traffic type is TCP, rather than UDP, because TCP should back off when it encounters dropped packets. If your traffic is primarily UDP based, this solution won't help.

The best way to introduce this bottleneck is with a shaper. If the router doesn't transmit more than 9.75 mbps in either direction, the router can decide what to drop.




Inside of this shaper, we're going to classify traffic based on access lists and guarantee a minimum bandwidth allocation per traffic class.

Let's start by creating a few access lists, these will match our high priority traffic. Use a separate access list to identify the different tiers of traffic. The 3 tiers of traffic have been identified and will be a remote IPSEC VPN, a business application, and some video conferencing. Because we are going to apply the same policy in 2 different directions, we need to account for the source and destination addresses being flipped.

ip access-list extended QoS_Tier_1
permit ip any host [Insert Real IP #1]
permit ip host [Insert Real IP #1] any

ip access-list extended QoS_Tier_2
permit ip any host [Insert Real IP #2]
permit ip host [Insert Real IP #2] any

ip access-list extended QoS_Tier_3
permit ip any host [Insert Real IP #3]
permit ip host [Insert Real IP #3] any

Now that we've identified the traffic with an access list, we need to create a traffic class. A traffic class is defined by the match criteria in class-map, in this case it's an access list.

class-map match-all QoS_Tier_1
description ** Remote VPN **
match access-group name QoS_Tier_1

class-map match-all QoS_Tier_2
description ** External Business Web App **
match access-group name QoS_Tier_2

class-map match-all QoS_Tier_3
description ** VideoCon **
match access-group name QoS_Tier_3

Next, we need to create the QoS policy that will allocate the bandwidth minimums for each class of traffic. That is done with a policy-map. All of the traffic not matched in the above 3 classes will be included in the class-default class, which will use CBWFQ (class-based weighted fair queueing).

policy-map Match_Traffic
class QoS_Tier_1
bandwidth 3000
class QoS_Tier_2
bandwidth 1000
class QoS_Tier_3
bandwidth 1500
class class-default
fair-queue 1024

Next we need to create the 9.75 mbps shaper and nest the above bandwidth allocations inside of the shaper. If you do other things on this router, like export netflow data to the inside, you may want to create some specific classes so they aren't subject to the shaper. You don't want that traffic to be matched by the class-default class.

policy-map Shape_Out
class class-default
shape average 9750000
service-policy Match_Traffic

Next, apply the policy-map to your router interfaces.

interface FastEthernet0/0
description ** To ISP - Circuit ID:123456789 NOC:xxx-xxx-xxxx**
service-policy output Shape_Out

interface FastEthernet0/1
description ** Internal Firewall - Eth 0/0 **
service-policy output Shape_Out

When you're done, you should verify the policy map is applied to the interface and is matching the traffic correctly.

show policy-map interface FastEthernet0/0
show policy-map interface FastEthernet0/1

With the above show commands, you will be able to collect statistics about how much bandwidth is used for each traffic class. You may need to go back and tune your bandwidth allocations depending on your tolerance for drops within those traffic classes.