IP RTP Priority
Router(config-if)# ip rtp priority starting-rtp-port-number port-number-range bandwidth設定完成之後，我們可以使用以下的指令來檢查我們的配置：
Router# show queue interface-type interface-number以下是Cisco官網上的說明：
Feature Overview
The IP RTP Priority feature provides a strict priority queueing scheme for delay-sensitive data such as voice. Voice traffic can be identified by its Real-Time Transport Protocol (RTP) port numbers and classified into a priority queue configured by the ip rtp priority command. The result is that voice is serviced as strict priority in preference to other nonvoice traffic.
The IP RTP Priority feature extends and improves on the functionality offered by the ip rtp reserve command by allowing you to specify a range of User Datagram Protocol (UDP)/RTP ports whose traffic is guaranteed strict priority service over any other queues or classes using the same output interface. Strict priority means that if packets exist in the priority queue, they are dequeued and sent first—that is, before packets in other queues are dequeued. We recommend that you use the ip rtp priority command instead of the ip rtp reserve command for voice configurations.
The IP RTP Priority feature does not require that you know the port of a voice call. Rather, the feature gives you the ability to identify a range of ports whose traffic is put into the priority queue. Moreover, you can specify the entire voice port range—16384 to 32767—to ensure that all voice traffic is given strict priority service. IP RTP Priority is especially useful on slow-speed links whose speed is less than 1.544 Mbps.
This feature can be used in conjunction with either Weighted Fair Queueing (WFQ) or Class-Based WFQ (CBWFQ) on the same outgoing interface. In either case, traffic matching the range of ports specified for the priority queue is guaranteed strict priority over other CBWFQ classes or WFQ flows; packets in the priority queue are always serviced first.
- When used in conjunction with WFQ, the ip rtp priority command provides strict priority to voice, and WFQ scheduling is applied to the remaining queues.
- When used in conjunction with CBWFQ, the ip rtp priority command provides strict priority to voice. CBWFQ can be used to set up classes for other types of traffic (such as Systems Network Architecture [SNA]) that needs dedicated bandwidth and needs to be treated better than best effort and not as strict priority; the nonvoice traffic is serviced fairly based on the weights assigned to the enqueued packets. CBWFQ can also support flow-based WFQ within the default CBWFQ class if so configured.
Because voice packets are small in size and the interface also can have large packets going out, the Link Fragmentation and Interleaving (LFI) feature should also be configured on lower speed interfaces. When you enable LFI, the large data packets are broken up so that the small voice packets can be interleaved between the data fragments that make up a large data packet. LFI prevents a voice packet from needing to wait until a large packet is sent. Instead, the voice packet can be sent in a shorter amount of time.
How IP RTP Priority Works
If you want to understand its behavior and properly use the IP RTP Priority feature, it is important to consider its admission control and policing characteristics. When you use the ip rtp priority command to configure the priority queue for voice, you specify a strict bandwidth limitation. This amount of bandwidth is guaranteed to voice traffic enqueued in the priority queue. (This is the case whether you use the IP RTP Priority feature with CBWFQ or WFQ.)
IP RTP Priority closely polices use of bandwidth for the priority queue, ensuring that the allocated amount is not exceeded in the event of congestion. In fact, IP RTP Priority polices the flow every second. IP RTP Priority prohibits transmission of additional packets once the allocated bandwidth is consumed. If it discovers that the configured amount of bandwidth is exceeded, IP RTP Priority drops packets, an event that is poorly tolerated by voice traffic. (Enable debugging to watch for this condition.) Close policing allows for fair treatment of other data packets enqueued in other CBWFQ or WFQ queues. To avoid packet drop, be certain to allocate to the priority queue the most optimum amount of bandwidth, taking into consideration the type of codec used and interface characteristics. IP RTP Priority will not allow traffic beyond the allocated amount.
It is always safest to allocate to the priority queue slightly more than the known required amount of bandwidth. For example, suppose you allocated 24 kbps bandwidth, the standard amount required for voice transmission, to the priority queue. This allocation seems safe because transmission of voice packets occurs at a constant bit rate. However, because the network and the router or switch can use some of the bandwidth and introduce jitter and delay, allocating slightly more than the required amount of bandwidth (such as 25 kbps) ensures constancy and availability.
The IP RTP Priority admission control policy takes RTP header compression into account. Therefore, while configuring the bandwidth parameter of the ip rtp priority command you only need to configure for the bandwidth of the compressed call. For example, if a G.729 voice call requires 24 kbps uncompressed bandwidth (not including Layer 2 payload) but only 12 kbps compressed bandwidth, you only need to configure a bandwidth of 12 kbps. You need to allocate enough bandwidth for all calls if there will be more than one call.
The sum of all bandwidth allocation for voice and data flows on the interface cannot exceed 75 percent of the total available bandwidth. Bandwidth allocation for voice packets takes into account the payload plus the IP, RTP, and UDP headers, but again, not the Layer 2 header. Allowing 25 percent bandwidth for other overhead is conservative and safe. On a PPP link, for instance, overhead for Layer 2 headers assumes 4 kbps. The amount of configurable bandwidth for IP RTP Priority can be changed using the max-reserved-bandwidth command on the interface.
If you know how much bandwidth is required for additional overhead on a link, under aggressive circumstances in which you want to give voice traffic as much bandwidth as possible, you can override the 75 percent maximum allocation for the bandwidth sum allocated to all classes or flows by using the max-reserved-bandwidth command. If you want to override the fixed amount of bandwidth, exercise caution and ensure that you allow enough remaining bandwidth to support best-effort and control traffic, and Layer 2 overhead.
As another alternative, if the importance of voice traffic far exceeds that of data, you can allocate most of the 75 percent bandwidth used for flows and classes to the voice priority queue. Unused bandwidth at any given point will be made available to the other flows or classes.
CBWFQ Configuration
The following example first defines a CBWFQ configuration and then reserves a strict priority queue:
! The following commands define a class map:router(config)# class-map class1
router(config-cmap)# match access-group 101
router(config-cmap)# exit
! The following commands create and attach a policy map:router(config)# policy-map policy1
router(config-pmap)# class class1
router(config-pmap-c)# bandwidth 3000
router(config-pmap-c)# queue-limit 30
router(config-pmap-c)# random-detect
router(config-pmap-c)# random-detect precedence 0 32 256 100
router(config-pmap-c)# exit
router(config)# interface Serial1
router(config-if)# service-policy output policy1
! The following command reserves a strict priority queue:router(config-if)# ip rtp priority 16384 16383 40
The queue-limit and random-detect commands are optional commands for CBWFQ configurations. The queue-limit command is used for configuring tail drop limits for a class queue. The random-detect command is used for configuring RED drop limits for a class queue, similar to the random-detect command available on an interface.
Virtual Template Configuration
The following example configures a strict priority queue in a virtual template configuration with CBWFQ. The max-reserved-bandwidth command changes the maximum reserved bandwidth allocated for CBWFQ and IP RTP Priority from the default (75 percent) to 80 percent.router(config)# multilink virtual-template 1
router(config)# interface virtual-template 1
router(config-if)# ip address 172.16.1.1 255.255.255.0
router(config-if)# no ip directed-broadcast
router(config-if)# ip rtp priority 16384 16383 25
router(config-if)# service-policy output policy1
router(config-if)# ppp multilink
router(config-if)# ppp multilink fragment-delay 20
router(config-if)# ppp multilink interleave
router(config-if)# max-reserved-bandwidth 80
router(config-if)# end
router(config)# interface Serial0/1
router(config-if)# bandwidth 64
router(config-if)# ip address 1.1.1.2 255.255.255.0
router(config-if)# no ip directed-broadcast
router(config-if)# encapsulation ppp
router(config-if)# ppp multilink
router(config-if)# end
Multilink Bundle Configuration
The following example configures a strict priority queue in a multilink bundle configuration with WFQ. The advantage to using multilink bundles is that you can specify different ip rtp priority parameters on different interfaces.
The following commands create multilink bundle 1, which is configured for a maximum ip rtp priority bandwidth of 200 kbps. The max-reserved-bandwidth command changes the maximum reserved bandwidth allocated for WFQ and IP RTP Priority.router(config)# interface multilink 1
router(config-if)# ip address 172.17.254.161 255.255.255.248
router(config-if)# no ip directed-broadcast
router(config-if)# ip rtp priority 16384 16383 200
router(config-if)# no ip mroute-cache
router(config-if)# fair-queue 64 256 0
router(config-if)# ppp multilink
router(config-if)# ppp multilink fragment-delay 20
router(config-if)# ppp multilink interleave
router(config-if)# max-reserved-bandwidth 80
The following commands create multilink bundle 2, which is configured for a maximum ip rtp priority bandwidth of 100 kbps:router(config)# interface multilink 2
router(config-if)# ip address 172.17.254.162 255.255.255.248
router(config-if)# no ip directed-broadcast
router(config-if)# ip rtp priority 16384 16383 100
router(config-if)# no ip mroute-cache
router(config-if)# fair-queue 64 256 0
router(config-if)# ppp multilink
router(config-if)# ppp multilink fragment-delay 20
router(config-if)# ppp multilink interleave
In the next part of the example, the multilink-group command configures serial interface 2/0 to be part of multilink bundle 1.router(config)# interface serial 2/0
router(config-if)# bandwidth 256
router(config-if)# no ip address
router(config-if)# no ip directed-broadcast
router(config-if)# encapsulation ppp
router(config-if)# no ip mroute-cache
router(config-if)# no fair-queue
router(config-if)# clockrate 256000
router(config-if)# ppp multilink
router(config-if)# multilink-group 1
Next, serial interface 2/1 is configured to be part of multilink bundle 2.router(config)# interface serial 2/1
router(config-if)# bandwidth 128
router(config-if)# no ip address
router(config-if)# no ip directed-broadcast
router(config-if)# encapsulation ppp
router(config-if)# no ip mroute-cache
router(config-if)# no fair-queue
router(config-if)# clockrate 128000
router(config-if)# ppp multilink
router(config-if)# multilink-group 2
Comments