![](/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-rT6A6m540x1.jpg)
Link Fragmentation and Interleaving 503
FRTS interaction and usage of queuing tools can be difficult to understand, let along trying to keep track of all the options. Interestingly, FRTS supports one set of queuing tools without FRF.12 enabled, and a subset with FRF.12 enabled, and with yet another subset of those (LLQ and IP RTP Priority) that actually interleave the packets. Table 7-9 summarizes the queuing tools and identifies when you can use them with FRTS and FRF.12.
Table 7-9 Queuing Tool Support with FRTS and FRF.12 (Cisco IOS Software Release 12.2 Mainline)
|
Queuing Tools Supported on Each VC |
Desired Features |
(Shaping Queues) |
|
|
FRTS only |
FIFO, PQ, Custom Queuing (CQ), Weighted Fair |
|
Queuing (WFQ), Class-Based Weighted Fair Queuing |
|
(CBWFQ), LLQ, IP RTP Priority |
|
|
FRTS with FRF.12 enabled |
WFQ, CBWFQ, LLQ, IP RTP Priority |
|
|
FRTS, FRF.12, with actual interleaving |
LLQ, IP RTP Priority |
of packets |
|
|
|
Choosing Fragment Sizes for Frame Relay
FRF.12 uses the same basic math as does MLP LFI to determine the fragment size—max-delay * bandwidth. But what do you use for bandwidth in the formula? CIR? Do you use the shaping or policing rate? Or the access rate, which is the clock rate used on the access link? Figure 7-11 shows a typical Frame Relay network that provides a backdrop from which to discuss which values to use.
Figure 7-11 Example Frame Relay Network Used to Explain How to Choose Fragment Sizes
|
|
|
|
|
|
|
|
CIR 64 kbps |
|
|
|
|
|
|
|
|
|
|
AR 128 kbps |
|
|
|
|
AR 1544 kbps |
|||||||
|
|
|
|
|
|
||||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
R2 |
|
|
|
|
|
|
|
Main |
||||||
|
|
Frame Relay |
|
|
|
|
|||||||||
|
|
|
|
|
FRS1 |
FRS2 |
|||||||||
|
|
|
|
|
Virtual Circuit |
||||||||||
160 byte frag takes 10ms |
|
|
160 byte frag takes .8ms |
||||||||||||
|
|
|
|
|
|
|
|
|
|
||||||
160 byte frag takes 10ms |
|
|
160 byte frag takes .8ms |
||||||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
In most cases, you should choose to fragment based on the slower access rate on either end of a VC, which in this case is the 128-kbps access rate on R1. The reason you should use the lower of the two access rates becomes apparent only when you think of serialization delay inside the cloud, and in both directions. First, consider left-to-right flow in the network. To reduce serialization delay to 10 ms on a 128-kbps link, the fragment size should be set to 160 bytes (128,000 * .01 = 1280 bits). When R2 sends a packet, the serialization delay takes 10 ms.
![](/html/1438/356/html_8qEWQlgVYy.fRAV/htmlconvd-rT6A6m541x1.jpg)
504 Chapter 7: Link-Efficiency Tools
Moving from left to right, a full-sized fragment sent from FRS1 to the Main router takes only 0.8 seconds to serialize! Reversing the direction, a 160-byte fragment leaving router Main, going into the cloud, only takes 0.8-ms serialization delay, so you might be tempted to make the fragment size much larger for packets sent by router Main. When the packets get to FRS2, however, and need to cross the access link to R1, a small fragment size of 160 bytes gives you an advantage of low serialization delay. If you were to make the fragment size on the Main router a much larger size, the frame would experience a much larger serialization delay on the link from FRS1 to R1.
One common misconception is that fragmentation size should be based on the CIR of the VC, rather than on the access rate. Fragmentation attacks the problem of serialization delay, and serialization delay is based on how long it takes to encode the bits onto the physical interface, which in turn is determined by the physical clock rate on the interface. So, you should always base FRF.12 fragmentation sizes on the clock rate (access rate) of the slower of the two access links, not on CIR.
FRF.12 configuration does not let you set the maximum delay, as does MLP LFI. Instead, you configure the fragment size directly. When planning, you normally pick a maximum serialization delay for each link first. So before you can configure FRF.12, you need to calculate the fragmentation size. When you know the lower of the two access rates, and the maximum serialization delay desired, you can calculate the corresponding fragment size with the following formula:
Max-delay * bandwidth
Table 7-8, shown earlier in this section, lists some of the more common combinations of maximum delay and bandwidth, with the resulting fragment sizes.
Fragmentation with More Than One VC on a Single Access Link
Cisco IOS Software enables FRF.12 per VC—in other words, you can perform LFI for the traffic on some VCs, but not others. Therefore, before configuring FRF.12, you should decide which VCs really need to use it.
You first need to determine whether any of the Frame Relay VCs need to use LFI. If the traffic on all the VCs can tolerate the delays without performing LFI, you are better off not fragmenting the frames. Fragmentation does increase the bandwidth required in the network slightly, because the fragmentation headers add a few bytes of overhead. Therefore, if serialization delay is not an issue, do not use FRF.12 at all.
Most installations consider LFI when voice is added to the network. If voice is added to all sites in a Frame Relay network, of course you would consider LFI on all the VCs. The interesting choice comes when you have compelling reasons for LFI on some VCs, and not-so-obvious compelling reasons for others. The network in Figure 7-12 shows just such a network, with voice between the Main site and R1, and no voice to the other two remote sites.
![](/html/1438/356/html_8qEWQlgVYy.fRAV/htmlconvd-rT6A6m542x1.jpg)
Link Fragmentation and Interleaving 505
Figure 7-12 Choosing Fragment Sizes
IP |
R1 |
AR 64K
AR 128K |
Main |
FRS1 |
FRS2 |
No Voice! |
FRS3 |
|
|
R2 AR 128K |
|
No Voice! |
|
R3 |
AR 256K FRS4 |
|
IP
In the figure, Main terminates three VCs that each share the same physical access link. Because voice traffic traverses the VC from Main to R1, LFI should be enabled on that VC, with the fragment size based on the slower of the two access links on either end of the VC. However, you should also enable LFI on all three VCs that terminate at Main.
The reason for LFI on all three VCs relates to an effect called egress blocking. Suppose that R1 sends a small voice packet, with R2 and R3 sending several large, unfragmented data packets. FRS2 receives the large packets first, and queues those packets to exit the access link to the Main router. The small voice packet arrives immediately after the large data packets, so the small voice packet must wait on the large packets to be forwarded.
Depending on the behavior of queuing in the Frame Relay switch, LFI may or may not help with the egress-blocking problem. With LFI on all the VCs, with the same general sequence of events, the small voice packet might just be behind a large number of small fragmented packets, rather than behind a small number of large packets. The Frame Relay switch might use a queuing algorithm that sends some frames from each VC intermittently, however, in which case LFI decreases the delay for the small voice packet. The key here is to understand how the VCs are configured to handle LFI.
For you exam takers out there, the general recommendation in the courses is to fragment on all VCs using a particular interface if at least one VC needs to use FRF. Therefore, in Figure 7-12, the only VC on which Cisco recommends not to bother with FRF.12 is the VC between R2 and R3.
MLP LFI and FRF both accomplish the same general task of reducing serialization delay for some packets. As seen in this chapter, the methods used by each differ in how each tool takes advantage of queuing tools. Table 7-10 summarizes the core functions of MLP LFI versus FRF.12, particularly how they each interact with the available queuing tools.
![](/html/1438/356/html_8qEWQlgVYy.fRAV/htmlconvd-rT6A6m543x1.jpg)
506 Chapter 7: Link-Efficiency Tools
Table 7-10 Comparisons Between MLP LFI and FRF.12
Step in the Process |
MLP LFI |
FRF.12 |
|
|
|
Configures maximum delay, |
Maximum delay |
Fragment size |
or actual fragment size |
|
|
|
|
|
Classification into the |
Based on the queuing tool enabled |
All packets coming from |
interface output queues |
on the interface |
LLQ or RTP Priority shaping |
|
|
queues placed in higher- |
|
|
priority queue |
|
|
|
Number of interface output |
Based on the queuing tool enabled |
2 queues, called Dual FIFO |
queues |
on the interface |
|
|
|
|
How queue service algorithm |
Based on queuing tool’s inherent |
PQ-like algorithm, always |
causes interleaving to occur |
queue service algorithm; PQ, LLQ, |
servicing High queue over |
|
and RTP Priority most aggressively |
Normal queue |
|
interleave packets |
|
|
|
|
Multilink PPP Interleaving Configuration
Before you configure MLP LFI, think about why you would use MLP at all. If you have a point- to-point link, and need to perform LFI, you must migrate from your current Layer 2 protocol to MLP, to use MLP LFI. However, MLP itself has many benefits, and even a few brief thoughts about what MLP does will help you through some of the configuration tasks.
MLP enables you to have multiple parallel point-to-point links between a pair of devices, such as routers. The main motivation for MLP was to allow dial applications to continue adding additional switched WAN connections between the endpoints when more bandwidth was needed. For instance, maybe one dialed line was brought up, but when the utilization exceeded 60 percent, another line dialed, and then another, and so on.
MLP includes the inherent capability to load balance the traffic across the currently active lines, without causing reordering problems. To understand those concepts, consider Figure 7-13, with three parallel point-to-point links controlled by MLP.
Figure 7-13 MLP Bundled with 3 Active Links—What Could Happen
|
|
|
|
|
|
|
1500 |
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
Reordered packets |
|||
|
|
|
|
|
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
100 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
R1 |
|
|
|
|
|
|
R2 |
1500 |
|
100 |
|
|
|
|
|
|
|
|
|
|
|
|
||||||
100 |
|
1500 |
|
|
|
|
|
|
|
|||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
![](/html/1438/356/html_8qEWQlgVYy.fRAV/htmlconvd-rT6A6m544x1.jpg)
Link Fragmentation and Interleaving 507
With three active links, MLP could reorder packets. If a 1500-byte packet arrives, for instance, immediately followed by a 100-byte packet, MLP might send the first packet over one link, and the next packet over the second link. Because the second packet is much smaller, its serialization delay will be much smaller. Assuming that both links speeds are equal, the 100-byte packet will arrive before the larger packet. Consequently, the 100-byte packet is forwarded first, before the 1500-byte packet. If both packets are part of the same flow, the endpoint computer may have to do more work to reorder the packets, which TCP could do if it is being used. However, some UDP-based applications could require that the out-of-order packets be re-sent, depending on the application. Over time, the three links will experience different utilization averages, depending on the random occurrence of traffic in the network.
MLP does not behave as shown in Figure 7-13. Instead, MLP, by its very nature, fragments packets. Figure 7-14 shows what really happens.
Figure 7-14 MLP Bundle with 3 Active Links—What Does Happen
|
|
|
|
|
|
|
|
500 (Frag 1) |
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
500 (Frag 2) |
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
|
|
|
|
|||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
R1 |
|
|
|
|
|
R2 |
100 |
|
1500 |
|
||
|
|
|
|
|
|
|
|
|
|
||||||||
100 |
|
1500 |
|
|
|
|
|
|
|
|
|||||||
|
|
|
|
|
|
|
|
500 (Frag 3) |
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
|
|
|
||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
MLP always fragments PPP frames to load balance traffic equitably and to avoid out-of-order packets. Notice that the 1500-byte packet was fragmented into three 500-byte fragments, one for each link. By default, MLP fragments each packet into equal-sized fragments, one for each link. Suppose, for instance, that two links were active; the fragments would have been 750 bytes long. If four were active, each fragment would have been 375 bytes long. And yes, even the 100-byte packet would be fragmented, with one fragment being sent over each link.
The other point you should consider about basic MLP, before looking at MLP LFI configuration, is that the multiple links appear as one link from a Layer 3 perspective. In the figures, R1 and R2 each have one IP address that applies to all three links. To configure these details, most of the interface subcommands normally entered on the physical interface are configured somewhere else, and then applied to each physical interface that will comprise part of the same MLP bundle.
With those two basic MLP concepts in mind, you can now make more sense of the MLP LFI configuration. Tables 7-11 and 7-12 list the pertinent configuration and show commands, respectively, and are followed by some example configurations.
![](/html/1438/356/html_8qEWQlgVYy.fRAV/htmlconvd-rT6A6m545x1.jpg)
508 Chapter 7: Link-Efficiency Tools
Table 7-11 Configuration Command Reference for MLP Interleaving
|
Command |
Mode and Function |
||
|
|
|
|
|
|
ppp multilink [bap] |
Interface configuration mode; enables multilink PPP on the |
||
|
|
interface, dialer group, or virtual template |
||
|
|
|
|
|
|
ppp multilink interleave |
Interface configuration mode; enables interleaving of |
||
|
|
unfragmented frames with fragments of larger frames |
||
|
|
|
|
|
|
ppp multilink fragment delay time |
Interface configuration mode; Enables MLP fragmentation, |
||
|
|
and defines fragment size, with formula bandwidth/time |
||
|
|
|
|
|
|
ppp multilink fragment disable |
Interface configuration mode; Disables MLP fragmentation |
||
|
|
|
|
|
|
ppp multilink group group-number |
Interface configuration mode; links a physical interface to a |
||
|
|
dialer group or virtual template |
||
|
|
|
|
|
Table 7-12 Exec Command Reference for MLP Interleaving |
|
|||
|
|
|
|
|
|
Command |
|
|
Function |
|
|
|
|
|
|
show ppp multilink |
|
|
Lists information about the active links currently in |
|
|
|
|
the same MLP bundle |
|
|
|
|
|
|
show interfaces |
|
|
Lists statistics and status about each interface, |
|
|
|
|
including multilink virtual interfaces |
|
|
|
|
|
|
show queueing [interface atm-subinterface |
|
Lists configuration and statistical information about |
|
|
[vc [[vpi/] vci]]] |
|
|
the queuing tool on an interface |
|
|
|
|
|
The first MLP LFI example shows a baseline configuration for MLP, without LFI. After this, the additional configuration commands for fragmentation, and then interleave, are added. Finally, the example ends with the addition of the ip rtp priority command, which enables one of the forms of queuing with a low-latency feature. The explanation after the example explains how some traffic was interleaved (or not) at each step along the way.
The criteria for the configuration is as follows:
•
•
•
Clock rate is 128 kbps on the point-to-point link.
Fragment to 10-ms fragments.
Use RTP Priority.
In the example, Client 1 downloads two to three web pages, each of which has two frames inside the page. Each web page uses two separate TCP connections to download two separate large JPG files. Client 1 also downloads a file using FTP get. In addition, a VoIP call is placed between extensions 3002 and 1002. Figure 7-15 shows the network used for the example, and Example 7-5 shows the configuration and some sample show commands.
![](/html/1438/356/html_8qEWQlgVYy.fRAV/htmlconvd-rT6A6m546x1.jpg)
Link Fragmentation and Interleaving 509
Figure 7-15 Sample Network for MLP LFI Examples
Note: All IP Addresses Begin 192.168.
Client1 |
|
|
|
|
|
|
|
|
|
Server1 |
||||||||||||||
|
|
|
|
|
99.251 |
99.253 |
|
|
|
|
|
|
|
|
||||||||||
|
|
1.251 |
|
|
|
|
|
|
|
|
|
|
||||||||||||
|
|
|
|
|
|
|
SW1 |
|
R1 |
|
s1/1 |
s0/1 R3 |
SW2 |
|
|
|
|
|
|
|||||
|
|
|
|
|
|
|
|
|
|
|
||||||||||||||
1.100 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
3.100 |
|
|
|||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
3.254 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
R4
1001 1002
3001 3002
Example 7-5 MLP LFI Configuration
!
! STEP 1 STEP 1 STEP 1 STEP 1 STEP 1 STEP 1 STEP 1 STEP 1 STEP 1 STEP 1 STEP 1 STEP 1
!
R3#show running-config
!
! Many lines omitted for brevity
!
username R1 password 0 me
!
interface Multilink9 bandwidth 128
ip address 192.168.99.253 255.255.255.0 no ip route-cache cef
load-interval 30 fair-queue
no cdp enable ppp multilink
multilink-group 9
!
!
interface Serial0/1 bandwidth 128
no ip address encapsulation ppp no ip mroute-cache load-interval 30 clockrate 128000 ppp multilink multilink-group 9
continues
![](/html/1438/356/html_8qEWQlgVYy.fRAV/htmlconvd-rT6A6m547x1.jpg)
510 Chapter 7: Link-Efficiency Tools
Example 7-5 MLP LFI Configuration (Continued)
!
!
!STEP 2 STEP 2 STEP 2 STEP 2 STEP 2 STEP 2 STEP 2 STEP 2 STEP 2 STEP 2
!Adding Fragmentation for 10ms fragments. Added same command on R1 as well,
!No shown here for brevity.
!
R3#conf t
Enter configuration commands, one per line. End with CNTL/Z. R3(config)#interface multilink 9
R3(config-if)#ppp multilink fragment-delay 10
R3(config-if)#^Z
R3#show interfaces multilink 9
Multilink9 is up, line protocol is up Hardware is multilink group interface Internet address is 192.168.99.253/24
MTU 1500 bytes, BW 128 Kbit, DLY 100000 usec, reliability 255/255, txload 233/255, rxload 43/255
Encapsulation PPP, loopback not set Keepalive set (10 sec)
DTR is pulsed for 2 seconds on reset LCP Open, multilink Open
Open: IPCP
Last input 00:00:02, output never, output hang never Last clearing of "show interface" counters 00:20:41
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 1056 Queueing strategy: weighted fair
Output queue: 64/1000/64/1055 (size/max total/threshold/drops) Conversations 5/11/32 (active/max active/max total) Reserved Conversations 0/0 (allocated/max allocated) Available Bandwidth 96 kilobits/sec
30 second input rate 22000 bits/sec, 44 packets/sec
30 second output rate 117000 bits/sec, 48 packets/sec
4459 packets input, 273353 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 62241 packets output, 5141980 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
0 carrier transitions
!
!STEP 3 STEP 3 STEP 3 STEP 3 STEP 3 STEP 3 STEP 3 STEP 3 STEP 3 STEP 3
!Added Interleaving feature. Did same on R1, not shown here.
!
R3#conf t
Enter configuration commands, one per line. End with CNTL/Z. R3(config)#interface multilink 9
R3(config-if)#ppp multilink interleave
R3(config-if)#^Z
![](/html/1438/356/html_8qEWQlgVYy.fRAV/htmlconvd-rT6A6m548x1.jpg)
Link Fragmentation and Interleaving 511
Example 7-5 MLP LFI Configuration (Continued)
R3#show interfaces multilink 9
Multilink9 is up, line protocol is up Hardware is multilink group interface Internet address is 192.168.99.253/24
MTU 1500 bytes, BW 128 Kbit, DLY 100000 usec, reliability 255/255, txload 227/255, rxload 29/255
Encapsulation PPP, loopback not set Keepalive set (10 sec)
DTR is pulsed for 2 seconds on reset LCP Open, multilink Open
Open: IPCP
Last input 00:00:00, output never, output hang never Last clearing of "show interface" counters 00:22:00
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 1406 Queueing strategy: weighted fair
Output queue: 27/1000/64/1405/164 (size/max total/threshold/drops/interleaves) Conversations 5/11/32 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated) Available Bandwidth 96 kilobits/sec
30 second input rate 15000 bits/sec, 30 packets/sec
30 second output rate 114000 bits/sec, 54 packets/sec
6386 packets input, 386857 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 66702 packets output, 6267446 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
0 carrier transitions
R3#
R3#show queue multilink 9
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 1906 Queueing strategy: weighted fair
Output queue: 64/1000/64/1905/16500 (size/max total/threshold/drops/interleaves) Conversations 5/11/32 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated) Available Bandwidth 96 kilobits/sec
(depth/weight/total drops/no-buffer drops/interleaves) 1/32384/4/0/982 Conversation 4, linktype: ip, length: 74
source: 192.168.3.100, destination: 192.168.1.100, id: 0xF513, ttl: 127, TOS: 0 prot: 6, source port 80, destination port 1517
(depth/weight/total drops/no-buffer drops/interleaves) 52/32384/1700/0/0 Conversation 17, linktype: ip, length: 62
source: 192.168.3.254, destination: 192.168.99.251, id: 0x08E5, ttl: 253, TOS: 0 prot: 17, source port 18490, destination port 17228
!
! Lines omitted for brevity
continues
![](/html/1438/356/html_8qEWQlgVYy.fRAV/htmlconvd-rT6A6m549x1.jpg)
512 Chapter 7: Link-Efficiency Tools
Example 7-5 MLP LFI Configuration (Continued)
!
!
!STEP 4 STEP 4 STEP 4 STEP 4 STEP 4 STEP 4 STEP 4 STEP 4 STEP 4 STEP 4
!Adding RTP Priority Queuing configuration next. Did same on R1.
!
R3#conf t
Enter configuration commands, one per line. End with CNTL/Z. R3(config)#interface multilink 9
R3(config-if)#ip rtp priority 16384 16383 65
R3(config-if)#^Z R3#
R3#show interfaces multilink 9
Multilink9 is up, line protocol is up Hardware is multilink group interface Internet address is 192.168.99.253/24
MTU 1500 bytes, BW 128 Kbit, DLY 100000 usec, reliability 255/255, txload 231/255, rxload 41/255
Encapsulation PPP, loopback not set Keepalive set (10 sec)
DTR is pulsed for 2 seconds on reset LCP Open, multilink Open
Open: IPCP
Last input 00:00:03, output never, output hang never Last clearing of "show interface" counters 00:23:36
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 1784 Queueing strategy: weighted fair
Output queue: 17/1000/64/1783/4441 (size/max total/threshold/drops/interleaves) Conversations 5/11/32 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated) Available Bandwidth 31 kilobits/sec
30 second input rate 21000 bits/sec, 43 packets/sec
30 second output rate 116000 bits/sec, 59 packets/sec
10217 packets input, 618117 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 72195 packets output, 7661717 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
0 carrier transitions
R3#show queue multilink 9
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 1784 Queueing strategy: weighted fair
Output queue: 18/1000/64/1783/6643 (size/max total/threshold/drops/interleaves) Conversations 6/11/32 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated) Available Bandwidth 31 kilobits/sec
![](/html/1438/356/html_8qEWQlgVYy.fRAV/htmlconvd-rT6A6m550x1.jpg)
Link Fragmentation and Interleaving 513
Example 7-5 MLP LFI Configuration (Continued)
(depth/weight/total drops/no-buffer drops/interleaves) 1/0/0/0/0 Conversation 40, linktype: ip, length: 62
source: 192.168.3.254, destination: 192.168.99.251, id: 0x08E5, ttl: 253, TOS: 0 prot: 17, source port 18490, destination port 17228
(depth/weight/total drops/no-buffer drops/interleaves) 1/32384/11/0/1282 Conversation 0, linktype: ip, length: 74
source: 192.168.3.100, destination: 192.168.1.100, id: 0xED88, ttl: 127, TOS: 0 prot: 6, source port 80, destination port 1513
!
!Lines omitted for brevity
!STEP 5 STEP 5 STEP 5 STEP 5 STEP 5 STEP 5 STEP 5 STEP 5 STEP 5 STEP 5
R3#show running-config
!Lines omitted for brevity
!
username R1 password 0 me
!
interface Multilink9 bandwidth 128
ip address 192.168.99.253 255.255.255.0 no ip route-cache cef
load-interval 30 fair-queue
no cdp enable ppp multilink
ppp multilink fragment-delay 10 ppp multilink interleave multilink-group 9
ip rtp priority 16384 16383 65
!
interface Serial0/1 bandwidth 128
no ip address encapsulation ppp no ip mroute-cache load-interval 30 clockrate 128000 ppp multilink multilink-group 9
!
! Lines omitted for brevity
!
![](/html/1438/356/html_8qEWQlgVYy.fRAV/htmlconvd-rT6A6m551x1.jpg)
514 Chapter 7: Link-Efficiency Tools
Cisco IOS Software enables you to use a couple of styles of configuration to configure MLP. This example shows the use of a virtual interface called a multilink interface. MLP needs to make more than one physical point-to-point link behave like a single link. To make that happen, IOS uses multilink interfaces to group together commands that normally would be applied to a physical interface. Each physical interface that is part of the same multilink group takes on the shared characteristics of the multilink interface. For instance, three parallel serial links in the same multilink group share a single IP address on one end of the link.
Example 7-5 is rather long. To help you find your way, the example includes comments lines with Step 1, Step 2, and so on. The following list explains these comments:
Step 1 In the example, multilink group 9 defines the interesting parameters in this example. Under the interface multilink 9 command, the IP address configuration (192.168.99.253), along with the bandwidth command, is listed. The multilink ppp command implies that this multilink group indeed uses multilink PPP. The multilink group 9 command tells IOS that this interface (multilink 9) is part of multilink group 9; this same command links each physical interface to the multilink group configuration. Now the interface configuration details that will be shared by all links in the same MLP bundle have been configured.
To add R3’s serial 0/1 interface to the MLP bundle, the multilink group 9 interface subcommand is added under serial 0/1. After the equivalent configuration has been added to R1, a single leased point-to-point serial link was up between R3 and R1, and each router was able to ping the other across the link.
Step 2 The example next shows the addition of the ppp multilink fragment-delay 10 command. Interestingly, this command does not enable fragmentation, but rather defines the maximum fragment size. Because the bandwidth was already set to 128, IOS calculates the fragment size as bandwidth * maxdelay (in seconds), or 128,000 * .01, which results in a 1280 bit (160 byte) fragment size.
Before the ppp multilink fragment-delay 10 command was added, in this example, MLP did not fragment. If the ppp multilink fragment-delay command had not been added, and four links were active in the MLP bundle, MLP would fragment frames into four equal-sized fragments. If three links were active, each frame would be fragmented into three equal-sized fragments, and so on. With one active link, MLP does not actually fragment the frames until the ppp multilink fragment-delay command is added.
After adding the ppp multilink fragment-delay 10 command in the example, the voice-call quality did not improve. So far, the configuration asked for fragmentation, but not for interleaving. Without interleaving, the unfragmented packets still must wait on all the fragments of larger packets to be serialized. In the context of QoS, it seems rather silly not to automatically
![](/html/1438/356/html_8qEWQlgVYy.fRAV/htmlconvd-rT6A6m552x1.jpg)
Link Fragmentation and Interleaving 515
interleave the shorter, unfragmented frames. Remember, however, that MLP fragments frames to load balance across multiple links without running into the problems relating to out-of-order packets.
Step 3 To gain the QoS advantage of reducing serialization delay by interleaving packets, the ppp multilink interleave command is added to the configuration next. The show interfaces command that follows lists a (highlighted) line that now shows a counter for interleaved packets, with the counter indeed showing that some packets have been interleaved.
Now the example has added all the requirements for MLP LFI, and all seems well—but it is not! The voice quality is still barely tolerable, with long delay and many breaks in the speech. The voice quality still suffers because of the queuing tool, WFQ. Notice that the next command in the example, show queue multilink 9, lists a voice flow with some statistics highlighted for the voice flow. The command lists drops for the highlighted voice flow, which is making a large impact of voice quality. Although the voice packets that get serviced do get interleaved, causing the interleave counter in the show interfaces command to increment, the quality still suffers because of the queuing delay and drops.
Step 4 The best ways to prevent the drops is to enable Low Latency Queuing (LLQ) for the voice traffic. Just to have another example of IP RTP Priority for practice, I chose to use the IP RTP Priority feature, enabling it with the ip rtp priority 65 command. However, LLQ is still recommended today for voice traffic. After adding the ip rtp priority command, the show interfaces command still shows interleaves, which is good, but the show queue command does not show any drops for the voice flow. In fact, the voice-call quality improved significantly to the point that all New Jersey housewives would give the call a Mean Opinion Score of 5!
Step 5 The final configuration on R3 is listed at the end of the example for completeness.
Frame Relay Fragmentation Configuration
The configuration of FRF.12 requires very little effort in itself. However, FRF.12 requires FRTS, and for the FRF.12 interleaving function to actually work, you need to enable IP RTP Priority or LLQ for the shaping queues on one or more VCs. Therefore, although the FRF.12 new configuration details are brief, the related tools make the configuration a little longer.
![](/html/1438/356/html_8qEWQlgVYy.fRAV/htmlconvd-rT6A6m553x1.jpg)
516 Chapter 7: Link-Efficiency Tools
The show commands related to FRF.12 give a fairly detailed view into what is actually happening with fragmentation and are covered as part of a couple of examples. Tables 7-13 and 7-14 list the configuration and show commands, respectively, and are followed by two FRF.12 examples.
Table 7-13 Command Reference for Frame Relay Fragmentation
|
Command |
Mode and Function |
|
|
|
|
frame-relay traffic-shaping |
Interface subcommand; enables FRTS on the |
|
|
interface |
|
|
|
|
class name |
Interface DLCI subcommand; enables a specific |
|
|
FRTS map class for the DLCI |
|
|
|
|
frame-relay class name |
Interface or subinterface command; enables a |
|
|
specific FRTS map class for the interface or |
|
|
subinterface |
|
|
|
|
map-class frame-relay map-class-name |
Global configuration mode; Names a map class, and |
|
|
places user in map-class configuration mode. |
|
|
|
|
frame-relay fragment fragment_size |
Map-class configuration mode; enables FRF.12 for |
|
|
VCs using this class |
|
|
|
Table 7-14 Exec Command Reference for Frame Relay Fragmentation |
||
|
|
|
|
Command |
Function |
|
|
|
|
show frame-relay fragment [interface |
Shows fragmentation statistics |
|
interface] [dlci] |
|
|
|
|
|
show frame-relay pvc [interface-type |
Shows statistics about overall performance of a VC |
|
interface-number] [dlci] |
|
|
|
|
|
show queueing [interface atm-subinterface |
Lists configuration and statistical information about |
|
[vc [[vpi/] vci]]] |
the queuing tool on an interface |
|
|
|
The FRF.12 sample configuration that follows uses the same FRTS configuration details as one of the FRTS examples from Chapter 5, but with the FRF.12 configuration added. The criteria for the configuration is as follows:
•Clock rate is 128 kbps on the access links on each end of the VC between R3 and R1.
•Fragment to 10-ms fragments.
•Shape all traffic at a 64-kbps rate.
•Configure Tc for 10ms.
![](/html/1438/356/html_8qEWQlgVYy.fRAV/htmlconvd-rT6A6m554x1.jpg)
Link Fragmentation and Interleaving 517
•
•
•
Do not use a Be.
Enable the configuration on the subinterface.
Do not specify a particular queuing method for the shaping queue.
In the example, Client 1 downloads two to three web pages, each of which has two frames inside the page. Each web page uses two separate TCP connections to download two separate large JPG files. Client 1 also downloads a file using FTP get. In addition, a VoIP call is placed between extensions 3002 and 1002. Figure 7-16 shows the network used for the example, and Example 7-6 shows the configuration and some sample show commands.
Figure 7-16 Sample Network for FRF.12 Configuration
Note: All IP Addresses Begin 192.168.
Client1 |
|
|
|
|
|
|
|
|
|
Server1 |
||||||||||||
|
|
|
2.252 |
|
|
|
|
|
|
|
|
|
||||||||||
|
|
1.252 |
|
|
|
|
|
|
|
|
|
|
|
|||||||||
|
|
|
|
|
|
SW1 |
R1 |
|
s0/0 |
s0/0 R3 |
SW2 |
|
|
|
|
|
|
|||||
|
|
|
|
|
|
|
|
|
|
|
||||||||||||
1.100 |
|
|
|
|
|
|
|
|
|
|
|
|
3.100 |
|
|
|||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
3.254 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
R4
1001 1002
3001 3002
Example 7-6 FRF.12 Configuration Sample
R3#show running-config
!
! Many lines omitted for brevity
!
interface Serial0/0
description connected to FRS port S0. Single PVC to R1. no ip address
encapsulation frame-relay load-interval 30 clockrate 128000 bandwidth 128
frame-relay traffic-shaping
!
interface Serial0/0.1 point-to-point
description point-point subint global DLCI 103, connected via PVC to DLCI 101 ( ip address 192.168.2.253 255.255.255.0
frame-relay class shape-all-64
continues
![](/html/1438/356/html_8qEWQlgVYy.fRAV/htmlconvd-rT6A6m555x1.jpg)
518 Chapter 7: Link-Efficiency Tools
Example 7-6 FRF.12 Configuration Sample (Continued)
frame-relay interface-dlci 101 IETF
!
interface Serial0/0.2 point-to-point
description point-to-point subint connected to DLCI 102 (R2) ip address 192.168.23.253 255.255.255.0
frame-relay interface-dlci 102
!
!
! Many lines omitted for brevity
!
map-class frame-relay shape-all-64 frame-relay traffic-rate 64000 640 no frame-relay adaptive-shaping frame-relay fair-queue
frame-relay fragment 160
! |
|
|
|
|
|
|
|
|
|
|
R3#show frame-relay fragment interface s 0/0.1 101 |
|
|
|
|
|
|||||
fragment size 160 |
|
|
|
fragment type end-to-end |
|
|
||||
|
|
|
|
|
|
|
|
|||
in fragmented pkts 52 |
|
|
out fragmented pkts 9367 |
|
|
|||||
in fragmented bytes 5268 |
|
out fragmented bytes 1511866 |
|
|
||||||
in un-fragmented pkts 5552 |
|
out un-fragmented pkts 6320 |
|
|
|
|
||||
in un-fragmented bytes 341743 |
|
|
|
|
|
|
||||
|
out un-fragmented bytes 405268 |
|
|
|||||||
in assembled pkts 5577 |
|
|
out pre-fragmented pkts 7387 |
|
|
|
||||
in assembled bytes 346749 |
|
|
|
|
||||||
|
out pre-fragmented bytes 1862784 |
|
||||||||
in dropped reassembling pkts 0 |
|
out dropped fragmenting pkts 0 |
|
|
||||||
in timeouts 0 |
|
|
|
|
|
|
|
|
|
|
in out-of-sequence fragments 0 |
|
|
|
|
|
|
|
|
||
in fragments with unexpected B bit set 0 |
|
|
|
|
|
|
||||
in fragments with skipped sequence number 0 |
|
|
|
|
|
|
||||
out interleaved packets 0 |
|
|
|
|
|
|
|
|
||
R3#show frame-relay fragment |
|
|
|
|
|
|
|
|
||
interface |
dlci |
frag-type |
frag-size |
in-frag |
out-frag |
dropped-fr |
||||
ag |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Serial0/0.1 |
101 |
end-to-end |
160 |
|
54 |
9700 |
|
|
0 |
|
|
|
|
|
|
|
|
|
|
|
|
R3#show frame-relay pvc
PVC Statistics for interface Serial0/0 (Frame Relay DTE)
|
Active |
Inactive |
Deleted |
Static |
Local |
2 |
0 |
0 |
0 |
Switched |
0 |
0 |
0 |
0 |
Unused |
0 |
0 |
0 |
0 |
DLCI = 101, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.1
input pkts 6094 |
output pkts 7926 |
in |
bytes 379217 |
out bytes 1998660 |
dropped pkts 0 |
in |
FECN pkts 0 |
in BECN pkts 0 |
out FECN pkts 0 |
out BECN pkts 0 |
![](/html/1438/356/html_8qEWQlgVYy.fRAV/htmlconvd-rT6A6m556x1.jpg)
|
|
|
|
|
Link Fragmentation and Interleaving 519 |
|
|
|
|
|
|||
Example 7-6 FRF.12 Configuration Sample (Continued) |
|
|
||||
|
in DE pkts 0 |
|
out DE pkts 0 |
|
||
|
|
|
||||
|
out bcast pkts 31 |
out bcast bytes 2416 |
|
|||
|
pvc create time 00:25:19, last time pvc status changed 00:15:50 |
|
||||
|
R3#show interface s 0/0 |
|
|
|
||
|
Serial0/0 is up, line protocol is up |
|
|
|||
|
Hardware is PowerQUICC Serial |
|
|
|||
|
Description: connected to FRS port S0. Single PVC to R1. |
|
||||
|
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, |
|
||||
|
reliability 255/255, txload 20/255, rxload 4/255 |
|
||||
|
Encapsulation FRAME-RELAY, loopback not set |
|
||||
|
Keepalive set |
(10 sec) |
|
|
|
|
|
LMI enq sent |
14, LMI stat recvd 14, LMI upd recvd 0, DTE LMI up |
|
|||
|
LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0 |
|
||||
|
LMI DLCI 1023 |
LMI type is CISCO |
frame relay DTE |
|
||
|
Broadcast queue 0/64, broadcasts sent/dropped 65/0, interface broadcasts 61 |
|
||||
|
Last input 00:00:03, output 00:00:00, output hang never |
|
||||
|
Last clearing of "show interface" counters 00:02:20 |
|
||||
|
|
|
|
|||
|
Queueing strategy: dual fifo |
|
|
|||
|
Output queue: high size/max/dropped 0/256/0 |
|
||||
|
Output queue 77/128, 176 drops; input queue 0/75, 0 drops |
|
||||
|
30 second input rate 26000 bits/sec, 51 packets/sec |
|
||||
|
30 second output rate 122000 bits/sec, 126 packets/sec |
|
||||
|
6599 packets input, 409250 bytes, 0 no buffer |
|
||||
|
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles |
|
||||
|
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort |
|
||||
|
17824 packets output, 2169926 bytes, 0 underruns |
|
||||
|
0 output errors, 0 collisions, 0 interface resets |
|
||||
|
0 output buffer failures, 0 output buffers swapped out |
|
||||
|
0 carrier transitions |
|
|
|
||
|
DCD=up |
DSR=up DTR=up |
RTS=up |
CTS=up |
|
|
|
R3#show queueing interface s 0/0 |
|
|
|||
|
|
|
||||
|
Interface Serial0/1 queueing strategy: priority |
|||||
|
|
|
||||
|
Output queue utilization (queue/count) |
|||||
|
high/0 medium/0 normal/16513 low/0 |
|
||||
|
! |
|
|
|
|
|
|
! Many lines |
omitted for brevity |
|
|
||
|
! |
|
|
|
|
|
|
|
|
|
|
|
|
Take a look at the highlighted configuration at the beginning of the example. FRF is configured with the frame-relay fragment command inside a map-class command. In this case, the fragment size was set to 160 bytes, which at a clock rate of 128 kbps implies 10 ms of serialization delay for the longest frame. The rest of the configuration enables FRTS on serial 0/0.1, which enables fragmentation, because the frame-relay fragment 160 command sits inside map-class frame-relay shape-all-64. To review, FRTS is enabled for all VCs on interface s0/0 by the frame-relay traffic-shaping command on the physical interface. To use the specific
![](/html/1438/356/html_8qEWQlgVYy.fRAV/htmlconvd-rT6A6m557x1.jpg)
520 Chapter 7: Link-Efficiency Tools
parameters in the shape-all-64 map class, the frame-relay class shape-all-64 command is used under interface s0/0.1, causing FRTS to use the shaping parameters in the map class, rather than defaults, for the VC to R1.
The next command in the example, show frame-relay fragment int s 0/0.1 101, lists most of the detailed statistics about FRF behavior. It lists counters for input and output packets and bytes as you might expect. In the example, 405,268 bytes have been sent in unfragmented frames, and 1,511,866 bytes in the fragmented frames, for a total of 1,917,134 bytes. It also lists a measurement of the number of output bytes that would have been sent had fragmentation not been used, as shown in the counters labeled “pre-fragmented.” The number of prefragmented bytes, listed as 1,862,784 in the command, implies that R3 sent about 55,000 more bytes than it otherwise would have had to send had fragmentation not been used.
The shorter version of the same command, show frame-relay fragment, lists the basic configuration settings and just the counter of input and output fragmented packets.
The show frame-relay pvc command lists statistics for each VC, but the counters represent values before fragmentation occurs. To see how the counters in this command and the show frame-relay fragment command compare, examine the highlighted value for packets sent, and the value of prefragmented output packets in the show frame-relay fragment command. The show frame-relay pvc command lists 7926 packets sent. The show frame-relay fragment command lists 7387 prefragmented packets sent, which is only a few less than what was seen in the show frame-relay pvc command that was typed just a few seconds later. Therefore, the show frame-relay pvc command counters are based on the packets before fragmentation.
Next, the show interfaces serial 0/0 command lists one last tidbit of insight into FRF operation. The highlighted portion of the command output lists the queuing method as Dual FIFO. As explained earlier, FRF causes two physical interface output queues to be used, as shown in Figure 7-9. The High queue gets PQ-like treatment, which is how FRF interleaves frames between the fragments in the other FRF output queue.
The final command in the example actually drives home two essential points. The show queueing interface serial 0/0 command lists information about queuing on interface serial 0/0, just
as was seen many times in Chapter 4. In this case, it describes the queuing on the physical interface, which we call Dual FIFO. Notice, however, that the command lists the queuing method as “priority,” and it lists counters for four queues, named High, Medium, Normal, and Low. So although the queuing method is called Dual FIFO, it behaves like PQ, with only two queues in use.
You may have noticed that the only queue with nonzero counters in the show queueing command is the Normal queue. With FRF.12, the only way to get a packet into the High interface queue is to use IP RTP Priority or LLQ on a shaping queue. In the previous example, the default queuing tool, WFQ, is used on the shaping queues. The next example shows a more typical configuration, with LLQ in use. Networks that need FRF.12 most often are those supporting voice traffic. These same networks need to use LLQ in the shaping queues to help reduce delay and jitter, and use FRF to reduce serialization delay. Shaping should also be tuned with a low
![](/html/1438/356/html_8qEWQlgVYy.fRAV/htmlconvd-rT6A6m558x1.jpg)
Link Fragmentation and Interleaving 521
Tc value, to reduce the delay waiting for the next shaping interval. The next example uses a class map called shape-all-96-shortTC, which includes FRF.12, LLQ, with shaping using a 10-ms Tc.
This next example also oversubscribes the access link from R3 to the FR cloud. When supporting voice, Cisco recommends to not oversubscribe an access link. However, many data-oriented Frame Relay designs purposefully oversubscribe the access links. Therefore, when the time comes to add VoIP traffic, increasing the CIRs on all the VCs may not be financially possible. This example uses two VCs, with each shaped at 96 kbps, with a 128-kbps access rate. Figure 7-17 outlines the network.
Figure 7-17 Frame Relay Network with the R3 Access Link Oversubscribed
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Client2 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
SW1 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
R1 |
|
128-kbps Access Rate |
|
|
|
|
|
|
|
|
|||||||||
Note: All IP Addresses Begin 192.168. |
|
Each VC Shaped at 96 kbps |
|
|
|
|
|
|
|
|||||||||||||||||||||||||
|
|
|
|
|||||||||||||||||||||||||||||||
Client1 |
2.252 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Server1 |
|||||||||||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||||||||
|
|
|
|
|
|
|
1.252 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
SW1 |
|
|
|
R1 |
|
s0/0 |
|
|
|
s0/0 R3 |
SW2 |
|
|
|
|
|
|
|||||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||||||||||||||||||
1.100 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
3.100 |
|
|
|||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
3.254 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
R4
1001 1002
3001 3002
The criteria for the example is as follows:
•Clock rate is 128 kbps on all access links.
•Fragment to 10-ms fragments.
•Shape all VCs at a 96-kbps rate.
•Set Tc to 10 ms.
•Do not use a Be.
•Configure LLQ, with VoIP in the low-latency queue, and all other traffic in another queue.
![](/html/1438/356/html_8qEWQlgVYy.fRAV/htmlconvd-rT6A6m559x1.jpg)
522 Chapter 7: Link-Efficiency Tools
In the example, Client 1 and Client 2 each download one web page, which has two frames inside the page. Each page download uses two separate TCP connections to download two separate large JPG files. Both PCs also download a file using FTP get. In addition, a VoIP call is placed between extensions 3002 and 1002. Figure 7-17 depicts the network used in the example. Example 7-7 shows the configuration and some sample show commands.
Example 7-7 Oversubscribed Access Link, with FRF.12, LLQ, and Tc = 10 ms
R3#show running-config
!
! Portions omitted for brevity
!
class-map match-all voip-rtp match ip rtp 16384 16383
!
!
policy-map voip-and-allelse class voip-rtp
priority 30
class class-default fair-queue
!
interface Serial0/0
description connected to FRS port S0. Single PVC to R1. no ip address
encapsulation frame-relay load-interval 30 clockrate 128000 bandwidth 128
frame-relay traffic-shaping
!
interface Serial0/0.1 point-to-point
description point-point subint global DLCI 103, connected via PVC to DLCI 101 ( ip address 192.168.2.253 255.255.255.0
frame-relay class shape-all-96-shortTC frame-relay interface-dlci 101 IETF
!
interface Serial0/0.2 point-to-point
description point-to-point subint connected to DLCI 102 (R2) ip address 192.168.23.253 255.255.255.0
frame-relay class shape-all-96-shortTC frame-relay interface-dlci 102
!
map-class frame-relay shape-all-96-shortTC no frame-relay adaptive-shaping frame-relay cir 96000
frame-relay bc 960
service-policy output voip-and-allelse frame-relay fragment 160
!
![](/html/1438/356/html_8qEWQlgVYy.fRAV/htmlconvd-rT6A6m560x1.jpg)
Link Fragmentation and Interleaving 523
Example 7-7 Oversubscribed Access Link, with FRF.12, LLQ, and Tc = 10 ms (Continued)
R3#show traffic-shape serial 0/0.1
Interface |
Se0/0.1 |
|
|
|
|
|
|
|
||
|
Access |
Target |
Byte |
Sustain |
Excess |
Interval |
Increment |
Adapt |
||
VC |
List |
|
Rate |
Limit |
bits/int |
bits/int |
(ms) |
(bytes) |
Active |
|
101 |
|
|
96000 |
120 |
960 |
0 |
|
|
120 |
- |
|
|
10 |
|
|||||||
R3#show traffic-shape serial 0/0.2 |
|
|
|
|
|
|||||
Interface |
Se0/0.2 |
|
|
|
|
|
|
|
||
|
Access |
Target |
Byte |
Sustain |
Excess |
Interval |
Increment |
Adapt |
||
VC |
List |
|
Rate |
Limit |
bits/int |
bits/int |
(ms) |
(bytes) |
Active |
|
102 |
|
|
96000 |
120 |
960 |
0 |
|
|
120 |
- |
|
|
10 |
|
|||||||
R3#show frame-relay fragment interface serial 0/0.1 101 |
|
|
||||||||
fragment size 160 |
|
|
fragment type end-to-end |
|
||||||
in fragmented pkts 14 |
|
|
out fragmented pkts 843 |
|
||||||
in fragmented bytes 1386 |
|
out fragmented bytes 135638 |
|
|||||||
in un-fragmented pkts 596 |
|
out un-fragmented pkts 1607 |
|
|||||||
in un-fragmented bytes |
35967 |
|
out un-fragmented bytes 103064 |
|
||||||
in assembled |
pkts 603 |
|
|
out pre-fragmented pkts 1706 |
|
|||||
in assembled |
bytes 37283 |
|
out pre-fragmented bytes 234764 |
|||||||
in dropped reassembling pkts 0 |
|
out dropped fragmenting pkts 0 |
|
|||||||
in timeouts 0 |
|
|
|
|
|
|
|
|
||
in out-of-sequence fragments 0 |
|
|
|
|
|
|
||||
in fragments |
with unexpected B bit set |
0 |
|
|
|
|
||||
in fragments |
with skipped sequence number 0 |
|
|
|
|
|||||
|
|
|
|
|
|
|
||||
out interleaved packets 662 |
|
|
|
|
|
|
||||
R3#show frame-relay fragment interface serial 0/0.2 102 |
|
|
||||||||
fragment size 160 |
|
|
fragment type end-to-end |
|
||||||
in fragmented pkts 0 |
|
|
out fragmented pkts 1541 |
|
||||||
in fragmented bytes 0 |
|
|
out fragmented bytes 235482 |
|
||||||
in un-fragmented pkts 285 |
|
out un-fragmented pkts 27 |
|
|||||||
in un-fragmented bytes |
12764 |
|
out un-fragmented bytes 1555 |
|
||||||
in assembled |
pkts 285 |
|
|
out pre-fragmented pkts 296 |
|
|||||
in assembled |
bytes 12764 |
|
out pre-fragmented bytes 227911 |
|||||||
in dropped reassembling pkts 0 |
|
out dropped fragmenting pkts 0 |
|
|||||||
in timeouts 0 |
|
|
|
|
|
|
|
|
||
in out-of-sequence fragments 0 |
|
|
|
|
|
|
||||
in fragments |
with unexpected B bit set |
0 |
|
|
|
|
||||
in fragments |
with skipped sequence number 0 |
|
|
|
|
out interleaved packets 0
R3#show policy-map interface serial 0/0.2
Serial0/0.2: DLCI 102 -
Service-policy output: voip-and-allelse
continues
![](/html/1438/356/html_8qEWQlgVYy.fRAV/htmlconvd-rT6A6m561x1.jpg)
524 Chapter 7: Link-Efficiency Tools
Example 7-7 Oversubscribed Access Link, with FRF.12, LLQ, and Tc = 10 ms (Continued)
Class-map: voip-rtp (match-all) 0 packets, 0 bytes
30 second offered rate 0 bps, drop rate 0 bps Match: ip rtp 16384 16383
Weighted Fair Queueing Strict Priority
Output Queue: Conversation 24 Bandwidth 30 (kbps) Burst 750 (Bytes) (pkts matched/bytes matched) 0/0 (total drops/bytes drops) 0/0
Class-map: class-default (match-any) 1440 packets, 1275806 bytes
30 second offered rate 55000 bps, drop rate 0 bps Match: any
R3#show queueing interface serial 0/0
Interface Serial0/0 queueing strategy: priority
Output queue utilization (queue/count) high/9514 medium/0 normal/34038 low/0
The FRF.12 configuration portion of the example is comprised again of a single command, frame-relay fragment 160, configured inside map-class frame-relay shape-all-96-shortTC. The rest of the configuration meets the other requirements stated before the example. The map class includes a setting of CIR to 96,000 bps, and a Bc of 960 bits, yielding a Tc value of 960/96,000, or 10 ms. The policy-map voip-and-allelse command defines LLQ for VoIP, with all other traffic being placed in the class-default queue. The service-policy output voip-and- allelse command under class-map frame-relay shape-all-96-shortTC enables LLQ for all VCs that use the class. FRTS is of course enabled on the physical interface, with the framerelay class shape-all-96-shortTC subinterface command causing each of the two VCs to use the FRTS parameters in the map class, rather than the FRTS defaults.
Immediately following the configuration in the example, two show frame-relay traffic-shaping commands verify the settings made in the configuration. Both show a calculated Tc value of 10 ms, and a Bc of 960.
Next comes a pair of show frame-relay fragment interface commands, one for subinterface s 0/0.1, and one for serial interface 0/0.2. On serial 0/0.1, the last line of output points out that interleaves did occur. For interleaves to occur, at least a small amount of congestion must occur on the physical interface. With two VCs shaped at 96 kbps, and a 128-kbps access link, and plenty of generated traffic, some congestion did occur. Notice however that serial 0/0.2 does not show any interleaved packets. All the traffic generated going from R3 to R2 was FTP and HTTP traffic, neither of which gets classified into the low-latency queue. In the show policy-map interface serial 0/0.2 command that ends the example, for instance, notice that the counters