Internetworking & Technology Consulting Services

Home Up Contact Us Feedback Contents Search
Intranet: Local Intranet: Remote Training Center Our Courses CellStream Blog Lab Access For Sale!
 

Up

 

Cisco QoS Technical Tips Page

This page contains a growing number of Cisco Router Technical Tips focused on Quality of Service for folks who work in networking.  This is such an important feature of IOS, we thought we would keep it entirely separate.  There is a quick pick list at the top.

For a list of frequently used Cisco IOS commands that we like, click here.

If you would like to submit a QoS technical tip for inclusion here - simply send it to us.

If you want to return to the regular Tech Tips page click here.

Quick Pick List

  1. Quality of Service at the Highest Level
  2. Cisco AutoQoS
  3. Cisco NAT and QoS IOS Order of Operations
  4. Using Cisco NBAR
  5. Committed Access Rate


 


Quality of Service at the Highest Level

Managing Quality of Service (QoS) is an important process and skill that everyone who runs a network needs to understand.  In this introduction, we will introduce you to QoS principles at a high level.  You will find details in other tech tips on the CellStream site.

 

First, lets understand something clearly:  If you have enough bandwidth, you don't need QoS.  On simple networks, with few intersections, if the bandwidth is sufficient for the application you don't need to read any further.  On the other hand, if you have little bandwidth and the application needs a lot of bandwidth, QoS may not be able to help either.  Where QoS comes in play is when you have shared bandwidth with multiple applications, and some of those applications need preferred or controlled access to the bandwidth.

 

To manage QoS on your network, several things are required: a) you need to classify traffic into different categories, b) you need to determine policies for the different traffic types in the first step, and c) you need to apply those policies in the right places in the network.  Let's not think it is too simple, however.  QoS can be quite complex with the many options that exist in Cisco IOS.

 

Consider the Following:

Lets say you have an access router that is going to support the following:  a VoIP service,  an online interactive game, and of course be used for  Web browsing and e-mail and file transfer.  Lets further say that the router is experiencing  performance issues with the VoIP service when simultaneously running other applications.  Specifically,  when downloading a file, the VoIP service barely works and the online interactive game is unplayable.

 

Following our basic procedure the first step is to classify the traffic types.  This is done in IOS by either using an access control list (ACL), creating a Policy Based Routing (PBR) definition  or using Network Based Application Recognition (NBAR).   The traditional way is to use an ACL  to specify the different port numbers used by the applications in the example.  NBAR is Cisco's QoS Auto-Pilot.  You simply switch it on and it takes care of QoS on an assumed template.  This may be good for some, but not customizable enough for others.  For more info on NBAR see <http://www.cisco.com/en/US/products/ps6616/products_qanda_item09186a00800a3ded.shtml>.

 

Assuming you have created the ACL, the next step is to create what IOS calls a class-map.  A class-map defines the traffic into groups. So for each traffic type you would create a class map (i.e. Class-map voip, class-map gaming, etc.).  This completes the classification process. Now you are ready to determine how the traffic will be handled with policies.

 

The next step is to create a policy-map.  A policy-map defines how much bandwidth and priority each class you created above will get.  There are many options here, but the concept is simple.

 

The last step is to actually apply the policy to an interface on the router.  This is done like applying an ACL.  You can apply the policy you create to either the input or the output of an interface:

 

cell_pe1(config-if)# service-policy output|input {name of policy-map}

 

If you are going to use NBAR, then you must use the 'ip nbar protocol-discovery' command on the interface on which you wish to enable NBAR.

 

There is a downloadable model we found on Tech Republic, but it requires membership (free) to view.  Here is the link:  <http://downloads.techrepublic.com.com/abstract.aspx?docid=269947>   It is pretty easy for QoS beginners: you open the Excel file provided, and fill out the yellow sections on the Variables worksheet., then click the Replace button; it will generate the appropriate QoS configuration on a new sheet called QOS-1.  Now copy the configuration from the Excel file, and paste it into the Cisco CLI. You can copy directly from Excel into a Telnet or SSH session or even the console port.

 

Return to Quick Pick List at the top.


Cisco AutoQoS

In our High Level overview of QoS we stated that configuring QoS can be complicated.  Cisco developed NBAR as the QoS 'autopilot' as one solution to this problem.  More recently, Cisco has developed something called  AutoQoS, which also configures QoS settings for you.  You can use AutoQoS to a)create policies based on real-time traffic flowing through your router or switch, or b) create predefined voice over IP (VoIP) policies for VoIP traffic flowing through your IOS device.

 

AutoQoS runs on Cisco IOS routers series 2600 through 7200, and it runs on most Cisco routers with IOS version 12.2(15)T and later.  AutoQoS requires that Cisco Express Forwarding (CEF) is  enabled.  You enable CEF in global configuration mode using the ' ip cef'  command.  You will also need 'bandwidth' statements on your interfaces because AutoQoS uses the bandwidth statements when configuring bandwidth limitations for protocols it will be prioritizing.  If you change your bandwidth statements after configuring AutoQoS, you must rerun AutoQoS.  You configure AutoQoS at the interface level, not global level. 

 

cell_pe1(config)# interface Serial0/0

cell_pe1(config-if)# auto qos voip

 

The above commands will turn on AutoQoS on the serial interface 0/0 for VoIP traffic.  You will be surprised by the number of changes this makes to your 'show running-config'.  You will find: a) an access control lists define traffic, b) a class-map that classifies the traffic into classes (know which traffic to put into each class by the access control list that it matched, the DSCP bit that it matched, or the NBAR protocol that it matched), c) a policy-map that assigns priorities to the classes, and d) application of  the policy-map to the interface, which affects the traffic.

 

Here are some associated links on the Cisco Web Site:

PowerPoint presentation on AutoQoS: <http://www.cisco.com/en/US/tech/tk543/tk759/tk879/tech_configuration_guides_list.html>

AutoQoS documentation <http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cg/hqos_c/part50/index.htm>

Documentation for the auto qos voip command <http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cr/hqos_r/qos_a1h.htm>

AutoQoS Q&A <http://www.cisco.com/en/US/tech/tk543/tk759/tk879/technologies_q_and_a_item0900aecd8020a589.shtml>

Return to Quick Pick List at the top.


Cisco IOS Order of Operations

The order of operations is hard coded into Cisco IOS and tells the router how to process traffic according to the configuration of different router functions and features.  While we cant' make you think like a router, it is likely you have already picked up on some of these.  When configuring features such as Network Address Translation (NAT), Quality of Service (QoS), and encryption, it's essential to understand the order of operations in order to configure these features successfully.

 

QoS Order of Operations

Here's the order of operations for inbound traffic to the router:

  1. QoS Policy Propagation through Border Gateway Protocol (BGP)—or QPPB
  2. Input common classification
  3. Input ACLs
  4. Input marking—class-based marking or Committed Access Rate (CAR)
  5. Input policing—through a class-based policer or CAR
  6. IPSec
  7. Cisco Express Forwarding (CEF) or Fast Switching

Here's the order of operations for outbound traffic from the router:

  1. CEF or Fast Switching
  2. Output common classification
  3. Output ACLs
  4. Output marking
  5. Output policing—through a class-based policer or CAR
  6. Queueing—Class-Based Weighted Fair Queueing (CBWFQ) and Low Latency Queueing (LLQ)—and Weighted Random Early Detection (WRED)

 

NAT Order of Operations

We assume understanding of NAT basic operations.   If the packet is from a NAT inside-designated interface, it uses the inside-to-outside list. If the packet is from an outside-to-inside interface, it uses that list.

Here's the order of operations for the inside-to-outside list:

  1. If IPSec, then check input access list
  2. Decryption—for Cisco Encryption Technology (CET) or IPSec
  3. Check input access list
  4. Check input rate limits
  5. Input accounting
  6. Policy routing
  7. Routing
  8. Redirect to Web cache
  9. NAT inside to outside (local to global translation)
  10. Crypto (check map and mark for encryption)
  11. Check output access list
  12. Inspect context-based access control (CBAC)
  13. TCP intercept
  14. Encryption

Here's the order of operations for the outside-to-inside list:

  1. If IPSec, then check input access list
  2. Decryption—for CET or IPSec
  3. Check input access list
  4. Check input rate limits
  5. Input accounting
  6. NAT outside to inside (global to local translation)
  7. Policy routing
  8. Routing
  9. Redirect to Web cache
  10. Crypto (check map and mark for encryption)
  11. Check output access list
  12. Inspect CBAC
  13. TCP intercept
  14. Encryption

 

Let's say that you have an IP packet coming in from an outside-to-inside interface. When translating that packet, you want to use an access control list to block traffic from certain IP addresses. Which IP address should you put in the ACL—the IP address before the packet's translation (i.e., the public IP address), or the IP address after the packet's translation (i.e., the private address)?

 

By checking the order of operations, you can determine that the "NAT outside to inside" operation occurs after the "Check input access list" task. Therefore, you would use the public IP address in the ACL because the packet hasn't gone through NAT.

 

On the other hand, what if you want to create a static route for traffic going through NAT?  In this case, you would use the private (inside) IP address because the traffic has already gone through NAT when it gets to the "Routing" operation.

Return to Quick Pick List at the top.


Using Cisco NBAR

NBAR is a powerful packet filtering/identification/firewall that you may already have installed on your Cisco router.  For a list of what NBAR can detect look at: http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124tcg/tqos_c/part_05/qsnbar1.htm#wp1056828.

 

NBAR is also what we call Cisco's "autopilot" for QoS.  It has been in IOS since ver. 12.0 and has been continually updated with recognition of new applications.  A huge improvement was made with IOS 12.3  which introduced the ability to recognize more applications because of the availability of the Packet Description Language Module (PDLM) feature.   PDLMs help IOS to know which application is which when it looks through the traffic flow. Cisco regularly releases new PDLMs for new applications, and you can get more info at http://www.cisco.com/cgi-bin/tablebuild.pl/pdlm (a valid CCO login is required).

 

For list of NBAR applications recognized with IOS version 12.3, use the following commands:

cell_pe1(config)#class-map match-all nbar
cell_pe1(config-cmap)#match pro ?

 

Configuring and using NBAR to identify and block traffic is done as follows (you can find further details at http://www.cisco.com/en/US/docs/ios/qos/configuration/guide/nbar_mqc_ps6922_TSD_Products_Configuration_Guide_Chapter.html):

 

First, make sure that CEF is on using the following command:

cell_pe1(config)# ip cef

 

Next create a class-map, identifying the traffic you want to block.

cell_pe1(config)#class-map match-any killedtraffic
cell_pe1(config-cmap)# match protocol http url “*loveme.exe*”
cell_pe1(config-cmap)# match protocol http mime “*loveme.exe*”

 

Now create a policy to mark the traffic:

cell_pe1(config)# policy-map mark-killedtraffic
cell_pe1cell_pe1(config-pmap)# class killedtraffic
cell_pe1(config-pmap)# set ip dscp 1

 

Next, apply the policy to the interface that faces the Internet or the source of the traffic that you want to block. This marks the traffic when it enters the router:

cell_pe1(config)# interface serial 1/0
cell_pe1(config-if)#service-policy input mark-bad-traffic

 

Now create an access control list (ACL) that denies the marked traffic:

cell_pe1(config)# access-list 191 deny ip any any dscp 1
cell_pe1(config)# access-list 191 permit ip any any

 

Lastly, deny the marked traffic as it’s about to exit your router by applying the ACL to an interface:

cell_pe1(config)# interface GigabitEthernet 0/0
cell_pe1(config-if)# ip access-group 191 out

 

A less talked about feature of NBAR is its security aspect. NBAR can identify  fields in a HTTP packet, such as the URL, content type, or user agent.  For example, NBAR recognized the fast-moving Code Red Worm that first circulated the Internet in 2001. While traditional firewalls weren’t able to look inside the HTTP stream of data and block the Code Red traffic, NBAR was ideal for the situation.

 

Lastly, there are some things that NBAR cannot do. You can’t use it on a tunnel or encrypted interface, and you can’t use it to work with asymmetric traffic flows, understand URLs or other traffic in HTTPS traffic, work with non-CEF traffic, or identify fragmented traffic.

 

Return to Quick Pick List at the top.


Committed Access Rate (CAR)

CAR — or “rate limiting” — is a method for managing unwanted traffic on your network and making sure it doesn’t affect important traffic.  Essentially, CAR controls the bandwidth of a certain type of traffic, and an access control list (ACL) defines which traffic it controls. Once you’ve created the ACL, you can set CAR to enforce a bandwidth rate on that traffic in either an INBOUND or OUTBOUND direction, according to the interface on which you applied CAR.

 

Configuring  CAR requires two simple steps: a) Create an ACL to define the traffic you want to rate limit, and b) Use the rate-limit command, referencing the ACL on your interface closest to the source of the traffic, referencing the proper direction, and referencing the proper bandwidth amounts.

 

You can only use CAR with IP traffic. To use CAR, you must first enable CEF on your routers.

 

Lets say you wanted to limit a branch office PC (10.1.100.1) access to the Internet.  First, we must define the traffic  to be rate limited on the main office router:

 

Main_Office(config)# access-list 110 permit tcp any eq www host 10.1.100.1

 

Now use the rate-limit command on the interface:

 

Main_Office(config)# interface Serial1/0

Main_Office(config-if)# rate-limit output access-group 110 40000 10000 30000 conform-action transmit exceed-action drop

 

This command has applied the rate limit to the interface, referencing ACL 110 in the outbound direction (because it is applied it on the headquarters router not the remote router). The 40000, 10000, 30000 represents the normal bits per second (bps) for this traffic (i.e., 40000 bps or about 40 Kb), the normal burst size for the traffic (i.e., 10000 or about 10 Kb), and the maximum burst size for the traffic (i.e., 30000 or about 20 Kb). The traffic must conform to these numbers in order for the router to transmit it (as specified by conform-action transmit). If the traffic exceeds those bandwidth settings, the router will drop it (as specified by exceed-action drop).

 

While you can use CAR in a variety of situations, keep in mind that CAR only limits what you tell it to limit with the ACL. In addition, the CAR bandwidth settings you reference limit all traffic referenced in the ACL.

 

Return to Quick Pick List at the top.


 

Return to Quick Pick List at the top.


 

 

 

 

 

 

 

 

CellStream Inc. is a registered Trademark
Copyright © 1998-2008 CellStream Incorporated