QoS in its simplest form is easy to follow, understand, and implement. Usually you need to go through a few steps to get QoS going:
Identify or Classify traffic. This will differentiate one type of traffic from another so that you can apply rules or policies appropriately.
Mark traffic. This essentially means to add a QoS marker or tag to traffic so that other devices can more quickly determine which policies to apply to it. This is usually done with DSCP or TOS or IP Precedence fields in data packets.
Apply policy to traffic. This entirely depends on the needs of the network, but many times includes bandwidth limits or guarantees to certain types of traffic such as voice traffic.
Here's a pretty simple QoS configuration:
First we identify traffic. In particular, the first class-map matches/identifies any traffic that is the RTP protocol. The second class-map identifies any traffic that is SIP, H323, or SKINNY which all happen to be voice control protocols.
Then we create a policy map that says what to do. The policy map in this example uses the classes we configured to identify traffic, and if traffic matches we set the DSCP value to EF of CS3.
class-map match-any MARKING-voice-traffic match protocol rtpclass-map match-any MARKING-voice-signaling match protocol sip match protocol h323 match protocol skinny!policy-map MARK-TRAFFIC class MARKING-voice-traffic set dscp ef class MARKING-voice-signaling set dscp cs3 !interface GigabitEthernet0/6 service-policy input MARK-TRAFFIC
This policy should be configured close to the edge devices themselves. Usually this policy is configured on the LAN interfaces in the inbound direction. This would mean that an IP Phone would send traffic into the LAN interface, and the policy would identify the traffic as voice and mark the packets as per the policy map. From there on out, all of the packets will include the DSCP marking so that other devices, such as routers, will know how to prioritize the traffic.
More Complicated Configuration: Multi-tier QoS
Multi-tier QoS, commonly referred to as nested QoS, involves having QoS policies configured within other QoS policies. Two tier QoS is very common, and fairly easy to follow the logic.
Let's consider a pretty common scenario: WAN connection with an Ethernet handoff. WAN connections are being handed off to customers as an Ethernet connection (as opposed to T1, DSL, Fiber, etc.) more and more and more nowadays. This is easy to work with, and doesn't require special cards or modules to be installed in customer routers.
But there is a non-optimal situation that occurs in many cases: the Ethernet speed and the circuit speed don't match. The WAN provider might present a 100Mbps Ethernet connection to the customer router, but the circuit could be limited to 50Mbps.
This is where tiered QoS comes in to play. To tackle this situation, the "parent" policy is configured to limit bandwidth to the speed the WAN provider allows on the circuit. Then you configure a "child" policy to be underneath the parent policy. This way, as traffic leaves an interface, it first goes through the parent policy to verify that it is within the parameters configured, such as a max speed of 50Mbps, and then it gets passed down to the child policy to further handle the traffic as seen fit by the administrator. Below is an example of a two-tier policy that limits traffic to 50Mbps, and within the 50 Mbps gives 2Mbps priority bandwidth to voice traffic:
! define a class that matches any traffic marked as EF or CS3class-map match-any VOICE match ip dscp ef match ip dscp cs3! Parent policy - limit traffic overall to 50Mbpspolicy-map ELAN-OUT class class-default shape average 50000000 service-policy ELAN-OUT-HEADEND! Child Policy - Give 2Mbps priority bandwidth to voice traffic, all other traffic gets a fair queuepolicy-map ELAN-OUT-HEADEND class VOICE priority 2000 class class-default fair-queue random-detect dscp-basedinterface GigabitEthernet0/2 description Ethernet WAN speed 100 duplex full service-policy output ELAN-OUT
There is a little more going on here. In this design, all traffic from a remote site will be sent through a centralized/head end router. The purpose behind this is to be able to control QoS in both directions, as explained by the article. Here's how the flow works logically: The 'grandparent' policy defines the circuit bandwidth allowed, the 'parent' policy matches traffic to a site by subnet and further limits bandwidth allowed based on the site, and the 'child' policy is configured to deal with specific traffic such as voice.
ip access-list extended BW permit ip any 10.167.8.0 0.0.0.255 permit ip any 10.168.8.0 0.0.0.255 permit ip any 10.6.129.0 0.0.0.255 permit ip any host 10.255.12.8class-map match-any VOICE-BW match ip precedence 5 match ip dscp ef match ip precedence 3 match ip dscp cs3 match ip dscp af31 ! Grandparent policy - limit the WAN interface (connected at a physical 1000Mbps), to the circuit speed of 400Mbps, then send that to the parent policypolicy-map ELAN-OUT class class-default shape average 400000000 account user-defined 18 service-policy ELAN-OUT-REMOTE! Parent policy - Match traffic to a particular site (via class which matches subnets). Apply a bandwidth limit and send that to the child policypolicy-map ELAN-OUT-REMOTE class BW shape average 10000000 service-policy BW-ELAN-POLICY class class-default fair-queue random-detect dscp-based! Child policy - give voice traffic 2Mbps priority bandwidth, and all other traffic gets a fair queuepolicy-map BW-ELAN-POLICY class VOICE-BW priority 2000 class class-default fair-queue random-detect dscp-basedinterface GigabitEthernet0/0/0 service-policy output ELAN-OUT
This policy can be greatly expanded upon. For starters, only one site was defined. To add more sites, more classes would need to be defined in the parent policy, and a child policy would need to be configured for each site. Each child policy could have many unique methods of splitting up the traffic further by defined classes. The way this policy was used in a real production environment had over a dozen sites and many other options configured; this example was reduced down to the necessary components to make it easier to read through and understand.
For those that may be wondering, 'Where is this 3-tier policy configured?', the answer is the head end routers. These are the only routers that need to be configured to handle multiple sites. Any remote site would need the more simple 2-tier QoS configuration as a remote site only needs to limit bandwidth to the circuit speed, and give priority to its own traffic.
QoS can be very simple in concept, and also easy and straightforward to configure. Depending on the situation, you may need to configure more complicated QoS in a multi-tiered fashion to properly control traffic. In a situation that includes a hub-and-spoke design with a WAN handoff that has an Ethernet handoff that has a different physical speed from the circuit speed, a 3-tier QoS configuration may be necessary to properly handle traffic.