Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
DQOS Exam Certification Guide - Cisco press.pdf
12.7 Mб

296 Chapter 4: Congestion Management

would be discarded due to policing, because the cumulative rate for all traffic would exceed 400 kbps. The policer would have no way to decide to discard just the extra voice, but not video, because the policer acts on all traffic in the class. However, with the two lower-latency queues configuration, only the voice calls would lose packets due to policing, and the video conference would not have any packets dropped by the policer.

In effect, with multiple low-latency queues, you get more granularity in what you police. In fact, the most typical reason to use multiple low-latency queues is to support voice in one queue, and video in another.

Queuing does not differ when comparing using a single low-latency queue with multiple lowlatency queues in a single policy map. IOS always takes packets from the low-latency queues first, as compared with the non-low-latency queues (those with a bandwidth command), just like before. However, IOS does not reorder packets between the various low-latency queues inside the policy map. In other words, IOS treats all traffic in all the low-latency queues with FIFO logic.

In short, using multiple low-latency queues in one policy map does enable you to police traffic more granularly, but it does not reorder packets among the various low-latency queues.

Unfortunately, the DQOS and QoS courses and exams disagree with each other about where you can have more than one low-latency queue. The DQOS course states that only one lowlatency queue is allowed in a single policy map, whereas the QoS course states that multiple low-latency queues are allowed. So, you may talk to colleagues who have seen some Cisco documentation, or taken the DQOS class, and swear that only one low-latency queue is allowed. Thankfully, the chances are low that you would see a question distinguishing this fine point. However, you should be aware of the differences in documentation and the courses, so we made it a point to draw attention to the differences here.

IP RTP Priority

Before Cisco created LLQ, Cisco created two other tools that added a single priority queue to another queuing tool. IP RTP Reserve was the first of these two tools to be introduced, followed by the IP RTP Priority feature. With current IOS releases, Cisco recommends not using these older tools, but instead suggests using LLQ. However, because IP RTP Priority is currently on QoS exams, a brief explanation is warranted.

IP RTP Priority provides many features like LLQ, but with a few differences. It adds a PQ to either WFQ or to CBWFQ. It classifies VoIP payload traffic by classifying packets in a range of UDP port numbers, from which it only selects traffic from the even-numbered (VoIP payload) ports. Like LLQ, the PQ created by IP RTP Priority always gets serviced first, but the bandwidth reserved for this queue is policed to prevent it from taking over all bandwidth. Table 4-14 summarizes the main features and compares the features with LLQ.




Queuing Tools 297





Table 4-14 Comparison of LLQ and IP RTP Priority Features




















Adds a priority queue to WFQ








Adds a priority queue to CBWFQ








Can classify on even UDP ports in a specified range








Can classify on anything MQC can use to classify








Reserves a configured amount of bandwidth








Bandwidth is policed, so priority queue cannot exceed the




configured bandwidth








Currently recommended best queuing tool for low latency







IP RTP Priority Configuration

To configure IP RTP Priority, you just add one additional configuration command to an interface that already uses WFQ. There are no additional show commands to list information about IP RTP Priority beyond the commands that apply to the underlying queuing tools (WFQ and CBWFQ). Table 4-15 lists the two configuration commands, and Example 4-9 lists several example configurations.

Table 4-15 Command Reference for IP RTP Priority



Mode and Function





ip rtp priority starting-rtp-port-number port-number-

Interface configuration mode; enables IP


range bandwidth

RTP Priority on a subinterface or interface





frame-relay ip rtp priority starting-rtp-port-number

FRTS (Frame Relay traffic shaping) map-


port-number-range bandwidth

class configuration mode; enables IP RTP



Priority in an FRTS map class, which is then



enabled on a subinterface or DLCI (data-link



connection identifier)




Example 4-9 IP RTP Priority Configuration Examples


! Example 1

interface serial 1/0

description this interface will use WFQ and IP RTP Priority, with 30 kbps reserved

encapsulation hdlc



298 Chapter 4: Congestion Management

Example 4-9 IP RTP Priority Configuration Examples (Continued)

ip rtp-priority 16384 16383 30


!Example 2 interface serial 1/1

description this interface will use CBWFQ and IP RTP Priority, with 30 kbps reserved encapsulation frame-relay

service-policy output my-policy ip rtp-priority 16384 16383 30

!Example 3

interface serial 1/3 encapsulation frame-relay frame-relay traffic-shaping

interface serial 1/3.1 point-to-point

description this subinterface will use FRTS per DLCI, plus WFQ and IP RTP Priority frame-relay interface-dlci 100

class my-shape


map-class my-shape frame-relay cir 128000 Frame-relay fair-queue

Frame-relay ip rtp-priority 16384 16383 30

Example 4-9 lists three different configurations for IP RTP Priority. The first example, configured on serial interface 1/0, shows a simple configuration on a point-to-point serial link using High-level Data Link Control (HDLC) encapsulation. The ip rtp-priority 16384 16383 30 command enables the feature, matching even-numbered UDP ports between 16384 and 32767. (The 16384 parameter is the base port number, and the 16383 parameter is the number of ports starting at the base port number.) The last parameter, 30, sets the guaranteed minimum bandwidth and the policing rate, just as the priority command did for LLQ.

The second example just shows IP RTP Priority enabled on a serial interface using Frame Relay. The ip rtp priority command enables the function on Frame Relay interfaces as well as HDLC interfaces. Also in the second example, RTP Priority is configured to work with CBWFQ, as evidenced by the service-policy subcommand under serial 1/1.

Finally, the third example shows RTP Priority along with Frame Relay traffic shaping (FRTS). Chapter 5 explains the details behind FRTS configuration. FRTS parameters are configured as subcommands of a command called map-class. Queuing, including IP RTP Priority, can be configured inside an FRTS map-class, which is then enabled on an interface, subinterface, or DLCI.

Cisco recommends LLQ be used for delay-sensitive traffic such as VoIP and interactive video traffic. However, in cases where CBWFQ and LLQ are not an option (for instance, when the IOS release is earlier than 12.0(7)T/12.1 Mainline), IP RTP Priority provides a good alternative for queuing delay-sensitive traffic.