Setting the DSCP or TOS Field
Problem
You want the router to mark the DSCP or TOS field of an IP packet to affect its priority through the network.
Solution
The solution to this problem depends on the sort of traffic distinctions you want to make, as well the version of IOS you are running in your routers.
There must be something that defines the different types of traffic that you wish to prioritize. In general, the simpler the distinctions are to make, the better. This is because all of the tests take router resources and introduce processing delays. The most common rules for distinguishing between traffic types use the packet's input interface and simple IP header information such as TCP port numbers. The following examples show how to set an IP Precedence value of immediate (2) for all FTP control traffic that arrives through the serial0/0 interface, and an IP Precedence of priority (1) for all FTP data traffic. This distinction is possible because FTP control traffic uses TCP port 21, and FTP data uses port 20.
The new method for configuring this uses class maps. Cisco first introduced this feature in IOS Version 12.0(5)T. This method first defines a class-map that specifies how the router will identify this type of traffic. It then defines a policy-map that actually makes the changes to the packet's TOS field:
Router#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router(config)#access-list 101 permit any eq ftp any Router(config)#access-list 101 permit any any eq ftp Router(config)#access-list 102 permit any eq ftp-data any Router(config)#access-list 102 permit any any eq ftp-data Router(config)#class-map match-all ser00-ftpcontrol Router(config-cmap)#description branch ftp control traffic Router(config-cmap)#match input-interface serial0/0 Router(config-cmap)#match access-group 101 Router(config-cmap)#exit Router(config)#class-map match-all ser00-ftpdata Router(config-cmap)#description branch ftp data traffic Router(config-cmap)#match input-interface serial0/0 Router(config-cmap)#match access-group 102 Router(config-cmap)#exit Router(config)#policy-map serialftppolicy Router(config-pmap)#description branch ftp traffic policy Router(config-pmap)#class ser00-ftpcontrol Router(config-pmap-c)#set ip precedence immediate Router(config-pmap-c)#exit Router(config-pmap)#class ser00-ftpdata Router(config-pmap-c)#set ip precedence priority Router(config-pmap-c)#exit Router(config-pmap)#exit Router(config)#interface serial0/0 Router(config-if)#ip route-cache policy Router(config-if)#service-policy input serialftppolicy Router(config-if)#exit Router(config)#end Router#
For earlier IOS versions, where class-maps were not available, you have to use policy-based routing to alter the TOS field in a packet. Applying this policy to the interface tells the router to use this policy to test all incoming packets on this interface and rewrite the ones that match the route map:
Router#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router(config)#access-list 101 permit any eq ftp any Router(config)#access-list 101 permit any any eq ftp Router(config)#access-list 102 permit any eq ftp-data any Router(config)#access-list 102 permit any any eq ftp-data Router(config)#route-map serialftp-rtmap permit 10 Router(config-route-map)#match ip address 101 Router(config-route-map)#set ip precedence immediate Router(config-route-map)#exit Router(config)#route-map serialftp-rtmap permit 20 Router(config-route-map)#match ip address 102 Router(config-route-map)#set ip precedence priority Router(config-route-map)#exit Router(config)#interface serial0/0 Router(config-if)#ip policy route-map serialftp-rtmap Router(config-if)#ip route-cache policy Router(config-if)#exit Router(config)#end Router#
Discussion
Before you can tag a packet for special treatment, you have to have an extremely clear idea of what types of traffic need special treatment, as well as precisely what sort of special treatment they will need. In the example, we have decided to give a special priority to FTP traffic received on a specific serial interface. We show how to do this using both the old and new configuration techniques.
This may appear to be a somewhat artificial example. After all, why would you care about tagging inbound traffic that you have already received from a low-speed interface? Actually, one of the most important principles for implementing QoS in a network is that you should always tag the packet as early as possible, preferably at the edges of the network. Then, as it passes through the network, each router only needs to look at the tag, and doesn't need to do any additional classification. In this case, we would ensure that the FTP traffic returning in the other direction is tagged by the first router that receives it. So the outbound traffic has already been tagged, and it is a waste of router resources to reclassify the outbound packets.
Many organizations actually take this idea of marking at the edges one step further, and remark every received packet. This helps to ensure that users aren't requesting special QoS privileges that they aren't allowed to have. However, you should be careful of this because it can sometimes disrupt legitimate markings. For example, a real-time application might use RSVP to reserve bandwidth through the network. It is important that the packets for this application have the appropriate Expedited Forwarding (EF) DSCP marking or the network might not handle them properly. However, you also don't want to let other non-real-time applications from this same source have the same EF priority level. So, if you are going to configure your routers to remark all incoming packets at the edges, make sure you understand what incoming markings are legitimate.
Recipe 15.10 shows another interesting variation of this idea. In that case, the routers are running DLSw to bridge SNA traffic through an IP network. So the routers themselves actually create the IP packets. This creates an additional challenge because there is no incoming interface. So that recipe uses local policy-based routing. The fact that the router creates the packets also gives it an important advantage because it doesn't have to consider any DLSw packets that might just happen to pass through.
The advantages of the newer class-map method aren't obvious in this example, but one of the first big advantages appears if you want to use the more modern DSCP tagging scheme. Because the older policy-based routing method doesn't directly support DSCP, you have to fake it by setting both the IP Precedence and the TOS separately as follows.
Router(config)#route-map serialftp-rtmap permit 10 Router(config-route-map)#match ip address 115 Router(config-route-map)#set ip precedence immediate Router(config-route-map)#set ip tos max-throughput
In this case, the packet will wind up with an IP Precedence value of immediate, or 2 (010 in binary), and TOS of max-throughput, or 4 (0100 in binary). Combining the bit patterns gives 0100100, but, as we discuss in Appendix B, DSCP only uses the first 6 bits, 010010. If you look up this bit combination in Table B-3 in Appendix B, you will see that it corresponds to a value of AF21, which is Class 2 and lowest drop precedence.
Doing the same thing with the class-map method is much more direct:
Router(config)#policy-map serialftppolicy Router(config-pmap)#class serialftpclass Router(config-pmap-c)#set ip dscp af21
Class-maps will also be useful later in this chapter when we talk about class-based weighted fair queuing and class-based traffic shaping.
It is important to note that throughout this entire example, we have only put a special value into the packet's TOS or DSCP field. This, by itself, doesn't affect how the packet is forwarded through the network. To do that, you must ensure that as each router in the network forwards these marked packets, the interface queues will react appropriately to this information.
Finally, we should note that while this recipe shows two useful ways of marking packets, Recipe 11.15 shows still another method, using Committed Access Rate (CAR) features. CAR tends to be more efficient on higher speed interfaces.
See Also
Recipe 11.3; Recipe 11.5; Recipe 11.6; Recipe 11.7; Recipe 11.10; Recipe 11.15; Recipe 11.16; Appendix B