![](/user_photo/1438_p9ksI.png)
- •QoS Overview
- •“Do I Know This Already?” Quiz
- •QoS: Tuning Bandwidth, Delay, Jitter, and Loss Questions
- •Foundation Topics
- •QoS: Tuning Bandwidth, Delay, Jitter, and Loss
- •Bandwidth
- •The clock rate Command Versus the bandwidth Command
- •QoS Tools That Affect Bandwidth
- •Delay
- •Serialization Delay
- •Propagation Delay
- •Queuing Delay
- •Forwarding Delay
- •Shaping Delay
- •Network Delay
- •Delay Summary
- •QoS Tools That Affect Delay
- •Jitter
- •QoS Tools That Affect Jitter
- •Loss
- •QoS Tools That Affect Loss
- •Summary: QoS Characteristics: Bandwidth, Delay, Jitter, and Loss
- •Voice Basics
- •Voice Bandwidth Considerations
- •Voice Delay Considerations
- •Voice Jitter Considerations
- •Voice Loss Considerations
- •Video Basics
- •Video Bandwidth Considerations
- •Video Delay Considerations
- •Video Jitter Considerations
- •Video Loss Considerations
- •Comparing Voice and Video: Summary
- •IP Data Basics
- •Data Bandwidth Considerations
- •Data Delay Considerations
- •Data Jitter Considerations
- •Data Loss Considerations
- •Comparing Voice, Video, and Data: Summary
- •Foundation Summary
- •QoS Tools and Architectures
- •“Do I Know This Already?” Quiz
- •QoS Tools Questions
- •Differentiated Services Questions
- •Integrated Services Questions
- •Foundation Topics
- •Introduction to IOS QoS Tools
- •Queuing
- •Queuing Tools
- •Shaping and Policing
- •Shaping and Policing Tools
- •Congestion Avoidance
- •Congestion-Avoidance Tools
- •Call Admission Control and RSVP
- •CAC Tools
- •Management Tools
- •Summary
- •The Good-Old Common Sense QoS Model
- •GOCS Flow-Based QoS
- •GOCS Class-Based QoS
- •The Differentiated Services QoS Model
- •DiffServ Per-Hop Behaviors
- •The Class Selector PHB and DSCP Values
- •The Assured Forwarding PHB and DSCP Values
- •The Expedited Forwarding PHB and DSCP Values
- •The Integrated Services QoS Model
- •Foundation Summary
- •“Do I Know This Already?” Quiz Questions
- •CAR, PBR, and CB Marking Questions
- •Foundation Topics
- •Marking
- •IP Header QoS Fields: Precedence and DSCP
- •LAN Class of Service (CoS)
- •Other Marking Fields
- •Summary of Marking Fields
- •Class-Based Marking (CB Marking)
- •Network-Based Application Recognition (NBAR)
- •CB Marking show Commands
- •CB Marking Summary
- •Committed Access Rate (CAR)
- •CAR Marking Summary
- •Policy-Based Routing (PBR)
- •PBR Marking Summary
- •VoIP Dial Peer
- •VoIP Dial-Peer Summary
- •Foundation Summary
- •Congestion Management
- •“Do I Know This Already?” Quiz
- •Queuing Concepts Questions
- •WFQ and IP RTP Priority Questions
- •CBWFQ and LLQ Questions
- •Comparing Queuing Options Questions
- •Foundation Topics
- •Queuing Concepts
- •Output Queues, TX Rings, and TX Queues
- •Queuing on Interfaces Versus Subinterfaces and Virtual Circuits (VCs)
- •Summary of Queuing Concepts
- •Queuing Tools
- •FIFO Queuing
- •Priority Queuing
- •Custom Queuing
- •Weighted Fair Queuing (WFQ)
- •WFQ Scheduler: The Net Effect
- •WFQ Scheduling: The Process
- •WFQ Drop Policy, Number of Queues, and Queue Lengths
- •WFQ Summary
- •Class-Based WFQ (CBWFQ)
- •CBWFQ Summary
- •Low Latency Queuing (LLQ)
- •LLQ with More Than One Priority Queue
- •IP RTP Priority
- •Summary of Queuing Tool Features
- •Foundation Summary
- •Conceptual Questions
- •Priority Queuing and Custom Queuing
- •CBWFQ, LLQ, IP RTP Priority
- •Comparing Queuing Tool Options
- •“Do I Know This Already?” Quiz
- •Shaping and Policing Concepts Questions
- •Policing with CAR and CB Policer Questions
- •Shaping with FRTS, GTS, DTS, and CB Shaping
- •Foundation Topics
- •When and Where to Use Shaping and Policing
- •How Shaping Works
- •Where to Shape: Interfaces, Subinterfaces, and VCs
- •How Policing Works
- •CAR Internals
- •CB Policing Internals
- •Policing, but Not Discarding
- •Foundation Summary
- •Shaping and Policing Concepts
- •“Do I Know This Already?” Quiz
- •Congestion-Avoidance Concepts and RED Questions
- •WRED Questions
- •FRED Questions
- •Foundation Topics
- •TCP and UDP Reactions to Packet Loss
- •Tail Drop, Global Synchronization, and TCP Starvation
- •Random Early Detection (RED)
- •Weighted RED (WRED)
- •How WRED Weights Packets
- •WRED and Queuing
- •WRED Summary
- •Flow-Based WRED (FRED)
- •Foundation Summary
- •Congestion-Avoidance Concepts and Random Early Detection (RED)
- •Weighted RED (WRED)
- •Flow-Based WRED (FRED)
- •“Do I Know This Already?” Quiz
- •Compression Questions
- •Link Fragmentation and Interleave Questions
- •Foundation Topics
- •Payload and Header Compression
- •Payload Compression
- •Header Compression
- •Link Fragmentation and Interleaving
- •Multilink PPP LFI
- •Maximum Serialization Delay and Optimum Fragment Sizes
- •Frame Relay LFI Using FRF.12
- •Choosing Fragment Sizes for Frame Relay
- •Fragmentation with More Than One VC on a Single Access Link
- •FRF.11-C and FRF.12 Comparison
- •Foundation Summary
- •Compression Tools
- •LFI Tools
- •“Do I Know This Already?” Quiz
- •Foundation Topics
- •Call Admission Control Overview
- •Call Rerouting Alternatives
- •Bandwidth Engineering
- •CAC Mechanisms
- •CAC Mechanism Evaluation Criteria
- •Local Voice CAC
- •Physical DS0 Limitation
- •Max-Connections
- •Voice over Frame Relay—Voice Bandwidth
- •Trunk Conditioning
- •Local Voice Busyout
- •Measurement-Based Voice CAC
- •Service Assurance Agents
- •SAA Probes Versus Pings
- •SAA Service
- •Calculated Planning Impairment Factor
- •Advanced Voice Busyout
- •PSTN Fallback
- •SAA Probes Used for PSTN Fallback
- •IP Destination Caching
- •SAA Probe Format
- •PSTN Fallback Scalability
- •PSTN Fallback Summary
- •Resource-Based CAC
- •Resource Availability Indication
- •Gateway Calculation of Resources
- •RAI in Service Provider Networks
- •RAI in Enterprise Networks
- •RAI Operation
- •RAI Platform Support
- •Cisco CallManager Resource-Based CAC
- •Location-Based CAC Operation
- •Locations and Regions
- •Calculation of Resources
- •Automatic Alternate Routing
- •Location-Based CAC Summary
- •Gatekeeper Zone Bandwidth
- •Gatekeeper Zone Bandwidth Operation
- •Single-Zone Topology
- •Multizone Topology
- •Zone-per-Gateway Design
- •Gatekeeper in CallManager Networks
- •Zone Bandwidth Calculation
- •Gatekeeper Zone Bandwidth Summary
- •Integrated Services / Resource Reservation Protocol
- •RSVP Levels of Service
- •RSVP Operation
- •RSVP/H.323 Synchronization
- •Bandwidth per Codec
- •Subnet Bandwidth Management
- •Monitoring and Troubleshooting RSVP
- •RSVP CAC Summary
- •Foundation Summary
- •Call Admission Control Concepts
- •Local-Based CAC
- •Measurement-Based CAC
- •Resources-Based CAC
- •“Do I Know This Already?” Quiz
- •QoS Management Tools Questions
- •QoS Design Questions
- •Foundation Topics
- •QoS Management Tools
- •QoS Device Manager
- •QoS Policy Manager
- •Service Assurance Agent
- •Internetwork Performance Monitor
- •Service Management Solution
- •QoS Management Tool Summary
- •QoS Design for the Cisco QoS Exams
- •Four-Step QoS Design Process
- •Step 1: Determine Customer Priorities/QoS Policy
- •Step 2: Characterize the Network
- •Step 3: Implement the Policy
- •Step 4: Monitor the Network
- •QoS Design Guidelines for Voice and Video
- •Voice and Video: Bandwidth, Delay, Jitter, and Loss Requirements
- •Voice and Video QoS Design Recommendations
- •Foundation Summary
- •QoS Management
- •QoS Design
- •“Do I Know This Already?” Quiz
- •Foundation Topics
- •The Need for QoS on the LAN
- •Layer 2 Queues
- •Drop Thresholds
- •Trust Boundries
- •Cisco Catalyst Switch QoS Features
- •Catalyst 6500 QoS Features
- •Supervisor and Switching Engine
- •Policy Feature Card
- •Ethernet Interfaces
- •QoS Flow on the Catalyst 6500
- •Ingress Queue Scheduling
- •Layer 2 Switching Engine QoS Frame Flow
- •Layer 3 Switching Engine QoS Packet Flow
- •Egress Queue Scheduling
- •Catalyst 6500 QoS Summary
- •Cisco Catalyst 4500/4000 QoS Features
- •Supervisor Engine I and II
- •Supervisor Engine III and IV
- •Cisco Catalyst 3550 QoS Features
- •Cisco Catalyst 3524 QoS Features
- •CoS-to-Egress Queue Mapping for the Catalyst OS Switch
- •Layer-2-to-Layer 3 Mapping
- •Connecting a Catalyst OS Switch to WAN Segments
- •Displaying QoS Settings for the Catalyst OS Switch
- •Enabling QoS for the Catalyst IOS Switch
- •Enabling Priority Queuing for the Catalyst IOS Switch
- •CoS-to-Egress Queue Mapping for the Catalyst IOS Switch
- •Layer 2-to-Layer 3 Mapping
- •Connecting a Catalyst IOS Switch to Distribution Switches or WAN Segments
- •Displaying QoS Settings for the Catalyst IOS Switch
- •Foundation Summary
- •LAN QoS Concepts
- •Catalyst 6500 Series of Switches
- •Catalyst 4500/4000 Series of Switches
- •Catalyst 3550/3524 Series of Switches
- •QoS: Tuning Bandwidth, Delay, Jitter, and Loss
- •QoS Tools
- •Differentiated Services
- •Integrated Services
- •CAR, PBR, and CB Marking
- •Queuing Concepts
- •WFQ and IP RTP Priority
- •CBWFQ and LLQ
- •Comparing Queuing Options
- •Conceptual Questions
- •Priority Queuing and Custom Queuing
- •CBWFQ, LLQ, IP RTP Priority
- •Comparing Queuing Tool Options
- •Shaping and Policing Concepts
- •Policing with CAR and CB Policer
- •Shaping with FRTS, GTS, DTS, and CB Shaping
- •Shaping and Policing Concepts
- •Congestion-Avoidance Concepts and RED
- •WRED
- •FRED
- •Congestion-Avoidance Concepts and Random Early Detection (RED)
- •Weighted RED (WRED)
- •Flow-Based WRED (FRED)
- •Compression
- •Link Fragmentation and Interleave
- •Compression Tools
- •LFI Tools
- •Call Admission Control Concepts
- •Local-Based CAC
- •Measurement-Based CAC
- •Resources-Based CAC
- •QoS Management Tools
- •QoS Design
- •QoS Management
- •QoS Design
- •LAN QoS Concepts
- •Catalyst 6500 Series of Switches
- •Catalyst 4500/4000 Series of Switches
- •Catalyst 3550/3524 Series of Switches
- •Foundation Topics
- •QPPB Route Marking: Step 1
- •QPPB Per-Packet Marking: Step 2
- •QPPB: The Hidden Details
- •QPPB Summary
- •Flow-Based dWFQ
- •ToS-Based dWFQ
- •Distributed QoS Group–Based WFQ
- •Summary: dWFQ Options
![](/html/1438/356/html_8qEWQlgVYy.fRAV/htmlconvd-rT6A6m375x1.jpg)
338 Chapter 5: Traffic Policing and Shaping
explicit congestion notification (FECN) and BECN bits—however, in some networks, the Frame Relay switches do set the bits, and in some, they do not.
If the BECN bit is set, the Main router, if using adaptive shaping, reduces its shaping rate on the VC to R1. Because the congestion occurs right to left, as signaled by a BECN flowing left to right, router Main knows it can slow down and help reduce the congestion. If Main receives another frame with BECN set, Main slows down more. Eventually, Main slows down the shaping rate until it reaches a minimum rate, sometimes called the minimum information rate (MIR), and other times called the mincir.
Similarly, if Main receives a Frame from R12 with FECN set, the congestion is occurring left to right. It does not help for Main to slow down. It does help for R12 to slow down. Therefore, the Main router can “reflect” the FECN, by marking the BECN bit in the next frame it sends on the VC to R12. R12, receiving a BECN, can reduce the shaping rate.
Finally, Foresight messages are separate, nondata signaling frames. Therefore, when the congestion occurs, Foresight does not need to wait on a data frame to signal congestion. In addition, Foresight sends messages toward the device that needs to slow down. For instance, a switch notices congestion right to left on the VC between Main and R24. The switch generates and sends a Foresight message to Main, using that same VC, so Main knows it needs to slow down its shaping rate on that VC temporarily.
When configuring adaptive shaping, you configure the minimum and maximum shaping rate. The configuration commands refer to the minimum rate as mincir, and the maximum rate as CIR, with mincir defaulting to 50 percent of CIR.
With no congestion, shaping uses the maximum rate. When the shaper receives a BECN or Foresight message, it slows down by 25 percent of the maximum rate. It continues to slow down by 25 percent of the maximum rate per Tc, until the minimum rate is reached. After 16 consecutive intervals occur without a BECN or Foresight congestion message, the shaping rate grows by 1/16 of the maximum rate during each Tc, until the maximum rate is reached again.
Where to Shape: Interfaces, Subinterfaces, and VCs
Shaping can be applied to the physical interface, a subinterface, or in some cases, to an individual VC. Depending on the choice, the configuration causes traffic shaping to occur separately for each VC, or it shapes several VCs together. In most cases, engineers want to shape each VC individually.
When shaping is applied to an interface for which VCs do not exist, shaping is applied to the main interface, because there are no subinterfaces or VCs on those interfaces. On Frame Relay and ATM interfaces, however, some sites have multiple VCs terminating in them, which means that subinterfaces will most likely be used. In some cases, more than one VC is associated with
![](/html/1438/356/html_8qEWQlgVYy.fRAV/htmlconvd-rT6A6m376x1.jpg)
Traffic-Policing and Traffic-Shaping Concepts 339
a single multipoint subinterface; in other cases, point-to-point subinterfaces are used, with a single VC associated with the subinterface. The question becomes this: To shape per VC, where do you enable traffic shaping?
First, consider a typical branch office, such as R24 in Figure 5-10.
Figure 5-10 PB Tents Network: Shaping on Subinterfaces and VCs
R1 |
|
|
|
|
|
|
|
|||
|
|
|
AR 128 kbps |
All VCs 64 kbps CIR |
|
|
||||
|
|
|
|
|||||||
R2 |
|
|
|
|
|
|||||
|
|
|
AR 128 kbps |
|
|
|
|
|
|
Main |
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
AR 128 kbps |
FRS1 |
FRS2 |
|
AR 1.5 Mbps |
||||||
|
|
|||||||||
|
|
|||||||||
.R3 |
|
|
|
FRS3 |
|
|
||||
|
|
|
|
|
||||||
. AR 128 kbps |
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
||||
. |
|
|
|
|
|
|
|
|
|
|
R24
R24 has a single VC to the Main site at PB Tents. Because R24 only has the single VC, the configuration on R24 may not even use subinterfaces at all. If the configuration does not use subinterfaces on R24’s serial link, traffic shaping can be configured on the physical interface. If the configuration includes a subinterface, you can enable traffic shaping on the physical interface, or on the subinterface. Because there is only one VC, it does not really matter whether shaping is enabled on the physical interface, or the subinterface—the behavior is the same.
Now consider the Main router. It has a VC to each remote site. (Also notice that a VC has been added between R1 and R2, just to make things interesting.) So, on the main router, point-to- point subinterfaces are used for the VCs to branches 3 through 24, and a multipoint subinterface is used for the two VCs to R1 and R2. To shape each VC to branches 3 through 24 separately, shaping can be configured on the subinterface. However, shaping applied to a multipoint subinterface shapes all the traffic on all VCs associated with the subinterface. To perform shaping on each VC, you need to enable shaping on each individual data-link connection identifier (DLCI).
In summary, most QoS policies call for shaping on each VC. The configuration commands used to enable shaping differ slightly based on the number of VCs, and how they are configured. Table 5-4 summarizes the options.
![](/html/1438/356/html_8qEWQlgVYy.fRAV/htmlconvd-rT6A6m377x1.jpg)
340 Chapter 5: Traffic Policing and Shaping
Table 5-4 |
Options of How to Enable Shaping for per-VC Shaping |
|
|
|
|
|
Location |
Requirements for Shaping per VC |
|
|
|
|
No VCs, for example, point-to-point |
Shape on the main interface. Shaping occurs for all traffic |
|
links |
on interface. |
|
|
|
|
Physical interface, 1 VC, no |
Shaping shapes the individual VC associated with this |
|
subinterfaces |
interface. Shaping can be enabled on the physical interface. |
|
|
|
|
Physical interface, 1 VC, 1 subinterface |
Shaping shapes the individual VC associated with this |
|
|
interface. Shaping can be enabled on the physical interface, |
|
|
the subinterface, or the VC (DLCI). |
|
|
|
|
Multiple VCs on 1 interface, point-to- |
Shaping can be enabled on the subinterface, or per DLCI. |
|
point subinterfaces only |
Both methods work identically. |
|
|
|
|
Multiple VCs on 1 interface, some |
Must enable shaping on each DLCI to shape per VC. |
|
multipoint subinterfaces with > 1 VC |
|
|
per subinterface |
|
|
|
|
Queuing and Traffic Shaping
Shaping tools support a variety of queuing tools that can be applied to the packets waiting in the shaping queue(s). At the same time, IOS supports queuing tools for the interface output queue(s) associated with the physical interface. Deciding when to use queuing tools on shaping queues, when to use them on the interface, and how the configurations differ in each case, can be a little confusing. This section clears up some of that confusion.
To begin, Table 5-5 lists the traffic-shaping tools, and the queuing tools supported by each for the shaping queues.
Table 5-5 Options for Queuing in Traffic-Shaping Tools
Shaping Tool |
Queuing Tools Supported for the Shaping Queue(s) |
|
|
GTS |
WFQ |
|
|
CB shaping |
FIFO, WFQ, CBWFQ, LLQ |
|
|
DTS |
FIFO, WFQ, CBWFQ, LLQ |
|
|
FRTS |
FIFO, WFQ, CBWFQ, LLQ, PQ, CQ |
|
|
When a shaper uses a queuing tool, instead of having a single shaping queue, multiple shaping queues exist. If FRTS were configured to use Priority Queuing (PQ), for instance, PQ would create four queues for shaping, named High, Medium, Normal, and Low. Figure 5-11 shows the basic idea, with shaping enabled on the physical interface, FIFO Queuing on the physical interface, and PQ configured for shaping the only VC.
![](/html/1438/356/html_8qEWQlgVYy.fRAV/htmlconvd-rT6A6m378x1.jpg)
Traffic-Policing and Traffic-Shaping Concepts 341
Figure 5-11 FRTS, with FIFO Queuing for the Physical Interface, Plus PQ for the Shaping Queue
Shaping Queues for a Single VC
PQ High –
Shaping Queue
PQ Medium –
Shaping Queue
PQ Normal –
Shaping Queue
PQ Low –
Shaping Queue
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Bit Rate |
|
|
|
|
Interface |
|
|
|
|
|
|
|
Limit |
|
|
|
|
|
|
|
TX Ring |
|
|
|
|
x bps |
|
|
|
|
Output Queue |
|
|
|
AR 128 kbps |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Slow |
Down |
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
|
||
Shape to |
|
|
|
|
|
|
|
|
|
|||
96 kbps |
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The shaping queues exist separately from the interface output queues, as seen in the figure. With PQ applied to the shaper, four shaping queues exist for this VC. When the shaper decides to allow another packet to be sent, it takes the next packet from the PQ shaping queues, according to PQ scheduler logic. Those packets are placed into queues associated with the physical interface and then forwarded out the interface.
In some cases, the shaping queues are bypassed, and in other cases, the interface output queues are bypassed. To understand why, consider Figure 5-12, which demonstrates part of the logic behind the decision for determining when each queue should be used.
Packets are held in a shaping queue or interface output queue only if there is some reason why the packet must wait to take the next step. For instance, you already know that if the TX Ring is not full, packets are immediately placed into the TX Ring, bypassing the interface output queue. Likewise, if shaping decides that a packet does not need to be delayed, it can go directly to the interface output queue, or even to the TX Ring.
Many QoS designs call for shaping per VC, as mentioned in the preceding section. Suppose that a router has two 64-kbps CIR VCs sharing an access link, each configured on a separate point- to-point subinterface. Shaping queues will be created for each VC. A single set of interface output queues will be created, too. Figure 5-13 depicts the overall idea.
![](/html/1438/356/html_8qEWQlgVYy.fRAV/htmlconvd-rT6A6m379x1.jpg)
342 Chapter 5: Traffic Policing and Shaping
Figure 5-12 Decision Logic for Queuing with Shaping Enabled
Packet |
|
|
|
|
|
||
Routed |
|
|
|
|
|
||
Out This |
|
|
|
|
|
||
Interface: |
Any Packets |
|
|
|
|||
Yes |
PQ High – |
||||||
|
|
||||||
|
|
in Shaping |
Shaping Queue |
||||
|
|
Queues? |
|
|
|
||
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
|
No |
|
|
|
PQ Medium – |
|
|
|
|
|
|
|
Shaping Queue |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Bc |
|
|
PQ Normal – |
||
|
|
Yes |
Shaping Queue |
||||
|
|
Exceeded |
|||||
|
|
|
|||||
|
|
|
|
|
|||
|
|
for |
|
|
|
||
|
|
Current |
|
|
PQ Low – |
||
|
|
Tc? |
|
|
Shaping Queue |
||
|
|
|
|
|
|
|
No
Shape to
96 kbps
|
Bit Rate |
Interface |
|
|
Limit |
TX Ring |
|
|
x bps |
Output Queue |
|
|
AR 128 kbps |
||
|
Down |
|
|
Slow |
|
|
|
|
|
|
Yes |
|
Yes |
|
Any Packets |
|
TX Ring |
No |
in Interface |
No |
||
Output |
Full? |
|
|
Queues? |
|
|
|
Figure 5-13 Fancy Queuing for the Physical Interface and for Two Sets of Shaping Queues
Shaping Queues for Subinterface 1
|
|
|
|
Bit Rate |
|
|
|
|
|
|
|
|
|
|
|
|
|
Limit |
|
|
|
|
|
|
|
|
|
|
Subint #1 |
|
|
x bps |
|
|
|
|
|
|
|
|
|
|
Shaping Queue1 |
|
Slow |
Down |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||
|
Subint #1 |
|
|
|
|
|
|
|
|
|
|
|
|
|
Shaping Queue2 |
|
Shape |
|
|
|
|
|
|
|
|
||
|
|
to |
|
|
|
||||||||
|
|
|
96 kbps |
|
|
|
|||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Shaping Queues for Subinterface 2 |
|
|
|
||||||||||
|
|
|
|
Bit Rate |
|
|
|
|
|
|
|
|
|
|
|
|
|
Limit |
|
|
|
|
|
|
|
|
|
|
Subint #2 |
|
|
|
|
||||||||
|
Shaping Queue1 |
|
|
x bps |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Slow |
Down |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||||||||
|
|
|
|
|
|
|
|
|
|
|
|||
|
Subint #2 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||
|
Shaping Queue2 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Shape to |
|
|
|||||||||
|
|
|
|
|
|||||||||
|
|
|
|
||||||||||
|
|
|
64 kbps |
|
|
Interface
Output
Queue#1
|
|
TX Ring |
|
|
||
|
|
AR 128 kbps |
||||
Interface |
|
|
|
|
||
|
|
|||||
Output |
|
|
|
|
|
|
|
|
|
|
|
|
|
Queue#2 |
|
|
|
|
|
|
The shaping tool creates a set of queues for each subinterface or VC, based on the queuing tool configured for use by the shaper. IOS creates only one set of output interface queues for the physical interface, based on the queuing configuration on the physical interface, as covered in Chapter 4, “Congestion Management.” In Figure 5-13, two sets of shaping queues have been created, one per VC. Both VCs feed the single set of interface output queues.