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

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.