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

Queuing Concepts 245

Example 4-1 TX Queue Length: Finding the Length, and Changing the Length (Continued)

tx_limited=0(1)

! Lines omitted to save space

The show controllers serial 0/0 command lists the size of the TX Queue or TX Ring. In the shaded output in Example 4-1, the phrase “tx_limited=0(16)” means that the TX Ring holds 16 packets. The zero means that the queue size is not currently limited due to a queuing tool being enabled on the interface. For the first instance of show controllers, no queuing method is enabled on the interface, so a zero signifies that the size of the TX Ring has not been limited automatically. After enabling Priority Queuing with the priority-group interface subcommand, the next show controllers command lists “tx_limited=1(2).” The new length of the TX Ring is 2, and 1 shows that the length is automatically limited as a result of queuing being configured. Next, Priority Queuing is disabled with the no priority-group interface subcommand, but the length of the TX Ring is explicitly defined with the tx-ring-limit 1 interface subcommand. On the final show controllers command, the “tx_limited=0(1)” output implies that the size is not limited, because no queuing is enabled, but that the length of the TX Ring is 1.

The following list summarizes the key points about TX Rings and TX Queues in relation to their effect on queuing:

The TX Queue/TX Ring always performs FIFO scheduling, and cannot be changed.

The TX Queue/TX Ring uses a single queue, per interface.

IOS shortens the interface TX Queue/TX Ring automatically when an output queuing method is configured.

The TX Ring/TX queue length can be configured to a different value.

Queuing on Interfaces Versus Subinterfaces and Virtual Circuits (VCs)

IOS queuing tools create and manage output queues associated with an interface, and then the packets drain into the TX Ring/Queue associated with the interface. IOS also supports queuing on subinterfaces and individual VCs when traffic shaping is also enabled. Shaping queues, created by the traffic-shaping feature, drain into the interface output queues, which then drain into the TX Ring/Queue. Like the interface output queues, the shaping queues can be managed with IOS queuing tools.

The interaction between shaping queues associated with a subinterface or VC, and queues associated with a physical interface, is not obvious at first glance. So, before moving into the details of the various queuing tools, consider what happens on subinterfaces, VCs, and physical interfaces so that you can make good choices about how to enable queuing in a router.

Figure 4-5 provides a reasonable backdrop from which to explain the interaction between queues. R1 has many permanent virtual circuits (PVCs) exiting its S0/0 physical interface. The

246 Chapter 4: Congestion Management

figure shows queues associated with two of the PVCs, a single queue for the physical interface, and the TX Ring for the interface.

Figure 4-5 Subinterface Shaping Queues, Interface Queues, and TX Ring

Router1

s0/0.1

 

 

 

 

 

 

 

 

 

Subinterface

#1

 

 

 

 

 

 

 

 

Shaping Queue

 

 

 

 

 

 

 

 

Interface

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Output Queue

 

 

TX Ring

 

 

 

 

 

 

 

 

s0/0

Subinterface

#2

 

 

 

 

 

 

 

 

Shaping Queue

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

s0/0.2

 

 

 

 

 

 

 

 

 

In this particular example, each subinterface uses a single FIFO shaping queue; the physical interface uses a FIFO output queue. At first glance, it seems simple enough: A packet arrives, and the forwarding decision dictates that the packet should exit subinterface S0/0.1. It is placed into the subinterface 0/0.1 shaping queue, and then into the physical interface output queue, and then into the TX Ring. Then, it exits the interface.

In some cases, the packet moves from the shaping queues directly to the TX Queue. You may recall that packets are not even placed in the output queue if the TX Ring is not full! If no congestion occurs on the interface, the TX Ring does not fill. If no congestion occurs in the TX Ring, the interface output queue does not fill, and the queuing tool enabled on the interface has no effect on the packets exiting the interface.

In some cases, IOS does not place the packets into a shaping queue as they arrive, but instead the packets are placed into the interface queue or TX Queue. When the shaping features knows that a newly arrived packet does not exceed the shaping rate, there is no need to delay the packet. In that case, a queuing tool used for managing the shaping queue would also have no effect.

Traffic shaping can cause subinterface shaping queues to fill, even when there is no congestion on the physical interface. Traffic shaping, enabled on a subinterface or VC, slows down the flow of traffic leaving the subinterface or VC. In effect, traffic shaping on the subinterface creates congestion between the shaping queues and the physical interface queues. On a physical interface, packets can only leave the interface at the physical clock rate used by the interface; similarly, packets can only leave a shaping queue at the traffic-shaping rate.

Queuing Concepts 247

For example, the VC associated with subinterface S0/0.1 uses a 64 kbps committed information rate (CIR), and S0/0 uses a T/1 circuit. Without traffic shaping, more than 64 kbps of traffic could be sent for that PVC, and the only constraining factor would be the access rate (T/1). The Frame Relay network might discard some of the traffic, because the router may send more (up to 1.5 Mbps) on the VC, exceeding the traffic contract (64-kbps CIR). So, traffic shaping could be enabled on the subinterface or VC, restricting the overall rate for this PVC to 64 kbps, to avoid frame loss inside the Frame Relay network. If the offered load of traffic on the subinterface exceeds 64 kbps for some period, traffic shaping delays sending the excess traffic by placing the packets into the shaping queue associated with the subinterface, and draining the traffic from the shaping queue at the shaped rate.

Figure 4-6 shows an updated version of Figure 4-5; this one’s PVC is currently exceeding the shaping rate, and the other PVC is not exceeding the shaping rate.

Figure 4-6 Shaping Active on One VC, and Not Active on the Other

Shaping

Queue

Bit Rate

Limit

x bps

128 kbps Routed

out Subinterface Incoming 0/0.1

Packets

40 kbps Routed out Subinterface 0/0.2

Slow

Down

 

 

Bit Rate

 

Limit

x bps

Discarded

s0/0.1 Queue Fills, Since

Offered Rate > Shaped Rate

Interface

 

 

TX Ring

s0/0

Output Queue

 

 

T1

 

 

 

 

Traffic Rate

Less Than

Shaping Rate

- NO Queuing!

In Figure 4-6, packets arrive and are routed out of each of the two subinterfaces. Traffic for subinterface 0/0.1 exceeds the shaping rate, and packets for subinterface 0/0.2 do not. Therefore, a queue begins to form on the shaping queue for subinterface 0/0.1, because traffic shaping delays packets by queuing the packets. On subinterface 0/0.2, packets will not be enqueued into the shaping queue, because the shaping rate has not been exceeded.

You can configure queuing tools to manipulate the output queue on a physical interface, as well as the shaping queue created by shaping. The concepts in this chapter apply to using queuing on both the main interface, and on any shaping queues. However, this chapter only covers the configuration of queuing to manipulate the interface output queues. Chapter 5, “Traffic Policing and Shaping,” which covers traffic shaping, explains how to configure queuing for use on shaping queues. When reading the next chapter, keep these queuing concepts in mind and watch for the details of how to enable your favorite queuing tools for shaping queues.