L2 WAN 3-Tier QoS - Hub-n-Spoke

In a previous article, L2-WAN-Routing-Design-for-QoS-Hub-and-Spoke-Using-EIGRP-Distribute-list-with-Route-map, a network design was made to route traffic through a head end (hub) for QoS control. This design was necessary to ensure that the ISP did not enter the equation when it comes to QoS. The following will explain the 3-tier QoS configuration that was used and reasoning behind it.

Simple QoS

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 rtp
class-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

Select all Open in new window

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 CS3
class-map match-any VOICE
 match ip dscp ef
 match ip dscp cs3
 
! Parent policy - limit traffic overall to 50Mbps
policy-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 queue
policy-map ELAN-OUT-HEADEND
 class VOICE
  priority 2000
 class class-default
  fair-queue
  random-detect dscp-based

interface GigabitEthernet0/2
 description Ethernet WAN
 speed 100
 duplex full
 service-policy output ELAN-OUT

Select all Open in new window

This is relatively easy to follow for the most part. But now it's time for the even bigger challenge -- 3-tier QoS as it would apply to the originally referenced article, L2-WAN-Routing-Design-for-QoS-Hub-and-Spoke-Using-EIGRP-Distribute-list-with-Route-map.

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.8

class-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 policy
policy-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 policy
policy-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 queue
policy-map BW-ELAN-POLICY
 class VOICE-BW
  priority 2000
 class class-default
  fair-queue
  random-detect dscp-based

interface GigabitEthernet0/0/0
 service-policy output ELAN-OUT

Select all Open in new window

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.

Conclusion

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.