Using Policy Maps
After you have identified the interesting traffic, you can mark it or set policies for it. Marking traffic involves setting the DSCP bits or the CoS bits. You should classify and mark traffic as close to the end devices as possible, because classifying traffic uses router and switch resources. This is most important for routers, which perform QoS in software. Imagine if every router and switch in the network had to look into every packet to examine its port number. It is much more efficient if the first switch that a packet touches does the classifying and then sets a DSCP value based on the type of traffic it is. Then every other switch and router in the network can trust that the marking is correct and treat the traffic accordingly. This creates a trust boundary at the access switch.
The MQC applies policies to the traffic that has been classified by using a policy map. A policy map references the previously created class maps and then specifies what is to be done with traffic in each class. The traffic could, for example, be marked, allocated a minimum bandwidth, limited to a maximum bandwidth, prioritized, or even dropped altogether. You apply policy maps to interfaces. A separate queue is created at the interface for each class map, and the traffic that is identified by each class map is placed in its queue. This allows you to treat each of the classes of traffic differently.
Example 8-7 shows an example of marking traffic in a policy map. The class map CoS-Voice was created in Example 8-6. It identifies traffic with a CoS value of 5 in the 802.1Q trunking tag. This example creates a policy map that marks all the traffic classified by CoS-Voice with a DSCP value of 46 (or EF).
Example 8-7 Marking Traffic Using a Policy Map
VGateway(config)#policy-map COS-TO-DSCP
VGateway(config-pmap)#class COS-Voice VGateway(config-pmap-c)#set dscp 46 !
VGateway(config-pmap-c)#class class-default
VGateway(config-pmap-c)#set dscp 0 !
VGateway#show policy-map
Example 8-7 Marking Traffic Using a Policy Map (Continued)
Policy Map COS-TO-DSCP Class COS-Voice
set dscp ef Class class-default set dscp default
Notice that in Example 8-7, all traffic other than that marked with a CoS of 5 is set to a DSCP of 0 under the default class. If you have routing traffic, it is a good idea to break that out separately before classifying everything else as DSCP 0. Notice also that even though the policy map was configured using decimal values, when you display it, those are translated to the PHB values.
You most commonly use a policy map to specify different treatment for the traffic in each queue created by a class map. Setting policy and marking traffic are not mutually exclusive—you can do both of them to the same class. Voice is typically placed in a priority queue, called a low-latency queue (LLQ). It is important to understand that this is a strict priority queue. If any traffic is in the queue, it is sent out before other traffic. You can limit the amount of bandwidth used by the priority queue, however, so that other traffic is not starved.
How much bandwidth should you allow in the priority queue? In planning your bandwidth requirements, take into account the anticipated data load plus the voice load. The amount of bandwidth allocated per call varies depending on the coding/decoding (codec) used. Codec describes methods of compressing voice. The most typically used are G.711, which is uncompressed voice, and G.729, which is a type of compressed voice. G.711 is usually used in the LAN where bandwidth is plentiful. G.729 is typically used in the WAN, where you have lower bandwidth links. A G.711 call, sent at 64 kbps, has a payload size of 160 bytes. A G.729 call, sent at 8 kbps, uses a payload size of 20 bytes.
IP, UDP, and RTP headers are put onto each packet. The IP header is 20 bytes, UDP is 8 bytes, and RTP is 12 bytes, totaling an additional 40 bytes for each VoIP packet. You have the option of compressing the IP, UDP, and RTP headers, which reduces the header overhead to 2 to 4 bytes, thus reducing the entire packet size and using less bandwidth. For more information on compression, see the "Compression" section later in this chapter.
When you are planning bandwidth allocation, also take into consideration the Layer 2 headers to be used. For instance, Ethernet adds an 18-byte header, whereas Frame Relay adds only 6 bytes. Multilink PPP also has a 6-byte header. The ATM header is 5 bytes. If you use MPLS in your WAN network, the MPLS edge router adds a 4-byte header. If you are sending voice over the Internet, you might want to encrypt it in an IPsec tunnel for added security. IPsec adds 50 to 57 bytes of overhead. Secure Real-Time Transport Protocol (SRTP) encrypts the payload of IP voice packets and adds 4 bytes to the packet.
As a general rule, 21 to 320 kbps of bandwidth is required per call, depending on the codec and overhead. A good recommendation when running voice and data through the same
interface is to limit the LLQ to about one-third of the bandwidth. This usually allows enough remaining bandwidth to divide between the data classes.
IP video conferencing (IP/VC) adds additional considerations to your QoS design. Interactive video has the same network needs as voice—150 ms maximum delay, jitter of 30 ms or less, and loss of 1 percent or less—so it is frequently put in a LLQ. However, video traffic varies widely in packet sizes and transmission rates. A typical video conferencing stream averages 384 kpbs of bandwidth. Cisco recommends overprovisioning the bandwidth by 20 percent, bringing it to 460 kbps per IP/VC stream. LLQ allows bursts of up to 200 ms, which is usually enough for one video stream. If you will be sending multiple streams through an interface, you might need to adjust the burst size. You can specify the burst parameter when you create the LLQ in the policy map, as part of the priority command, as shown in Example 8-8. No hard and fast rule is available about how much to increase the burst parameter. You need to test as multiple IP/VC streams are added.
NOTE See Chapter 16 for more detailed information on bandwidth planning.
In Example 8-8, classes are created for voice, video conferencing, and call signaling. These classes are allotted bandwidth in the policy map. Voice and video are put into the LLQ, and the burst value for video is changed. Keep in mind that this is a simplistic example. In your network, you will most likely have other traffic that should be classified and included in the policy map.
Example 8-8 Policy Map for Voice and Video Traffic
VGateway(config)#class-map Voice VGateway(config-cmap)#match dscp ef !
VGateway(config-cmap)#class-map Video
VGateway(config-cmap)#match dscp 41 !
VGateway(config)#class-map match-any Call_Signaling
VGateway(config-cmap)#match dscp cs3
VGateway(config-cmap)#match dscp af31 !
VGateway(config-cmap)#policy-map VOICE-VIDEO VGateway(config-pmap)#class Voice
VGateway(config-pmap-c)#priority percent 15 !
VGateway(config-pmap-c)#class Video VGateway(config-pmap-c)#priority percent 18 ? <32-2000000> Burst in bytes <cr>
VGateway(config-pmap-c)#priority percent 18 30000 !
VGateway(config-pmap-c)#class Call_Signaling
Example 8-8 Policy Map for Voice and Video Traffic (Continued)
VGateway(config-pmap-c)#bandwidth percent 5 !
VGateway(config-pmap-c)#class class-default VGateway(config-pmap-c)#fair-queue
VGateway(config-pmap-c)#random-detect dscp-based !
VGateway(config-pmap-c)#int s0/0
VGateway(config-if)#service-policy output VOICE-VIDEO
Notice the fair-queue and random-detect dscp-based commands under the class-default. The fair-queue command tells the router to create a separate queue for each conversation, or traffic flow, that falls into the default class. The random-detect command enables weighted random early detection (WRED) within that class. It tells the router to drop random packets from flows as the queue begins to fill up. This is done in an attempt to prevent the queue from filling completely and dropping all new packets. When the dscp-based command is added, the router drops packets based on their DSCP value. Packets with higher DSCP values are dropped later than lower valued ones.
The policy is applied to interface serial 0/0 and affects outbound traffic. An extremely useful command to verify and monitor your QoS configuration is show policy interface interface_number. Example 8-9 shows the output from this command. Although the router currently has no traffic, you can see that the command gives a detailed picture of the policy and its effect on traffic through that interface.
Example 8-9 show policy interface Command Output
VGateway#show policy interface s0/0
Serial0/0
Service-policy output: VOICE-VIDEO
Class-map: Voice (match-all) 0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: dscp ef (46)
Queueing
Strict Priority
Output Queue: Conversation 264 Bandwidth 15 (%)
Bandwidth 450 (kbps) Burst 11250 (Bytes) (pkts matched/bytes matched) 0/0 (total drops/bytes drops) 0/0
Class-map: Video (match-all) 0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: dscp 41
Queueing
Strict Priority
Example 8-9 show policy interface Command Output (Continued)
Output Queue: Conversation 264 Bandwidth 18 (%)
Bandwidth 540 (kbps) Burst 30000 (Bytes) (pkts matched/bytes matched) 0/0 (total drops/bytes drops) 0/0
Class-map: Call_Signaling (match-any) 0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps Match: dscp cs3 (24) 0 packets, 0 bytes 5 minute rate 0 bps Match: dscp af31 (26) 0 packets, 0 bytes 5 minute rate 0 bps Queueing
Output Queue: Conversation 265 Bandwidth 5 (%)
Bandwidth 150 (kbps) Max Threshold 64 (packets) (pkts matched/bytes matched) 0/0 (depth/total drops/no-buffer drops) 0/0/0
Class-map: class-default (match-any) 0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Queueing
Flow Based Fair Queueing Maximum Number of Hashed Queues 256 (total queued/total drops/no-buffer drops) 0/0/0 exponential weight: 9
|
dscp |
Transmitted |
Random drop |
Tail drop |
Minimum |
Maximum |
Mark |
|
pkts/bytes |
pkts/bytes |
pkts/bytes |
thresh |
thresh |
prob |
|
|
af11 |
0/0 |
0/0 |
0/0 |
32 |
40 |
1/10 |
|
af12 |
0/0 |
0/0 |
0/0 |
28 |
40 |
1/10 |
|
af13 |
0/0 |
0/0 |
0/0 |
24 |
40 |
1/10 |
|
af21 |
0/0 |
0/0 |
0/0 |
32 |
40 |
1/10 |
|
af22 |
0/0 |
0/0 |
0/0 |
28 |
40 |
1/10 |
|
af23 |
0/0 |
0/0 |
0/0 |
24 |
40 |
1/10 |
|
af31 |
0/0 |
0/0 |
0/0 |
32 |
40 |
1/10 |
|
af32 |
0/0 |
0/0 |
0/0 |
28 |
40 |
1/10 |
|
af33 |
0/0 |
0/0 |
0/0 |
24 |
40 |
1/10 |
|
af41 |
0/0 |
0/0 |
0/0 |
32 |
40 |
1/10 |
|
af42 |
0/0 |
0/0 |
0/0 |
28 |
40 |
1/10 |
|
af43 |
0/0 |
0/0 |
0/0 |
24 |
40 |
1/10 |
|
cs1 |
0/0 |
0/0 |
0/0 |
22 |
40 |
1/10 |
|
cs2 |
0/0 |
0/0 |
0/0 |
24 |
40 |
1/10 |
|
cs3 |
0/0 |
0/0 |
0/0 |
26 |
40 |
1/10 |
|
cs4 |
0/0 |
0/0 |
0/0 |
28 |
40 |
1/10 |
|
cs5 |
0/0 |
0/0 |
0/0 |
30 |
40 |
1/10 |
|
cs6 |
0/0 |
0/0 |
0/0 |
32 |
40 |
1/10 |
Example 8-9 show policy interface Command Output (Continued)
cs7 ef rsvp default
0/0 0/0 0/0 0/0
0/0 0/0 0/0 0/0
0/0 0/0 0/0 0/0
34 36 36 20
40 40 40 40
1/10
1/10
1/10
1/10
Based on the output from the show policy interface command, you can tell the name of the policy map that is applied to the interface, the names of all the class maps in that policy map, and which type of traffic they match against. You can determine the policy applied to each class. Notice that both Voice and Video are shown as a strict priority queue, whereas Class-default shows flow-based fair queuing. If no queuing method is listed, the queue is using FIFO. The amount of bandwidth allocated and actually used is shown. Because the Class-default is using DSCP-based WRED, drop statistics are shown for each PHB value. This is an excellent command to remember when configuring class-based QoS because it shows both the policy and the effect of the policy. To verify specific components of a policy, use the show policy-map, show class-map, and show queueing commands.
In a well-designed network, traffic generally arrives at the voice gateway already marked appropriately. You might need to change those markings, however, when sending voice over an MPLS VPN network. MPLS networks change the typical WAN paradigm. Instead of having a link between two sites, or a hub-and-spoke topology, MPLS provides connectivity to all your sites through a single WAN link. It is similar to an Ethernet network or a full-mesh Frame Relay network in that you have any-to-any connectivity through one physical link. Traffic switching between sites is done in the cloud, by the service provider.
The popularity of MPLS is growing due not only to its ability to provide full-mesh connectivity, but also for its ability to provide differing levels of service for user traffic. This makes it ideal for intraoffice voice and video, in addition to data. However, cooperation is needed between the company and the service provider to ensure consistent treatment of traffic throughout the MPLS network. It is not enough for each site to regulate the way it sends traffic out its own WAN interface, because the service provider routers are also involved in the equation. Consider a simple MPLS network such as the one shown in Figure 8-1.
Continue reading here: Mapping to MPLS Classes
Was this article helpful?