Cisco QoS

There's lots of talk about Quality of Service (QoS). It lets you adjust traffic flow to give priority to some traffic, and limit others. It's not the magical cure to network issues, that some people think it is. It's more like overdraft protection on your bank account: it's good for those little emergencies, but you do not want to depend on it. If your QoS is constantly adjusting packets to compensate for congestion or high latency, you need a better pipe.

That being said, here's how to set up a basic policy that will optimize various types of traffic.

QoS works on a two step process: classify packets then optimize their flow.

The policies like this get applied to the outbound traffic on the WAN interface of the router on each end of the connection. You need to know what the actual available bandwidth is on the link, not just what it's specified as. If you set the line rate in the policy to be higher than what the usable capacity is, the QoS policy will never kick in. With Cisco, the QoS policy is only activated during times of congestion.

A major problem with high-latency, low-bandwidth links like T1's is that small, time-sensitive VoIP packets get held up behind big data packets that take a long time to send. The solution is to break up the big packets, and interleave the voice packets. Part of the solution is to lower the IP MTU on the WAN interface of the router. Once this is done, big packets that come in to the LAN interface get broken up (fragmented) by the CPU, which mixes in the voice packets according to the priority statements in the QoS policy.

Traffic Classification

Depending on the software revision, you can identify traffic by almost any attribute. In the example below, the class-maps match on packets that have their DSCP values set, or ones that are of a certain protocol. In this case, I'm going by the assumption that the DSCP values are set by the device sourcing the packets (a phone in this example). Remember that I said above that this is applicable to traffic leaving the WAN interface. If a device isn't setting the DSCP values on packets, ingress policies can also be created which will identify packets and set the DSCP accordingly. I'm not going to cover that though.

class-map match-any DSCP-VOICE
 match dscp ef
class-map match-any DSCP-VOICE-SIGNALLING
 match dscp af41
class-map match-any NETWORK-CONTROL
 match protocol ospf
 match protocol snmp
 match protocol icmp
 match protocol telnet

The Inner Policy

There are two policies: inner and outer. The inner policy takes the traffic classes and allocates bandwidth to them. The outer allocates the total amount of bandwidth to the inner policy.

There are multiple actions that can be used when applying bandwidth to a traffic flow:

• Priority - "Priority" traffic is sent to the egress queue before all other traffic (in kbps). The priority is also a rate limiter, so during congestion, anything in excess of the value will be dropped. You'll want to be sure to have this high enough that you won't cause any packet drops, but not so high that you wont have enough bandwidth for any other traffic classes. That's called "queue starvation".
• Bandwidth - This is the traffic that's given the second-best treatment. It's given a reserved amount of bandwidth, like priority traffic, but it's packets aren't expedited through the queue. It's allowed to exceed the amount allocated, stealing it from unclassified traffic, providing the priority traffic has already been serviced.
• Police - This limits the amount of bandwidth a type of traffic can use.
• Unallocated - This isn't a parameter to configure, it's just the remaining amount of bandwidth that hasn't been assigned. Any unclassified packets get their bandwidth from this remainder.

policy-map CLASSIFY_TRAFFIC
 class DSCP-VOICE
  priority 1100
 class DSCP-VOICE-CONTROL
  ! Bandwidth values can be in kbps or percentages of the overall bandwidth
  bandwidth 100
 class NETWORK-CONTROL
  bandwidth 8

The Outer Policy

This policy defines the overall usable bandwidth on the interface, as it may be less than the interface's physical bandwidth. Note that the sum of the bandwidth values defined in the inner policy must not exceed this value. If you used percentages in the inner policy, they are calculated against this number.

The inner policy is embedded in this policy.

policy-map WAN_POLICY
 class class-default
  shape average 1300000
  service-policy CLASSIFY_TRAFFIC

The Interface Config

interface FastEthernet1
 description TO WAN CONNECTION
 ip address 10.10.10.2 255.255.255.248
 ! 600 is a value that I found works generally well.
 ip mtu 600
 ! These commands limit the number of packets that can be in the hardware transmit queue.
 ! This gives the CPU more control over which packets are sent over the wire first.
 tx-ring-limit 3
 tx-queue-limit 3
 ! Applies the policy to the WAN interface
 service-policy output WAN_POLICY
!