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

rauenpcSenior Network Speialist
CERTIFIED EXPERT
Published:
Quality of Service (QoS) options are nearly endless when it comes to networks today. This article is merely one example of how it can be handled in a hub-n-spoke design using a 3-tier configuration.
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

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

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

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.
0
1,948 Views
rauenpcSenior Network Speialist
CERTIFIED EXPERT

Comments (0)

Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.