-
Cisco 10000 Series Router Quality of Service Configuration Guide
-
Cisco 10000 Series Router Quality of Service Configuration Guide
-
About This Guide
-
Quality of Service Overview
-
Classifying Traffic
-
Configuring QoS Policy Actions and Rules
-
Attaching Service Policies
-
Distributing Bandwidth Between Queues
-
Policing Traffic
-
Marking Traffic
-
Prioritizing Services
-
Shaping Traffic
-
Overhead Accounting
-
Managing Packet Queue Congestion
-
Sharing Bandwidth Fairly During Congestion
-
Simultaneous Policy Maps
-
Defining QoS for Multiple Policy Levels
-
Oversubscribing Physical and Virtual Links
-
Fragmenting and Interleaving Real-Time and Nonreal-Time Packets
-
Configuring Dynamic Subscriber Services
-
Regulating Subscriber Traffic
-
Configuring Quality of Service for PVC Bundles
-
Configuring Quality of Service for MPLS Traffic
-
VLAN Tag-Based Quality of Service
-
Hierarchical Scheduling and Queuing
-
Configuring Frame Relay QoS Using Frame Relay Legacy Commands
-
QoS Policy Propagation Through the Border Gateway Protocol
-
Glossary
-
Feedback
Table Of Contents
Fragmenting and Interleaving Real-Time and Nonreal-Time Packets
Link Fragmentation and Interleaving
Feature History for Link Fragmentation and Interleaving
System Limits for Link Fragmentation and Interleaving
Configuration Commands for MLP-Based Fragmentation and Interleaving
interface multilink Command History
ppp multilink fragment-delay Command
ppp multilink interleave Command
ppp multilink fragmentation Command
ppp multilink fragment disable Command
Multilink PPP-Based Link Fragmentation and Interleaving
Feature History for MLP Over Serial-Based LFI
Performance and Scalability for MLP Over Serial-Based LFI
Restrictions and Limitations for MLP Over Serial-Based LFI
Line Card Support for MLP Over Serial-Based LFI
Single-VC MLP Over ATM-Based LFI
Feature History for Single-VC MLP Over ATM-Based LFI
Fragment Size Calculation for MLP Over ATM-Based LFI
MLP Bundle Interface and Service Policies
Performance and Scalability for Single-VC MLP Over ATM-Based LFI
Restrictions and Limitations for Single-VC MLP Over ATM-Based LFI
Line Card Support for MLP Over ATM-Based LFI
Multi-VC MLP Over ATM-Based LFI
Feature History for Multi-VC MLP Over ATM-Based LFI
Fragment Size Calculation for Multi-VC MLP Over ATM-Based LFI
MLP Bundle Interface and Service Policies
Performance and Scalability for Multi-VC MLP Over ATM-Based LFI
Restrictions and Limitations for Multi-VC MLP Over ATM-Based LFI
Line Card Support for MLP Over ATM-Based LFI
MLP Over Frame Relay-Based LFI
Feature History for MLP Over Frame Relay-Based LFI
Multilink Group Interfaces and Virtual Template Interfaces
MLP Bundle Interface and Service Policies
Fragment Size Calculation for MLP Over Frame Relay-Based LFI
Performance and Scalability for MLP Over Frame Relay-Based LFI
Restrictions and Limitations for MLP Over Frame Relay-Based LFI
Creating a MLP Bundle Interface
Enabling MLP on a Virtual Template Interface
Configuring a Shaping Policy for MLP Over Frame Relay-Based LFI
Adding a Serial Member Link to a MLP Bundle
Adding an ATM Member Link to a MLP Bundle
Adding a Frame Relay Member Link to a MLP Bundle
Moving a Member Link to a Different MLP Bundle
Removing a Member Link from a MLP Bundle
Feature History for FRF.12 Fragmentation
FRF.12 over Multilink Frame Relay
FRF.12 Fragmentation Inheritance
FRF.12 Fragmentation and Hierarchical Policies
PVC-Based FRF.12 Fragmentation
Interface-Based FRF.12 Fragmentation
Minimum Fragment Size for FRF.12 Fragmentation
Configuration Commands for FRF.12 Fragmentation
frame-relay fragment Command (Map-Class)
frame-relay fragment end-to-end Command (Interface)
Performance and Scalability for FRF.12 Fragmentation
Prerequisites for FRF.12 Fragmentation
Restrictions and Limitations for FRF.12 Fragmentation
Configuring PVC-Based FRF.12 Fragmentation
Enabling FRF.12 Fragmentation on a Map Class
Configuring a Hierarchical Policy and PVC-Based FRF.12 Fragmentation
Configuring Interface-Based FRF.12 Fragmentation
Configuration Example for Enabling Interface-Based FRF.12 Fragmentation
Configuration Examples for Link Fragmentation and Interleaving
Configuration Example for MLP Over Serial-Based LFI
Configuration Example for Single-VC MLP Over ATM-Based LFI
Configuration Example for Multi-VC MLP Over ATM-Based LFI
Configuration Example for MLP Over Frame Relay-Based LFI
Configuration Examples for PVC-Based FRF.12 Fragmentation
Configuration Example for Interface-Based FRF.12 Fragmentation
Verifying and Monitoring Link Fragmentation and Interleaving
Verification Example for MLP Over Serial-Based LFI
Verification Examples for FRF.12 Fragmentation
Fragmenting and Interleaving Real-Time and Nonreal-Time Packets
Integrating delay-sensitive real-time traffic with nonreal-time data packets on low-speed links can cause the real-time packets to experience long queuing delays while waiting for the larger nonreal-time packets to transmit. Real-time traffic, however, cannot tolerate delay. The challenge becomes how to integrate real-time and nonreal-time packets while reducing latency for the real-time packets. The Cisco 10000 series router addresses this by breaking larger data packets into fragments and interleaving the smaller real-time packets between the fragments. In this way, time-sensitive real-time traffic remains intact and does not experience excessive delay.
This chapter describes fragmentation and interleaving on the Cisco 10000 series router. It includes the following topics:
•
Link Fragmentation and Interleaving
•
•
•
Link Fragmentation and Interleaving
Link fragmentation and interleaving (LFI) is a method that allows long nonreal-time data packets to be fragmented into smaller frames and shorter real-time packets to be interleaved between the fragments. In this way, real-time delay-sensitive packets, such as voice over IP (VoIP), and nonreal-time delay-insensitive packets, such as data transfer, can be carried together on low-speed links without causing excessive delay to the real-time traffic.
Real-time delay-sensitive traffic becomes susceptible to increased latency when the network processes nonreal-time delay-insensitive packets. Long queuing delays can occur while real-time traffic waits for the nonreal-time packet to be transmitted. Therefore, controlling the maximum one-way end-to-end delay for time-sensitive traffic becomes challenging when integrating voice and data traffic.
An important part of delay is the time it takes to actually place the bits onto an interface, referred to as serialization delay. We recommend that serialization delay not exceed 20 ms. Serialization delay is calculated using the following formula:
Serialization Delay = Frame Size (bits) / Link Bandwidth (bps)
As shown in Figure 16-1, a nonreal-time data packet of 1500 bytes takes 214 ms to leave the router over a 56-kbps link. While waiting for the large data packet to transmit, the router queues real-time packets. However, real-time traffic cannot tolerate delay. For example, good voice quality requires delay to be less than 150 ms. By fragmenting the nonreal-time large data packet into smaller frames and interleaving real-time packets between the fragments, both real-time packets and data frames can be carried together on low-speed links, without causing excessive delay to the real-time traffic.
Figure 16-1 Integrating Voice and Data Packets on Low-Speed Links
The Cisco 10000 series router supports the following types of link fragmentation and interleaving (LFI):
•
•
•
•
•
Feature History for Link Fragmentation and Interleaving
System Limits for Link Fragmentation and Interleaving
Table 16-1 lists the system limits for link fragmentation and interleaving (LFI).
Note
Configuration Commands for MLP-Based Fragmentation and Interleaving
The following commands are used to configure Multilink PPP (MLP)-based fragmentation and interleaving:
•
•
•
•
interface multilink Command
To create and configure a multilink bundle, use the interface multilink command in global configuration mode. To remove a multilink bundle, use the no form of the command. By default, no multilink interfaces are configured.
interface multilink multilink-bundle-numberno interface multilink multilink-bundle-numberSyntax Description
interface multilink Command History
Usage Guidelines for the interface multilink Command
The following describes the range of valid values for multilink interfaces:
•
–
–
•
–
•
–
–
•
–
For releases prior to Cisco IOS Release 12.2(28)SB, the valid multilink interface range is 1 to 2,147,483,647.
ppp multilink Command
To enable Multilink PPP (MLP) on an interface, use the ppp multilink command in interface configuration mode. To disable MLP, use the no form of the command. By default, the command is disabled.
ppp multilinkno ppp multilinkppp multilink Command History
Usage Guidelines for the ppp multilink Command
The ppp multilink command applies only to interfaces that use Point-to-Point Protocol (PPP) encapsulation.
When you use the ppp multilink command, the first channel negotiates the appropriate Network Control Protocol (NCP) layers (such as the IP Control Protocol and IPX Control Protocol), but subsequent links negotiate only the Link Control Protocol (LCP) and MLP.
ppp multilink fragment-delay Command
To specify a maximum size in units of time for packet fragments on a Multilink PPP (MLP) bundle, use the ppp multilink fragment-delay command in interface configuration mode. To reset the maximum delay to the default value, use the no form of the command. By default, if fragmentation is enabled, the fragment delay is 30 milliseconds.
ppp multilink fragment-delay delay-maxno ppp multilink fragment-delay delay-maxSyntax Description
delay-max
Specifies the maximum amount of time, in milliseconds, that is required to transmit a fragment. Valid values are from 1 to 1000 milliseconds.
ppp multilink fragment-delay Command History
Usage Guidelines for the ppp multilink fragment-delay Command
The ppp multilink fragment-delay command is useful when packets are interleaved and traffic characteristics such as delay, jitter, and load balancing must be tightly controlled.
MLP chooses a fragment size on the basis of the maximum delay allowed. If real-time traffic requires a certain maximum boundary on delay, using the ppp multilink fragment-delay command to set that maximum time can ensure that a real-time packet gets interleaved within the fragments of a large packet.
By default, MLP has no fragment size constraint, but the maximum number of fragments is constrained by the number of links. If interleaving is enabled, or if the bundle contains links that have differing bandwidths, or if a fragment delay is explicitly configured with the ppp multilink fragment-delay command, then MLP uses a different fragmentation algorithm. In this mode, the number of fragments is unconstrained, but the size of each fragment is limited to the fragment-delay value, or 30 milliseconds if the fragment delay has not been configured.
The ppp multilink fragment-delay command is configured under the multilink interface. The value assigned to the delay-max argument is scaled by the speed at which a link can convert the time value into a byte value.
ppp multilink interleave Command
To enable interleaving of real-time packets among the fragments of larger nonreal-time packets on a Multilink PPP (MLP) bundle, use the ppp multilink interleave command in interface configuration mode. To disable interleaving, use the no form of the command. By default, interleaving is disabled.
ppp multilink interleaveno ppp multilink interleaveppp multilink interleave Command History
Usage Guidelines for the ppp multilink interleave Command
The ppp multilink interleave command applies to multilink interfaces, which are used to configure a bundle.
Interleaving works only when the queuing mode on the bundle is set to fair queuing.
If interleaving is enabled when fragment delay is not configured, the default delay is 30 milliseconds. The fragment size is derived from that delay, depending on the bandwidths of the links.
ppp multilink fragmentation Command
To enable packet fragmentation, use the ppp multilink fragmentation command in interface configuration mode. To disable fragmentation, use the no form of the command. By default, fragmentation is enabled.
ppp multilink fragmentationno ppp multilink fragmentationppp multilink fragmentation Command History
ppp multilink fragment disable Command
To disable packet fragmentation, use the ppp multilink fragment disable command in interface configuration mode. To enable fragmentation, use the no form of this command.
ppp multilink fragment disableno ppp multilink fragment disableppp multilink fragment disable Command History
Usage Guidelines for the ppp multilink fragment disable Command
The ppp multilink fragment delay and ppp multilink interleave commands have precedence over the ppp multilink fragment disable command. Therefore, the ppp multilink fragment disable command has no effect if these commands are configured for a multilink interface and the following message displays:
Warning: 'ppp multilink fragment disable' or 'ppp multilink fragment maximum' will be ignored, since multilink interleaving or fragment delay has been configured and have higher precedence.To completely disable fragmentation, you must do the following:
Router(config-if)# no ppp multilink fragment delayRouter(config-if)# no ppp multilink interleaveRouter(config-if)# ppp multilink fragment disableppp multilink group Command
To restrict a physical link to joining only a designated multilink group interface, use the ppp multilink group command in interface configuration mode. To remove the restriction, use the no form of the command. By default, this command is disabled.
ppp multilink group group-numberno ppp multilink group group-numberSyntax Description
ppp multilink group Command History
Usage Guidelines for the ppp multilink group Command
By default the ppp multilink group command is disabled, which means the link can negotiate to join any bundle in the system.
When the ppp multilink group command is configured, the physical link is restricted from joining any but the designated multilink group interface. If a peer at the other end of the link tries to join a different bundle, the connection is severed. This restriction applies when MLP is negotiated between the local end and the peer system. The link can still come up as a regular PPP interface.
Multilink PPP-Based Link Fragmentation and Interleaving
Interactive traffic such as Telnet and Voice over IP (VoIP) is susceptible to increased latency when the network processes large packets such as LAN-to-LAN FTP transfers traversing a WAN. Packet delay is especially significant when the FTP packets are queued on slow links within the WAN. To solve delay problems on slow bandwidth links, the router supports link fragmentation and interleaving (LFI) based on the Cisco implementation of Multilink PPP (MLP), which supports the fragmentation and packet-sequencing specifications in RFC 1990.
LFI allows reserve queues to be set up so that Real-Time Transport Protocol (RTP) streams can be mapped into a higher priority queue.
As shown in Figure 16-2, without fragmentation and interleaving nonreal-time data packets can overwhelm real-time packets such as voice. However, when fragmentation and interleaving is enabled, bandwidth is shared equitably between nonreal-time packets and real-time packets.
Figure 16-2 Fragmenting and Interleaving Packets
MLP fragmentation allows large packets to be multilink encapsulated and fragmented into a small enough size to satisfy the delay requirements of real-time traffic. MLP fragmentation is enabled by default. To disable fragmentation, use the no ppp multilink fragmentation or ppp multilink fragment disable command.
Small real-time packets are not multilink encapsulated. MLP interleaving provides a special transmit queue (priority queue) for delay-sensitive packets to allow the packets to be sent earlier than other packet flows. Real-time packets remain intact and are sent (interleaved) between the fragments of the larger packets.
The router supports MLP-based fragmentation and interleaving on serial, Frame Relay, and ATM links. For information on how MLP works and MLP-based LFI, see the following sections:
•
•
•
How MLP-Based LFI Works
To understand how MLP-based LFI works, it helps to understand the problem it addresses. The complete end-to-end delay target for real-time packets, especially voice packets, is 150 to 200 milliseconds (ms). The IP-based datagram transmission techniques for audio transmission do not adequately address the problems posed by limited bandwidth and the very stringent telephony delay bound of 150 ms.
Unacceptable queuing delays for small real-time packets exist regardless of the use of QoS features such as weighted fair queuing (WFQ), and the use of voice compression algorithms such as code excited linear prediction (CELP) compression, which reduces the inherent bit rate from 64 kbps to as low as 8 kbps. Despite these measures, real-time delay continues to exist because per-packet header overhead is too large and large maximum transmission units (MTUs) are needed to produce acceptable bulk transmission efficiency.
A large MTU of 1500 bytes takes 215 ms to traverse a 56-kbps line, which exceeds the delay target. Therefore, to limit the delay of real-time packets on relatively slow bandwidth links—links such as 56-kbps Frame Relay or 64-kbps ISDN B channels—a method for fragmenting larger packets and queuing smaller packets between fragments of the large packet is needed. MLP helps to solve this problem through LFI.
MLP provides a method of splitting, recombining, and sequencing datagrams across multiple logical data links. The LFI scheme is relatively simple: large datagrams are multilink encapsulated and fragmented to packets of a size small enough to satisfy the delay requirements of the delay-sensitive traffic; small delay-sensitive packets are not multilink encapsulated, but are interleaved between fragments of the large datagram.
MLP allows the fragmented packets to be sent at the same time over multiple point-to-point links to the same remote address. The multiple links come up in response to a dialer load threshold that you define. The load can be calculated on inbound traffic, outbound traffic, or on either, as needed for the traffic between the specific sites. MLP provides bandwidth on demand and reduces transmission latency across WAN links.
To ensure correct order of transmission and reassembly, LFI adds multilink headers to the datagram fragments after the packets are dequeued and ready to be sent.
MLP Over Serial-Based LFI
MLP over serial-based LFI uses the fragmentation and interleaving capability of MLP to integrate real-time packets (such as voice packets) and nonreal-time packets (such as data transfers) on the same link while reducing real-time packet latency.
MLP allows you to bundle T1 interfaces into logical groups. As indicated in Figure 16-3, you can configure a MLP bundle with up to 10 T1 links. Using MLP, you can create a degree of redundancy by configuring a MLP bundle that is made up of T1 links from more than one line card. If one line card stops operating, the part of the bundle on other line cards continues to operate.
Figure 16-3 shows a MLP bundle that consists of T1 interfaces from three T3 interfaces.
Figure 16-3 MLP Bundle
Feature History for MLP Over Serial-Based LFI
Performance and Scalability for MLP Over Serial-Based LFI
To enhance performance and scalability for MLP over serial-based LFI, configure the hold-queue command in interface configuration mode for all physical interfaces, except when configuring the ATM OC-12 line card. The OC-12 does not require the hold-queue command. For example:
Router(config-if)# hold-queue 4096 inFor more information, see the "Scalability and Performance" chapter in the Cisco 10000 Series Router Broadband Aggregation, Leased-Line, and MPLS Configuration Guide.
Restrictions and Limitations for MLP Over Serial-Based LFI
•
•
•
Router(config)# interface multilink 8•
•
•
Line Card Support for MLP Over Serial-Based LFI
The following line cards support MLP over serial-based LFI for the Cisco 10000 series router:
•
•
•
•
Single-VC MLP Over ATM-Based LFI
Single-VC MLP over ATM-based LFI uses the fragmentation and interleaving capability of MLP to integrate real-time and nonreal-time packets together on the same link. MLP defines the mechanisms to fragment, reassemble, and sequence large datagrams across multiple logical data links. MLP uses the fragmentation and packet sequencing specifications defined in RFC 1990 to implement link fragmentation and interleaving at the bundle level, supporting only one LFI-enabled member link per MLP bundle.
The following describes how MLP implements fragmentation and interleaving:
•
•
When configuring single-VC MLP over ATM-based LFI, you must configure a virtual template interface for the MLP bundle. However, the virtual template does not need to be unique for each bundle—multiple MLP bundles can share the same virtual template.
For more information about MLP, see the "Multilink PPP-Based Link Fragmentation and Interleaving" section and the Cisco 10000 Series Router Broadband Aggregation, Leased-Line, and MPLS Configuration Guide.
Feature History for Single-VC MLP Over ATM-Based LFI
Fragment Size Calculation for MLP Over ATM-Based LFI
For MLP over ATM-based LFI, the ideal fragment size should allow the fragments to fit into an exact multiple of ATM cells. Table 16-2 lists the minimum fragment sizes for Single-VC and Multi-VC MLP over ATM-based LFI. As shown in the table, the minimum fragment size depends on the AAL5 encapsulation type used and whether or not protocol compression is enabled.
To calculate the fragment size, do the following:
Step 1
(Link Bandwidth * Fragment-Delay) / 8Step 2
If the number of ATM cells is less than two, then use two ATM cells in Step 3. The minimum number of ATM cells you can have is 2.
Step 3
Number of Cells * 48Step 4
The AAL trailer is 8 bytes.
The number of MLP header bytes depends on the AAL5 encapsulation and whether or not protocol compression is enabled (see Table 16-3).
Table 16-3 lists the number of bytes in the MLP header, depending on the AAL5 encapsulation type and whether or not protocol compression is used.
MLP Bundle Interface and Service Policies
The router applies a service policy, attached to a multilink interface, to only the MLP bundle interface. The QoS actions defined by the service policy are applied to the outbound nonreal-time packets before the packets reach the bundle first-in first-out (FIFO) queue. The nonreal-time packets are fragmented in the FIFO queue and then the real-time packets are interleaved between the fragments as the real-time packets exit their priority queue.
Transmit Processing
The purpose of MLP over ATM-based LFI transmit processing is to fragment large nonreal-time delay-insensitive packets and interleave smaller real-time delay-sensitive packets between the fragments. Each MLP bundle has multiple transmit packet queues. MLP does not interleave packet fragments from different packet queues associated with a given MLP bundle. Instead, MLP transmits all of the fragments associated with a nonreal-time packet in order before transmitting fragments from another nonreal-time packet. MLP posts all of the packets from the various nonreal-time packet queues to a single bundle first-in first-out (FIFO) queue. It is from this single bundle queue that MLP does the following:
•
•
•
Real-time traffic, such as voice, are queued intact to a priority (low-latency) queue. It is from this queue that MLP transmits the real-time packets and interleaves them between the nonreal-time fragments. Because real-time packets are not MLP encapsulated or fragmented, MLP can safely interleave these packets as needed. Traffic transmitted from the priority queue takes precedence over the MLP encapsulated traffic that is transmitted from the related bundle queue.
Figure 16-4 shows an example of the packet flow of real-time and nonreal-time packets.
Figure 16-4 MLP Over ATM-Based LFI Packet Queue Flow
Receive Processing
The purpose of MLP over ATM-based LFI receive processing is to reassemble MLP over ATM encapsulated packet fragments into PPP over ATM packets. During receive processing, the fragments that arrive out of order and the packets with missing fragments are discarded. Valid fragments are merged in memory until the entire packet is reassembled.
Performance and Scalability for Single-VC MLP Over ATM-Based LFI
The following list describes how to enhance performance and scalability for Single-VC MLP over ATM-based LFI:
•
–
–
–
–
•
For more information, see the "Scalability and Performance" chapter in the Cisco 10000 Series Router Broadband Aggregation, Leased-Line, and MPLS Configuration Guide.
Restrictions and Limitations for Single-VC MLP Over ATM-Based LFI
•
•
•
•
•
•
•
•
•
Line Card Support for MLP Over ATM-Based LFI
The following line cards support MLP over ATM-based LFI for the Cisco 10000 series router:
•
•
•
Multi-VC MLP Over ATM-Based LFI
Multi-VC MLP over ATM-based LFI uses the fragmentation and interleaving capability of MLP to integrate real-time and nonreal-time packets together on the same link. MLP defines the mechanisms to fragment, reassemble, and sequence large datagrams across multiple logical data links. MLP uses the fragmentation and packet sequencing specifications defined in RFC 1990 to implement link fragmentation and interleaving at the bundle level. Multi-VC MLP over ATM-based LFI supports up to 10 member links per MLP bundle, one of which is LFI-enabled.
MLP encapsulates real-time packets as PPP over ATM (PPPoA) and sends the packets to a priority transmit queue to enable the router to transmit the real-time packets earlier than other packet flows. The router interleaves the real-time packets between the fragments of the larger, nonreal-time packet over a single point-to-point link to the remote address. Upon receipt, the receiving fragmentation peer processes the real-time packets as PPPoA packets.
MLP fragments the large data packets to a size small enough to satisfy the delay requirements of real-time traffic. MLP encapsulates the packets as MLP packets and sends the packets to a first-in first-out (FIFO) queue to enable the router to transmit the fragments at the same time over multiple point-to-point links to the same remote address. Upon receipt, the receiving fragmentation peer reassembles the fragments to the original packet and then processes it as PPPoA. The underlying PPP encapsulation conforms to RFC 1661.
MLP fragments all outbound MLP packets with a payload that is larger than the specified fragment size. The smallest fragment size depends on the AAL5 encapsulation type and whether or not protocol compression is enabled. For more information, see the "Fragment Size Calculation for MLP Over ATM-Based LFI" section.
When configuring Multi-VC MLP over ATM-based LFI, you must configure a virtual template interface for the MLP bundle. However, the virtual template does not need to be unique for each bundle—multiple MLP bundles can share the same virtual template.
Feature History for Multi-VC MLP Over ATM-Based LFI
Fragment Size Calculation for Multi-VC MLP Over ATM-Based LFI
For Multi-VC MLP over ATM-based LFI, the ideal fragment size should allow the fragments to fit into an exact multiple of ATM cells. Table 16-2 lists the minimum fragment sizes for Single-VC and Multi-VC MLP over ATM-based LFI. As shown in the table, the minimum fragment size depends on the AAL5 encapsulation type used and whether or not protocol compression is enabled.
For more information, see the "Fragment Size Calculation for MLP Over ATM-Based LFI" section.
MLP Bundle Interface and Service Policies
The router applies a service policy, attached to a multilink interface, to only the MLP bundle interface. The QoS actions defined by the service policy are applied to the outbound nonreal-time packets before the packets reach the bundle first-in first-out (FIFO) queue. The nonreal-time packets are fragmented in the FIFO queue and then the real-time packets are interleaved between the fragments as the real-time packets exit their priority queue.
Performance and Scalability for Multi-VC MLP Over ATM-Based LFI
The following list describes how to enhance performance and scalability for Multi-VC MLP over ATM-based LFI:
•
–
–
–
–
•
For more information, see the "Scalability and Performance" chapter in the Cisco 10000 Series Router Broadband Aggregation, Leased-Line, and MPLS Configuration Guide.
Restrictions and Limitations for Multi-VC MLP Over ATM-Based LFI
•
•
•
•
•
•
•
•
•
•
•
Line Card Support for MLP Over ATM-Based LFI
The following line cards support MLP over ATM-based LFI for the Cisco 10000 series router:
•
•
•
MLP Over Frame Relay-Based LFI
MLP over Frame Relay-based LFI uses the fragmentation and interleaving capability of MLP to transport real-time traffic (for example, voice) and nonreal-time traffic (for example, data transfers) together on low-speed Frame Relay permanent virtual circuits (PVCs) without causing excessive delay to the real-time traffic. MLP over Frame Relay-based LFI supports RFC 1990, The PPP Multilink Protocol.
MLP over Frame Relay-based LFI makes it possible for delay-sensitive packets and delay-insensitive packets to share the same link by fragmenting the long data packets into a sequence of smaller data packets referred to as fragments. The fragments are interleaved with the real-time packets. On the receiving side of the link, the fragments are reassembled and the packet is reconstructed. This method of fragmenting and interleaving helps guarantee the appropriate QoS for the real-time traffic.
When configuring MLP over Frame Relay-based LFI, you must configure a virtual template interface for the MLP bundle. The virtual template must be unique to only that bundle—multiple MLP bundles cannot share the same virtual template.
For more information about MLP, see the "Multilink PPP-Based Link Fragmentation and Interleaving" section and the Cisco 10000 Series Router Broadband Aggregation, Leased-Line, and MPLS Configuration Guide.
Feature History for MLP Over Frame Relay-Based LFI
Multilink Group Interfaces and Virtual Template Interfaces
You can configure MLP by assigning a multilink group to a virtual template interface configuration. Virtual templates allow a virtual access interface (VAI) to dynamically clone interface parameters from the specified virtual template. If you assign a multilink group to a virtual template and you assign the virtual template to a physical interface, all of the links that pass through the physical interface belong to the same multilink bundle.
MLP Bundle Interface and Service Policies
The router applies a service policy, attached to a multilink interface, to only the MLP bundle interface. The QoS actions defined by the service policy are applied to the outbound nonreal-time packets before the packets reach the bundle first-in first-out (FIFO) queue. The nonreal-time packets are fragmented in the FIFO queue and then the real-time packets are interleaved between the fragments as the real-time packets exit their priority queue.
Transmit Processing
The purpose of MLP over Frame Relay-based LFI transmit processing is to fragment large nonreal-time delay-insensitive packets and interleave smaller real-time delay-sensitive packets between the fragments. Each MLP bundle has multiple transmit packet queues. MLP does not interleave packet fragments from different packet queues associated with a given MLP bundle. Instead, MLP transmits all of the fragments associated with a nonreal-time packet in order before transmitting fragments from another nonreal-time packet. MLP posts all of the packets from the various nonreal-time packet queues to a single bundle first-in first-out (FIFO) queue.
It is from this single bundle queue that MLP does the following:
•
•
•
Real-time traffic, such as voice, are queued intact to a priority (low-latency) queue. It is from this queue that MLP transmits the real-time packets and interleaves them between the nonreal-time fragments. Because real-time packets are not MLP encapsulated or fragmented, MLP can safely interleave these packets as needed. Traffic transmitted from the priority queue takes precedence over the MLP encapsulated traffic that is transmitted from the related bundle queue.
Figure 16-4 shows an example of the packet flow of real-time and nonreal-time packets.
Figure 16-5 MLP Over Frame Relay-Based LFI Packet Queue Flow
Receive Processing
The purpose of MLP over Frame Relay-based LFI receive processing is to reassemble MLP over Frame Relay encapsulated packet fragments into PPP over ATM packets. During receive processing, the fragments that arrive out of order and the packets with missing fragments are discarded. Valid fragments are merged in memory until the entire packet is reassembled.
Fragment Size Calculation for MLP Over Frame Relay-Based LFI
To calculate the minimum fragment size for MLP over Frame Relay-based LFI, do the following:
Step 1
(Link Bandwidth * Fragment-Delay) / 8Step 2
Nominal Fragment Size - (Frame Relay Encap. Bytes + MLP Header Bytes + Cells Checksum)where:
Frame Relay Encapsulation Bytes is 4.
MLP Header Bytes is 4.
Cells Checksum is 2.
Step 3
For no protocol compression, subtract 2 bytes.
For MLP over Frame Relay-based LFI, the minimum fragment size is 56, calculated as follows:
(MLP Min. Weight) - (PPP Encapsulation Bytes) - (MLP Header Bytes) = Min. Fragment Sizewhere:
MLP Minimum Weight is 64
PPP Encapsulation Bytes is 4.
MLP Header Bytes is 4.
Performance and Scalability for MLP Over Frame Relay-Based LFI
The following list describes how to enhance performance and scalability for MLP over Frame Relay-based LFI:
•
–
–
–
–
•
For more information, see the "Performance and Scalability" chapter in the Cisco 10000 Series Router Broadband Aggregation, Leased-Line, and MPLS Configuration Guide.
Restrictions and Limitations for MLP Over Frame Relay-Based LFI
•
•
•
•
•
•
•
•
•
Configuring MLP-Based LFI
Table 16-4 lists the components you must configure for MLP-based LFI.
Table 16-4 Configuration Requirements for MLP-Based LFI
MLP over Serial-Based LFI
Required
Required
Not Required
Not Required
Single-VC MLP over ATM-Based LFI
Required
Required
Required
Required1
Multi-VC MLP over ATM-Based LFI
Required
Required
Required
Required
MLP over Frame Relay-Based LFI
Required
Required
Required
Required2
1 A service policy with a priority queue defined must be attached to the multilink interface. The VC does not require a service policy.
2 A service policy with the shape command defined must be attached to the VC. A service policy with a priority queue defined must be attached to the multilink interface.
To configure MLP-based fragmentation and interleaving, perform the following configuration tasks:
•
•
•
•
•
•
Creating a MLP Bundle Interface
To create a MLP bundle interface, enter the following commands beginning in global configuration mode:
Configuration Example for Creating a MLP Bundle Interface
Example 16-1 shows a sample configuration for creating a MLP bundle interface.
Example 16-1 Creating a MLP Bundle Interface
Router(config)# interface multilink 8Router(config-if)# ip address 172.16.48.209 255.255.0.0Router(config-if)# ppp chap hostname cambridgeRouter(config-if)# service-policy output bronzeRouter(config-if)# ppp multilinkRouter(config-if)# ppp multilink fragment-delay 50Router(config-if)# ppp multilink interleaveRouter(config-if)# ppp multilink group 8Router(config-if)# exitEnabling MLP on a Virtual Template Interface
The virtual template interface is attached to the member links, not to the MLP bundle. You can apply the same virtual template to the member links; you are not required to apply a unique virtual template to each member link.
To enable MLP on a virtual template, enter the following commands beginning in global configuration mode:
Configuration Example for Enabling MLP on a Virtual Template
Example 16-2 shows a sample configuration for enabling MLP on a virtual template.
Example 16-2 Enabling MLP on a Virtual Template
Router(config)# interface virtual-template1Router(config-if)# ppp max-configure 110Router(config-if)# ppp max-failure 100Router(config-if)# ppp timeout retry 5Router(config-if)# keepalive 30Router(config-if)# no ip addressRouter(config-if)# ip mroute-cacheRouter(config-if)# ppp authentication chapRouter(config-if)# ppp multilinkRouter(config-if)# exitConfiguring a Shaping Policy for MLP Over Frame Relay-Based LFI
MLP over Frame Relay-based LFI required that you configure a QoS policy that shapes traffic.
To configure a QoS policy that shapes traffic for MLP over Frame Relay-based LFI, enter the following commands beginning in global configuration mode:
Adding a Serial Member Link to a MLP Bundle
You can configure up to 10 member links per MLP bundle for MLP over serial-based LFI. You can also terminate the serial links on multiple line cards in the router chassis if all of the links are the same type, such as T1 or E1. The link speeds must be the same for all of the links in the bundle. If the interface you add to the MLP bundle contains information such as an IP address, routing protocol, or access list, the router ignores that information. If you remove the interface from the MLP bundle, that information becomes active again.
To add serial member links to a MLP bundle, enter the following commands beginning in global configuration mode:
Adding an ATM Member Link to a MLP Bundle
You can configure up to 10 member links per MLP bundle for Multi-VC MLP over ATM-based LFI. However, you can configure only one member link per MLP bundle for Single-VC MLP over ATM-based LFI.
To add ATM member links to a MLP bundle, enter the following commands beginning in global configuration mode:
Configuration Example for Adding ATM Links to a MLP Bundle
Example 16-3 shows how to add an ATM link to a MLP bundle. In the example, MLP is enabled on the interface named Multilink 10,000 and on the virtual template named virtual-template1. The maximum delay is set to 8 ms for the transmission of a packet fragment on the MLP bundle. The virtual template is applied to PVC 1/33 on ATM subinterface 4/0/0.1 and the PVC is associated with the MLP bundle.
Example 16-3 Adding ATM Links to a MLP Bundle
Router(config)# access-list 100 permit udp any any precedence critical!Router(config)# class-map BronzeRouter(config-cmap)# match access-group 100!Router(config-pmap)# policy-map BusinessRouter(config-pmap)# class BronzeRouter(config-pmap-c)# priorityRouter(config-pmap-c)# police 48!Router(config)# interface Multilink 10000Router(config-if)# ip address 10.6.6.1 255.255.255.0Router(config-if)# service-policy output PremiumRouter(config-if)# ppp multilinkRouter(config-if)# ppp multilink fragment-delay 8Router(config-if)# ppp multilink interleaveRouter(config-if)# ppp multilink group 10000Router(config-if)# exitRouter(config)# interface virtual-template1Router(config-if)# ppp max-configure 110Router(config-if)# ppp max-failure 100Router(config-if)# ppp timeout retry 5Router(config-if)# keepalive 30Router(config-if)# no ip addressRouter(config-if)# ppp multilinkRouter(config-if)# exitRouter(config)# interface atm 4/0/0Router(config-if)# hold-queue 4096 inRouter(config-if)# interface atm 4/0/0.1 point-to-pointRouter(config-subif)# pvc 1/33Router(config-if-atm-vc)# vbr-nrt 128 128 1Router(config-if-atm-vc)# encapsulation aal5snapRouter(config-if-atm-vc)# protocol ppp virtual-template1Router(config-if-atm-vc)# ppp multilink group 10000Adding a Frame Relay Member Link to a MLP Bundle
You can configure only one member link per MLP bundle for MLP over Frame Relay-based LFI.
To add a Frame Relay member link to a MLP bundle, enter the following commands beginning in global configuration mode:
Example 16-4 shows how to add Frame Relay links to a MLP bundle. In the example, MLP is enabled on the Multilink 20009 interface and on the virtual template named Virtual-Template 209. The service-policy named voip is applied to the Multilink 20009 interface. Virtual-Template 209 is applied to DLCI 18 on the serial subinterface 3/0/1.1.
Example 16-4 Adding Frame Relay Links to a MLP Bundle
frame-relay switchingclass-map match-all voipmatch ip rtp 16384 1000policy-map voipclass voipprioritypolice 24000 1000 0 conform-action transmit exceed-action drop violate-action droppolicy-map shapeclass class-defaultshape 100interface Multilink20009ip address 10.1.2.2 255.255.255.0ppp multilinkppp multilink fragment disableppp multilink fragment delay 8ppp multilink interleaveppp multilink group 20009service-policy output voipinterface serial 3/0/1no ip addressencapsulation frame-relayno keepalive!interface serial 3/0/1.1 point-to-pointno keepaliveframe-relay interface-dlci 18 ppp Virtual-Template209service-policy output shape!interface Virtual-Template209description mlp_lfi_c10kno ip addressppp chap hostname lfiofr-20009ppp multilinkppp multilink group 20009!Moving a Member Link to a Different MLP Bundle
To move a member link to a different MLP bundle, enter the following commands beginning in interface configuration mode:
Step 1
Router(config)# interface type number slot/module/port.channel:controller-number
Specifies the interface that you want to move to a different MLP bundle. Enters interface configuration mode.
Step 2
Router(config-if)# ppp chap hostname hostname
(Optional) Identifies the hostname sent in the Challenge Handshake Authentication Protocol (CHAP) challenge.
You must specify the same hostname as the one you assigned when you created the MLP bundle. For more information, see the "Creating a MLP Bundle Interface" section.
hostname is the name of the bundle group. This is the unique identifier that identifies the bundle.
Note
Step 3
Router(config-if)# ppp multilink group group-number
Moves this interface to the MLP bundle you specify.
group-number identifies the multilink group. Change this group-number to the new MLP group group-number. Valid values are:
•
–
–
•
–
•
–
–
•
–
Removing a Member Link from a MLP Bundle
To remove a member link from a MLP bundle, enter the following commands beginning in global configuration mode:
FRF.12 Fragmentation
FRF.12 Fragmentation uses Frame Relay Forum FRF.12-based fragmentation on Frame Relay permanent virtual circuits (PVCs) to allow long, nonreal-time data packets to be broken into smaller frames and shorter real-time packets to be interleaved between the fragments. In this way, real-time and nonreal-time packets can be carried together on low-speed links without causing excessive delay to the real-time traffic. The real-time packets remain intact and are less likely to experience long queuing delays.
FRF.12 fragmentation is defined by the FRF.12 Implementation Agreement. The router implements the end-to-end application of the FRF.12 standard. This application specifies fragmentation between two Frame Relay data terminal equipment (DTE) devices that are interconnected by one or more Frame Relay networks.
The following describes how FRF.12 mechanisms fragment and reassemble packets:
•
•
•
•
FRF.12 fragmentation transmits in order all fragments associated with a nonreal-time packet before transmitting fragments from another nonreal-time packet associated with the same PVC. When fragments arrive out of order, the receiving DTE detects and discards any packets that are missing fragments.
Figure 16-6 shows an example configuration of end-to-end fragmentation. When FRF.12 fragmentation is used between two peer DTEs, the fragmentation procedure is transparent to the Frame Relay networks between the transmitting and receiving DTEs.
Figure 16-6 End-to-End Fragmentation and Reassembly
You can configure FRF.12 Fragmentation at the PVC or interface level. For more information, see the "PVC-Based FRF.12 Fragmentation" section and the "Interface-Based FRF.12 Fragmentation" section.
Feature History for FRF.12 Fragmentation
FRF.12 over Multilink Frame Relay
To remove and re-attach service policies from the FRF.12 over Multilink Frame Relay configuration when traffic is running, use Example 16-5. In Example 16-5, you remove the map-class, and then remove the service policy.
Example 16-5 Remove the Map-Class Before Removing the Service Policy
int mfr2001.1no frame-relay class mfrno service-policy out mfr1int mfr2001.1service-policy out mfr1frame-relay class mfr
When traffic is stopped, you can remove and re-attach service policies using Example 16-6 and Example 16-7.
Example 16-6 Removing and Re-attaching the Service Policy
int mfr2001.1no service-policy out mfr1int mfr2001.1service-policy out mfr1Example 16-7 Remove the Service Policy Before Removing the Map-Class.
int mfr2001.1no service-policy out mfr1no frame-relay class mfrint mfr2001.1frame-relay class mfrservice-policy out mfr1FRF.12 Fragmentation Inheritance
Table 16-4 describes FRF.12 Fragmentation inheritance when you configure LFI on a Frame Relay interface, subinterface, or DLCI (either directly or using a map class with LFI enabled).
PVC-Based Frame Relay LFI Inheritance
Interface
All PVCs on the interface and its subinterfaces
Subinterface
All PVCs on the subinterface
DLCI
DLCI only
FRF.12 Fragmentation and Hierarchical Policies
To configure FRF.12 Fragmentation, you must first configure a hierarchical service policy and attach it to a Frame Relay interface, subinterface, or data-link connection identifier (DLCI) in one of the following ways:
•
•
Fragmentation is enabled only when a hierarchical service policy is attached. The hierarchical service policy you define must identify and allocate queues for real-time (priority) traffic and nonreal-time traffic.
Example 16-8 creates a serial T1 interface and defines a service policy for both real-time and nonreal-time traffic. You can create the T1 interface under any higher level channelized interface that supports T1 tributaries or the T1/E1 line card interface. In the example, the child policy map named policy_12_p0 defines QoS actions for three traffic classes: prec_q0 for priority traffic, prec_q1 for non-priority traffic, and prec_q2 for non-priority traffic. The parent policy map named policy_13 shapes traffic for all of the traffic classes to 256 kbps. The service-policy command is used to apply the child policy to the parent policy. When applying the service policy to an interface, subinterface, or DLCI, use the service-policy command and specify the output keyword for FRF.12 Fragmentation.
Example 16-8 Defining a Hierarchical Service Policy
Router(config)# t1 1 channel-group 1 timeslot 1-24 speed 56!Router(config)# class-map match-all prec_q2Router(config-cmap)# match ip precedence 2Router(config-cmap)# class-map match-all prec_q0Router(config-cmap)# match ip precedence 0Router(config-cmap)# class-map match-all prec_q1Router(config-cmap)# match ip precedence 1!Router(config)# policy-map policy_12_p0Router(config-pmap)# class prec_q0Router(config-pmap-c)# priorityRouter(config-pmap-c)# police 64000Router(config-pmap-c)# class prec_q1Router(config-pmap-c)# bandwidth percent 39Router(config-pmap-c)# class prec_q2Router(config-pmap-c)# bandwidth percent 4!Router(config)# policy-map policy_13Router(config-pmap)# class class-defaultRouter(config-pmap-c)# shape 256Router(config-pmap-c)# service-policy policy_12_p0For more information, see the "Configuring Interface-Based FRF.12 Fragmentation" section and Chapter 13 "Defining QoS for Multiple Policy Levels."
PVC-Based FRF.12 Fragmentation
PVC-based FRF.12 Fragmentation allows you to configure LFI on a per-PVC basis using a Frame Relay map class. Fragmentation is enabled in the map class and then the map class is associated with a specific Frame Relay subinterface or data-link connection identifier (DLCI). Each PVC performs fragmentation independently of other PVCs on its interface and each PVC has its own individual queues.
When using PVC-based FRF.12 Fragmentation, fragmentation is enabled only when the PVC or its subinterface has a hierarchical service policy. For more information, see the "FRF.12 Fragmentation and Hierarchical Policies" section and Chapter 13 "Defining QoS for Multiple Policy Levels."
Interface-Based FRF.12 Fragmentation
Interface-based FRF.12 Fragmentation allows you to configure LFI on a per-interface basis. When LFI is enabled on an interface, the interface treats all traffic on the interface as one group with one LFI setting, regardless of which PVC a packet belongs to.
For example, an Internet service provider (ISP) might offer multiple PVCs on an interface to the same subscriber. In this case, rather than introducing artificial bandwidth divisions among PVCs of the same subscriber, the service provider might want to treat all of the PVCs together and offer an aggregate quality of service with LFI at the Frame Relay interface.
When FRF.12 Fragmentation is enabled on an interface, all of the PVCs on the main interface and its subinterfaces have fragmentation enabled with the same configured fragment size. When the first PVC is set up, the interface queues become fragmentation queues. The main interface and all of its subinterfaces share the same set of queues.
When LFI is disabled for each PVC on a Frame Relay interface, interface fragmentation queues become normal queues when the last PVC is disabled.
Minimum Fragment Size for FRF.12 Fragmentation
FRF.12 Fragmentation fragments all outbound Frame Relay frames that are larger than the specified fragment size. Although you can configure from 16 to 1600 bytes as the fragment size, the minimum supported fragment size is 44 bytes. The default fragment size is 53 bytes.
Configuration Commands for FRF.12 Fragmentation
This section describes the commands that are used to configure FRF.12 Fragmentation. It includes the following commands:
•
•
frame-relay fragment Command (Map-Class)
To enable the fragmentation of Frame Relay frames on a Frame Relay map class, use the frame-relay fragment command in map-class configuration mode. To disable Frame Relay fragmentation, use the no form of the command. By default, fragmentation is disabled.
frame-relay fragment fragment_sizeno frame-relay fragment fragment_sizeSyntax Description
frame-relay fragment Command History
Usage Guidelines for the frame-relay fragment Command
Frame Relay fragmentation is enabled on a per-PVC basis. Before enabling Frame Relay fragmentation, you must first associate a Frame Relay map class with a specific data-link connection identifier (DLCI), and then enter map-class configuration mode and enable or disable fragmentation for that map class.
All of the fragments of a Frame Relay frame except the last one have a payload size that is equal to the fragment size. The last fragment has a payload that is less than or equal to the fragment size.
frame-relay fragment end-to-end Command (Interface)
To enable the fragmentation of Frame Relay frames on an interface, use the frame-relay fragment end-to-end command in interface configuration mode. To disable Frame Relay fragmentation, use the no form of the command.
frame-relay fragment fragment_size end-to-endno frame-relay fragment fragment_size end-to-endSyntax Description
frame-relay fragment end-to-end Command History
Usage Guidelines for the frame-relay fragment end-to-end Command
When you enable fragmentation on an interface, all of the PVCs on the main interface and its subinterfaces have fragmentation enabled with the same configured fragment size.
When configuring fragmentation on an interface with priority (low-latency) queuing, configure the fragment size to be greater than the largest high-priority frame that would be expected. This configuration prevents higher priority traffic from being fragmented and queued up behind lower priority fragmented frames. If the size of a priority frame is larger than the configured fragment size, the priority frame is fragmented.
All of the fragments of a Frame Relay frame except the last one have a payload size that is equal to the fragment size. The last fragment has a payload that is less than or equal to the fragment size.
Local Management Interface (LMI) traffic is not fragmented.
Performance and Scalability for FRF.12 Fragmentation
To enhance performance and scalability, configure the hold-queue command in interface configuration mode for all physical interfaces when configuring FRF.12 Fragmentation. For example:
Router(config-if)# hold-queue 4096 inPrerequisites for FRF.12 Fragmentation
•
•
•
Note
•
Note
Restrictions and Limitations for FRF.12 Fragmentation
PVC-Based Fragmentation
•
•
•
•
–
–
–
–
–
–
•
Interface-Based Fragmentation
•
•
•
•
•
•
Configuring PVC-Based FRF.12 Fragmentation
To configure PVC-based FRF.12 Fragmentation, perform the following configuration tasks:
•
•
Enabling FRF.12 Fragmentation on a Map Class
To enable FRF.12 Fragmentation on a Frame Relay map class, enter the following commands beginning in global configuration mode:
Attaching the Map Class
To attach the map class, perform the following configuration tasks:
•
•
•
Attaching a Map Class to a Frame Relay Interface or Subinterface
To attach a map class to a Frame Relay interface or subinterface, enter the following commands beginning in global configuration mode:
Configuration Examples for Attaching a Map Class to a Frame Relay Interface and Subinterface
Example 16-9 shows how to attach a map class with fragmentation enabled to a Frame Relay interface. In the example, fragmentation is enabled in the map class named lfi_map_class and the fragment size is set at 300 bytes. The QoS service policy named policy_13 is also applied to the map class for outbound traffic. The map class is applied to the serial interface 5/0/0/1:0, which has two subinterfaces configured. Serial subinterface 5/0/0/1:0.1 has DLCI 17 and subinterface 5/0/0/1:0.2 has DLCI 18. Because the map class with fragmentation enabled is applied to the main interface, traffic on DLCI 17 and DLCI 18 is subject to fragmentation and interleaving.
Example 16-9 Attaching a Map Class to a Frame Relay Interface
Router(config)# map-class frame-relay lfi_map_classRouter(config-map-c)# frame-relay fragment 300Router(config-map-c)# service-policy output policy_13Router(config-map-c)# no frame-relay adaptive-shaping!Router(config)# interface serial 5/0/0/1:0Router(config-if)# hold-queue 4096 inRouter(config-if)# no ip addressRouter(config-if)# no ip directed-broadcastRouter(config-if)# encapsulation frame-relayRouter(config-if)# frame-relay class lfi_map_class!Router(config)# interface serial 5/0/0/1:0.1 point-to-pointRouter(config-subif)# ip address 192.168.1.1 255.255.255.0Router(config-subif)# no ip directed-broadcastRouter(config-subif)# frame-relay interface-dlci 17!Router(config)# interface serial 5/0/0/1:0.2 point-to-pointRouter(config-subif)# ip address 192.168.2.1 255.255.255.0Router(config-subif)# no ip directed-broadcastRouter(config-subif)# frame-relay interface-dlci 18Example 16-10 shows how to attach a map class with fragmentation enabled to a subinterface. In the example, fragmentation is enabled in the map class named lfi_map_class and the fragment size is set at 300 bytes. The QoS service policy named policy_13 is also applied to the map class for outbound traffic. The map class is applied to the serial subinterface 5/0/0/1:0.1 on which DLCI 17 is configured. Therefore, Frame Relay traffic on DLCI 17 is subject to fragmentation and interleaving. Because the lfi_map_class is also attached to serial subinterface 5/0/0/1:0.2, traffic on DLCI 18 is also subject to fragmentation and interleaving.
Note
Example 16-10 Attaching a Map Class to a Frame Relay Subinterface
Router(config)# map-class frame-relay lfi_map_classRouter(config-map-c)# service-policy output policy_13Router(config-map-c)# frame-relay fragment 300Router(config-map-c)# no frame-relay adaptive-shaping!Router(config)# interface serial 5/0/0/1:0Router(config-if)# hold-queue 4096 inRouter(config-if)# no ip addressRouter(config-if)# no ip directed-broadcastRouter(config-if)# encapsulation frame-relay!Router(config)# interface serial 5/0/0/1:0.1 point-to-pointRouter(config-subif)# ip address 192.168.1.1 255.255.255.0Router(config-subif)# no ip directed-broadcastRouter(config-subif)# frame-relay class lfi_map_classRouter(config-subif)# frame-relay interface-dlci 17!Router(config)# interface serial 5/0/0/1:0.2 point-to-pointRouter(config-subif)# ip address 192.168.2.1 255.255.255.0Router(config-subif)# no ip directed-broadcastRouter(config-subif)# frame-relay class lfi_map_classRouter(config-subif)# frame-relay interface-dlci 18Attaching a Map Class to a Frame Relay DLCI
To attach a map class to a Frame Relay DLCI, enter the following commands beginning in global configuration mode:
Configuration Example for Attaching a Map Class to a Frame Relay DLCI
Example 16-11 shows how to attach a map class with LFI enabled to a Frame Relay DLCI. In the example, fragmentation is enabled in the map class named lfi_map_class and the fragment size is set at 300 bytes. The QoS service policy named policy_13 is also applied to the map class for outbound traffic. The main interface 5/0/0/1:0 has two subinterfaces with DLCI configured. The lfi_map_class is attached to DLCI 17 on subinterface 5/0/0/1:0.1. Therefore, the router fragments and interleaves only the traffic on DLCI 17 and applies the QoS actions defined in policy_13 to only DLCI 17 traffic.
Example 16-11 Attaching a Map Class to a Frame Relay DLCI
Router(config)# map-class frame-relay lfi_map_classRouter(config-map-c)# frame-relay fragment 300Router(config-map-c)# service-policy output policy_13Router(config-map-c)# no frame-relay adaptive-shaping!Router(config)# interface serial 5/0/0/1:0Router(config-if)# hold-queue 4096 inRouter(config-if)# no ip addressRouter(config-if)# no ip directed-broadcastRouter(config-if)# encapsulation frame-relay!Router(config)# interface serial 5/0/0/1:0.1 point-to-pointRouter(config-subif)# ip address 192.168.1.1 255.255.255.0Router(config-subif)# no ip directed-broadcastRouter(config-subif)# frame-relay interface-dlci 17Router(config-fr-dlci)# frame-relay class lfi_map_class!Router(config)# interface serial 5/0/0/1:0.2 point-to-pointRouter(config-subif)# ip address 192.168.2.1 255.255.255.0Router(config-subif)# no ip directed-broadcastRouter(config-subif)# frame-relay interface-dlci 18Attaching a Map Class to a Frame Relay Interface and a Service Policy to a Subinterface
To attach a map class to a Frame Relay interface and a service policy to a subinterface, enter the following commands beginning in global configuration mode:
Configuration Example for Attaching a Map Class to a Frame Relay Interface and a Service Policy to a DLCI
Example 16-12 shows how to attach a map class with fragmentation enabled to a Frame Relay interface and attach a service policy to a DLCI. In the example, fragmentation is enabled in the map class named lfi_map_class and the fragment size is set at 300 bytes. The map class is applied to the serial interface 5/0/0/1:0, which has two subinterfaces configured. DLCI 17 is configured on subinterface 5/0/0/1:0.1 and DLCI 18 is configured on subinterface 5/0/0/1:0.2. Because the map class with fragmentation enabled is applied to the main interface, all of the traffic on the main interface, the two subinterfaces, and the DLCIs is fragmented. However, because the service policy is applied directly on DLCI 17 and DLCI 18, only the traffic on those DLCIs is subject to the QoS actions defined in the service policy.
Example 16-12 Attaching a Map Class to a Frame Relay Interface and a Service Policy to a DLCI
Router(config)# map-class frame-relay lfi_map_class_oneRouter(config-map-c)# frame-relay fragment 300Router(config-map-c)# no frame-relay adaptive-shaping!Router(config)# interface serial 5/0/0/1:0Router(config-if)# hold-queue 4096 inRouter(config-if)# no ip addressRouter(config-if)# no ip directed-broadcastRouter(config-if)# encapsulation frame-relayRouter(config-if)# frame-relay class lfi_map_class!Router(config)# interface serial 5/0/0/1:0.1 point-to-pointRouter(config-subif)# ip address 192.168.1.1 255.255.255.0Router(config-subif)# no ip directed-broadcastRouter(config-subif)# frame-relay interface-dlci 17Router(config-fr-dlci)# service-policy output policy_13!Router(config)# interface serial 5/0/0/1:0.2 point-to-pointRouter(config-subif)# ip address 192.168.2.1 255.255.255.0Router(config-subif)# no ip directed-broadcastRouter(config-subif)# frame-relay interface-dlci 18Router(config-fr-dlci)# service-policy output policy_13Configuring a Hierarchical Policy and PVC-Based FRF.12 Fragmentation
To configure a hierarchical policy and PVC-based FRF.12 Fragmentation, perform the following configuration tasks:
•
•
•
•
Configuring the Child QoS Policy
To configure a child QoS policy, enter the following commands beginning in global configuration mode:
Step 1
Router(config)# policy-map policy-map-name
Creates or modifies the child policy. Enters policy-map configuration mode.
policy-map-name is the name of the policy map.
Step 2
Router(config-pmap)# class class-map-name
Assigns the traffic class you specify to the policy map. Enters policy-map class configuration mode.
class-map-name is the name of a previously configured class map and is the traffic class for which you want to define QoS actions.
Note
Step 3
Router(config-pmap-c)# priority
Configures a traffic class as a priority queue.
Note
Step 4
or
Router(config-pmap-c)# police [cir] percent percent [bc] normal-burst-in-msec [be] excess-burst-in-msec [conform-action action] [exceed-action action] [violate-action action]
or
police {cir cir} [bc] burst-normal [pir pir] [be] peak-burst [conform-action action] [exceed-action action] [violate-action action]
Configures single-rate traffic policing based on bits per second or as a percentage of the parent policy's shape rate, or configures two-rate traffic policing based on bits per second.
(Optional) cir is the committed information rate (CIR) and indicates an average rate at which the policer meters traffic. CIR is based on the interface shape rate.
percent percent indicates to use the percentage of available bandwidth specified in percent to calculate the CIR. Valid values are from 1 to 100.
[bc] burst-normal and [bc] normal-burst-in-msec specify the normal or committed burst size (CBS) that the first token bucket uses for policing traffic. Specify the burst-normal value in bytes and normal-burst-in-msec value in milliseconds (ms).
[be] burst-excess and [be] excess-burst-in-msec specify the excess burst size (EBS) used by the second token bucket for policing. Specify the burst-excess value in bytes and excess-burst-in-msec value in milliseconds (ms).
[be] peak-burst is the peak information rate (PIR). Indicates the rate at which the second token bucket is updated. The pir specifies the PIR value in bits per second.
For more information, see Chapter 6 "Policing Traffic."
Configuring the Parent QoS Policy
To configure the parent QoS policy, enter the following commands beginning in global configuration mode:
Enabling FRF.12 Fragmentation on a Frame Relay Map Class
To enable FRF.12 Fragmentation on a Frame Relay map class, enter the following commands beginning in global configuration mode:
Attaching a Map Class to a Frame Relay DLCI
To attach a map class to a Frame Relay DLCI, enter the following commands beginning in global configuration mode:
Configuration Example for Configuring a Hierarchical Policy and PVC-Based FRF.12 Fragmentation
Example 16-13 shows how use a hierarchical policy when fragmenting packets on a Frame Relay DLCI. In the example, access control lists (ACLs) 101 and 102 are defined and used as match criteria in two class maps to classify traffic. The child policy map named qos_pq_cbwfq_0 defines the traffic class named acl_101 as priority traffic and polices the traffic at 10 percent of the parent shape rate. The traffic class named acl_102 requests 30 percent of the bandwidth. The parent policy map named outer_policy shapes traffic at 768 kbps. The child policy is applied to the parent class-default class. The parent policy is applied to the map class named PQ_FR_CLASS_0. This map class sets the fragment size at 768 bytes. The map class is applied to DLCI 27 on serial interface 5/0/0/1:0.1.
Example 16-13 Configuring a Hierarchical Policy and PVC-Based FRF.12 Fragmentation
Router(config)# access-list 101 permit udp any eq 16384 any eq 16384Router(config)# access-list 102 permit udp any eq 3000 any eq 3000Router(config)# class-map match-all acl_101Router(config-cmap)# match access-group 101Router(config-cmap)# class-map match-all acl_102Router(config-cmap)# match access-group 102!Router(config)# policy-map qos_pq_cbwfq_0Router(config-pmap)# class acl_101Router(config-pmap-c)# priorityRouter(config-pmap-c)# police percent 10Router(config-pmap-c)# class acl_102Router(config-pmap-c)# bandwidth percent 30!Router(config-pmap)# policy-map outer_policyRouter(config-pmap)# class class-defaultRouter(config-pmap-c)# shape 768Router(config-pmap-c)# service-policy qos_pq_cbwfq_0!Router(config)# map-class frame-relay PQ_FR_CLASS_0Router(config-map-c)# service-policy output outer_policyRouter(config-map-c)# frame-relay fragment 768!Router(config)# interface serial 5/0/0/1:0Router(config-if)# hold-queue 4096 inRouter(config-if)# no ip addressRouter(config-if)# no ip directed-broadcastRouter(config-if)# encapsulation frame-relay!Router(config-if)# interface serial 5/0/0/1:0.1 point-to-pointRouter(config-if)# ip address 10.1.1.102 255.255.255.0Router(config-subif)# frame-relay interface-dlci 27Router(config-fr-dlci)# frame-relay class PQ_FR_CLASS_0Configuring Interface-Based FRF.12 Fragmentation
To configure interface-based FRF.12 Fragmentation, enter the following commands beginning in global configuration mode:
Configuration Example for Enabling Interface-Based FRF.12 Fragmentation
Example 16-14 shows how to enable FRF.12 Fragmentation on an interface. In the example, end-to-end FRF.12 fragmentation is enabled on the main serial interface 5/0/0/1:0 and the fragment size is set at 200 bytes. The service policy named Premium is attached to the main interface in the outbound direction. The main interface has two subinterfaces: serial subinterface 5/0/0/1:0.1 with DLCI 27 and subinterface 5/0/0/1:0.2 with DLCI 28.
Example 16-14 Enabling Interface-Based Fragmentation
Router(config)# interface serial 5/0/0/1:0Router(config-if)# hold-queue 4096 inRouter(config-if)# no ip addressRouter(config-if)# no ip directed-broadcastRouter(config-if)# encapsulation frame-relayRouter(config-if)# frame-relay fragment 200 end-to-endRouter(config-if)# service-policy output PremiumRouter(config-if)# interface serial 5/0/0/1:0.1 point-to-pointRouter(config-subif)# ip address 192.168.1.1 255.255.255.0Router(config-subif)# no ip directed broadcastRouter(config-subif)# frame-relay interface-dlci 27Router(config-subif)# interface serial 5/0/0/1:0.2 point-to-pointRouter(config-subif)# ip address 192.16.2.1 255.255.255.0Router(config-subif)# no ip directed broadcastRouter(config-subif)# frame-relay interface-dlci 28Configuration Examples for Link Fragmentation and Interleaving
This section provides the following configuration examples:
•
•
•
•
•
Configuration Example for MLP Over Serial-Based LFI
Example 16-15 shows a sample configuration for MLP over serial-based LFI. In the example, the MLP bundle named Multilink 2 consists of three serial links: 8/0/0.2/7:0, 8/0/0.2/8:0, and 8/0/0.2/9:0. Fragmentation and interleaving are both enabled on the bundle.
Example 16-15 Configuring MLP Over Serial-Based LFI
!Router(config)# controller SONET 8/0/0Router(config-controller)# framing SONETRouter(config-controller)# path 2 controller t3!Router(config)# controller T3 8/0/0.2Router(config-controller)# overhead c2 4Router(config-controller)# framing m23Router(config-controller)# t1 7 channel-group 0 timeslots 1-24Router(config-controller)# t1 8 channel-group 0 timeslots 1-24Router(config-controller)# t1 9 channel-group 0 timeslots 1-24!Router(config)# class-map match-all prec_5Router(config-cmap)# match ip precedence 5!Router(config)# policy-map policy_MLPLFIRouter(config-pmap)# class prec_5Router(config-pmap-c)# priorityRouter(config-pmap-c)# police 512000 9216 12000 conform-action transmit exceed-action set-prec-transmit 3 violate-action dropRouter(config-pmap-c)# class class-defaultRouter(config-pmap-c)# bandwidth remaining percent 20!Router(config)# interface Multilink2Router(config-if)# ip address 10.0.0.6 255.255.255.252Router(config-if)# load-interval 30Router(config-if)# ppp acfc local requestRouter(config-if)# ppp acfc remote applyRouter(config-if)# ppp chap hostname group2Router(config-if)# ppp multilinkRouter(config-if)# ppp multilink fragment delay 2Router(config-if)# ppp multilink interleaveRouter(config-if)# ppp multilink group 2Router(config-if)# service-policy output policy_MLPLFI!Router(config)# interface serial 8/0/0.2/7:0Router(config-subif)# no ip addressRouter(config-subif)# encapsulation pppRouter(config-subif)# load-interval 30Router(config-subif)# no fair-queueRouter(config-subif)# no keepaliveRouter(config-subif)# ppp chap hostname group2Router(config-subif)# ppp multilinkRouter(config-subif)# ppp multilink group 2!Router(config)# interface serial 8/0/0.2/8:0Router(config-subif)# no ip addressRouter(config-subif)# encapsulation pppRouter(config-subif)# load-interval 30Router(config-subif)# no fair-queueRouter(config-subif)# no keepaliveRouter(config-subif)# ppp chap hostname group2Router(config-subif)# ppp multilinkRouter(config-subif)# ppp multilink group 2!Router(config)# interface serial 8/0/0.2/9:0Router(config-subif)# no ip addressRouter(config-subif)# encapsulation pppRouter(config-subif)# load-interval 30Router(config-subif)# no fair-queueRouter(config-subif)# no keepaliveRouter(config-subif)# ppp chap hostname group2Router(config-subif)# ppp multilinkRouter(config-subif)# ppp multilink group 2Configuration Example for Single-VC MLP Over ATM-Based LFI
Example 16-16 shows a sample configuration for Single-VC MLP over ATM-based LFI. This configuration uses a multilink interface and a virtual template interface. In the example, MLP and the interleaving of Real-Time Transport Packets (RTP) is enabled on the Multilink 10,020 interface. The maximum delay allowed for the transmission of a packet fragment is 8 ms. The Multilink 10,020 interface is associated with the MLP bundle. The QoS service policy named Premium is attached to the Multilink 10,020 interface. MLP is enabled on the virtual template interface named virtual-template1, which is applied to PVC 0/32 on ATM subinterface 4/0/0.1. This PVC is associated with the bundle.
Example 16-16 Configuring Single-VC MLP Over ATM-Based LFI
Router(config)# access-list 100 permit udp any any precedence critical!Router(config)# class-map BusinessRouter(config-cmap)# match access-group 100!Router(config-pmap)# policy-map PremiumRouter(config-pmap)# class BusinessRouter(config-pmap-c)# priorityRouter(config-pmap-c)# police 48!Router(config)# interface Multilink10020Router(config-if)# ip address 172.16.0.1 255.255.0.0Router(config-if)# service-policy output PremiumRouter(config-if)# ppp multilinkRouter(config-if)# ppp multilink fragment-delay 8Router(config-if)# ppp multilink interleaveRouter(config-if)# ppp multilink group 10020Router(config-if)# ppp chap hostname router2!Router(config)# interface virtual-template1Router(config-if)# ppp max-configure 110Router(config-if)# ppp max-failure 100Router(config-if)# ppp timeout retry 5Router(config-if)# keepalive 30Router(config-if)# no ip addressRouter(config-if)# ppp authentication chapRouter(config-if)# ppp multilink!Router(config)# interface atm 4/0/0Router(config-if)# hold-queue 4096 in!Router(config)# interface atm 4/0/0.1 point-to-pointRouter(config-if)# pvc 0/32Router(config-if-atm-vc)# vbr-nrt 100 80 1Router(config-if-atm-vc)# encapsulation aal5snapRouter(config-if-atm-vc)# protocol ppp virtual-template1Router(config-if-atm-vc)# ppp multilink group 10020Configuration Example for Multi-VC MLP Over ATM-Based LFI
Example 16-17 shows how to configure Multi-VC MLP over ATM-based LFI. In the example, the virtual template named virtual-template 2 is applied to PVCs 101/34, 101/35, and 101/36. Each of these PVCs is assigned to MLP bundle group 8. Notice that all of the member links have the same encapsulation type. The router does not support member links with different encapsulation types.
Example 16-17 Configuring Multi-VC MLP Over ATM-Based LFI
Router(config)# access-list 100 permit udp any any precedence critical!Router(config)# class-map GoldRouter(config-cmap)# match access-group 100!Router(config-pmap)# policy-map BusinessRouter(config-pmap)# class GoldRouter(config-pmap-c)# priorityRouter(config-pmap-c)# police 48!Router(config)# interface Multilink8Router(config-if)# ip address 172.16.0.1 255.255.0.0Router(config-if)# service-policy output PremiumRouter(config-if)# ppp multilinkRouter(config-if)# ppp multilink fragment-delay 8Router(config-if)# ppp multilink interleaveRouter(config-if)# ppp multilink group 8Router(config-if)# ppp chap hostname router2Router(config)# interface virtual-template2Router(config-if)# ppp max-configure 110Router(config-if)# ppp max-failure 100Router(config-if)# ppp timeout retry 5Router(config-if)# keepalive 30Router(config-if)# no ip addressRouter(config-if)# ip mroute-cacheRouter(config-if)# ppp authentication chapRouter(config-if)# ppp multilink!Router(config)# interface atm 6/0/0Router(config-if)# no ip addressRouter(config-if)# hold-queue 4096 inRouter(config-if)# no atm ilmi-keepalive!Router(config)# interface atm 6/0/0.1 point-to-pointRouter(config-if)# no ip addressRouter(config-if)# pvc 101/34Router(config-if-atm-vc)# vbr-nrt 512 256 20Router(config-if-atm-vc)# encapsulation aal5muxRouter(config-if-atm-vc)# ppp virtual-template 2Router(config-if-atm-vc)# ppp multilink group 8!Router(config)# interface atm 6/0/0.2 point-to-pointRouter(config-if)# no ip addressRouter(config-if)# pvc 101/35Router(config-if-atm-vc)# vbr-nrt 512 256 20Router(config-if-atm-vc)# encapsulation aal5muxRouter(config-if-atm-vc)# ppp virtual-template 2Router(config-if-atm-vc)# ppp multilink group 8!Router(config)# interface atm 6/0/0.3 point-to-pointRouter(config-if)# no ip addressRouter(config-if)# pvc 101/36Router(config-if-atm-vc)# vbr-nrt 512 256 20Router(config-if-atm-vc)# encapsulation aal5muxRouter(config-if-atm-vc)# ppp virtual-template 2Router(config-if-atm-vc)# ppp multilink group 8Configuration Example for MLP Over Frame Relay-Based LFI
Example 16-18 shows how to add Frame Relay links to a MLP bundle. In the example, MLP is enabled on the Multilink 10002 interface and on the virtual template named Virtual-Template1. The service-policy named Business is applied to the Multilink 10002 interface. Virtual-Template 1 is applied to DLCI 101 on the serial subinterface 1/0/1.1.
Example 16-18 Configuring MLP Over Frame Relay-Based LFI
Router(config)# interface Multilink10002Router(config-if)# ip address 10.1.2.2 255.255.255.0Router(config-if)# ppp multilinkRouter(config-if)# ppp multilink fragment disableRouter(config-if)# ppp multilink fragment delay 8Router(config-if)# ppp multilink interleaveRouter(config-if)# ppp multilink group 10002Router(config-if)# service-policy output Business!Router(config)# interface serial1/0/1Router(config-if)# no ip addressRouter(config-if)# encapsulation frame-relayRouter(config-if)# no keepalive!Router(config)# interface serial1/0/1.1 point-to-pointRouter(config-if)# no keepaliveRouter(config-if)# frame-relay interface-dlci 18 ppp Virtual-Template209Router(config-if)# service-policy output Premium!Router(config)# interface Virtual-Template1Router(config-if)# description mlp_lfi_c10kRouter(config-if)# no ip addressRouter(config-if)# ppp chap hostname lfiofr-10002Router(config-if)# ppp multilinkRouter(config-if)# ppp multilink group 10002!Configuration Examples for PVC-Based FRF.12 Fragmentation
Example 16-19 shows how to use a map class to configure PVC-based FRF.12 Fragmentation and attach the map class to a main interface. In the example, fragmentation is enabled in the map class named frag and the fragment payload size is set at 40 bytes. The frag map class also enables weighted fair queuing and has the QoS service policy named Bronze applied for outbound traffic. The frag map class is associated with serial interface 1/0/0/1:0. The main interface has two subinterfaces configured: subinterface 1/0/0/1:0.1 with DLCI 100 and subinterface 1/0/0/1:0.2 with DLCI 101. Because the frag map class with fragmentation enabled is attached to the main interface, fragmentation is also enabled on DLCI 100 and DLCI 101.
Example 16-19 Configuring PVC-Based FRF.12 Fragmentation on an Interface Using a Map Class
Router(config)# map-class frame-relay fragRouter(config-map-c)# frame-relay cir 128000Router(config-map-c)# frame-relay bc 1280Router(config-map-c)# frame-relay fragment 40Router(config-map-c)# frame-relay fair-queueRouter(config-map-c)# service-policy output BronzeRouter(config-map-c)# no frame-relay adaptive-shaping!Router(config)# interface serial 1/0/0/1:0Router(config-if)# hold-queue 4096 inRouter(config-if)# no ip addressRouter(config-if)# no ip directed-broadcastRouter(config-if)# encapsulation frame-relayRouter(config-if)# frame-relay class frag!Router(config)# interface serial 1/0/0/1:0.1 point-to-pointRouter(config-subif)# ip address 192.168.1.1 255.255.255.0Router(config-subif)# no ip directed-broadcastRouter(config-if)# frame-relay interface-dlci 100!Router(config)# interface serial 1/0/0/1:0.2 point-to-pointRouter(config-subif)# ip address 192.168.2.1 255.255.255.0Router(config-subif)# no ip directed-broadcastRouter(config-subif)# frame-relay interface-dlci 101Example 16-20 shows how to use a map class to configure FRF.12 Fragmentation and attach the map class to a subinterface. In the example, the fragmentation is enabled on the map class named lfi-class1 and the map class is attached to serial subinterface 5/0/0/1:0.1. The QoS service policy named Business is also attached to subinterface 5/0/0/1:0.1. In this configuration, all of the traffic on subinterface 5/0/0/1:0.1 and all of the DLCIs configured on the subinterface are subject to fragmentation and interleaving.
Example 16-20 Configuring PVC-Based FRF.12 Fragmentation on a Subinterface Using a Map Class
Router(config)# map-class frame-relay lfi-class1Router(config-map-c)# frame-relay fragment 300Router(config-map-c)# no frame-relay adaptive-shaping!Router(config)# interface serial 5/0/0/1:0Router(config-if)# hold-queue 4096 inRouter(config-if)# no ip addressRouter(config-if)# no ip directed-broadcastRouter(config-if)# encapsulation frame-relay!Router(config)# interface serial 5/0/0/1:0.1 point-to-pointRouter(config-subif)# ip address 192.168.10.1 255.255.255.0Router(config-subif)# no ip directed-broadcastRouter(config-subif)# service-policy BusinessRouter(config-subif)# frame-relay class lfi-class1Router(config-subif)# frame-relay interface-dlci 101!Router(config)# interface serial 5/0/0/1:0.2 point-to-pointRouter(config-subif)# ip address 192.168.10.2 255.255.255.0Router(config-subif)# no ip directed-broadcastRouter(config-subif)# frame-relay interface-dlci 102Example 16-21 shows how to use a map class to configure FRF.12 Fragmentation and attach the map class to a Frame Relay DLCI. In the example, fragmentation is enabled in the Frame Relay map class named Voice and the fragment size is set at 320 bytes. The Voice map class also enables priority queuing. The policy map named Business is also applied to the Voice map class. The map class is attached to DLCI 20 configured on the point-to-point serial subinterface 7/0/0/1:0.1.
Example 16-21 Configuring PVC-Based FRF.12 Fragmentation on a DLCI Using a Map Class
Router(config)# map-class frame-relay VoiceRouter(config-map-c)# frame-relay fragment 320Router(config-map-c)# frame-relay ip rtp priority 16384 16383 25Router(config-map-c)# service-policy output BusinessRouter(config-map-c)# exitRouter(config)# interface serial 7/0/0/1:0Router(config-if)# hold-queue 4096 inRouter(config-if)# no ip addressRouter(config-if)# encapsulation frame-relay ietfRouter(config-if)# frame-relay intf-type dceRouter(config-if)# interface serial 7/0/0/1:0.1 point-to-pointRouter(config-subif)# ip address 10.32.0.1 255.255.255.0Router(config-subif)# frame-relay interface-dlci 20Router(config-fr-dlci)# frame-relay class VoiceConfiguration Example for Interface-Based FRF.12 Fragmentation
Example 16-22 shows how to configure FRF.12 Fragmentation on serial interface 3/0/0.1/1:0. In the example, the fragment size is set at 300 bytes. The service policy named 11q is attached to the serial interface 3/00/0.1/1:0 and applied to the outbound packets on the main interface, subinterface, and DLCIs. Because fragmentation is enabled directly on the main interface, all of the traffic on the main interface, the subinterfaces, and the DLCIs is subject to fragmentation and interleaving.
Example 16-22 Configuring Interface-Based FRF.12 Fragmentation
Router(config)# access-list 101 match ip any host 10.16.0.2Router(config)# class-map voiceRouter(config-cmap)# match access-group 101!Router(config)# policy-map llqRouter(config-pmap)# class voiceRouter(config-pmap-c)# priorityRouter(config-pmap-c)# police 64000Router(config-pmap-c)# class videoRouter(config-pmap-c)# bandwidth 32!Router(config)# interface serial 3/0/0.1/1:0Router(config-if)# hold-queue 4096 inRouter(config-if)# ip address 10.16.0.1 255.0.0.0Router(config-if)# encapsulation frame-relayRouter(config-if)# bandwidth 128Router(config-if)# clock rate 128000Router(config-if)# service-policy output llqRouter(config-if)# frame-relay fragment 300 end-to-endRouter(config-if)# end!Router(config)# interface serial 3/0/0.1/1:0.1 point-to-pointRouter(config-if)# ip address 172.16.1.2 255.255.255.0Router(config-if)# no ip directed-broadcastRouter(config-if)# frame-relay interface-dlci 109Verifying and Monitoring Link Fragmentation and Interleaving
The Cisco 10000 series routers collect information about the number of:
•
•
•
•
The PRE1 counts only output fragments while the PRE2 counts both fragments and packets.
To verify and monitor the configuration of link fragmentation and interleaving, enter the following commands in privileged EXEC mode:
Verification Example for MLP Over Serial-Based LFI
Example 16-23 shows sample output from the show ppp multilink interface command. This example displays information about the MLP over serial-based LFI configuration provided in Example 16-15.
Example 16-23 show ppp multilink interface Command Sample Output
Router# show ppp multilink interface Multilink2Multilink2, bundle name is group2Endpoint discriminator is group2Bundle up for 02:31:57, 1/255 loadReceive buffer limit 36000 bytes, frag timeout 1000 msBundle is Distributed0/0 fragments/bytes in reassembly list0 lost fragments, 0 reordered0/0 discarded fragments/bytes, 0 lost received0x0 received sequence, 0x1 sent sequenceC10K Multilink PPP infoBundle transmit infosend_seq_num 0x1Bundle reassembly infoexpected_seq_num: 0x000000Member links: 3 active, 0 inactive (max 10, min not set)Se8/0/0.2/7:0, since 02:31:57, 384 weight, 378 frag sizeSe8/0/0.2/9:0, since 00:03:46, 384 weight, 378 frag sizeSe8/0/0.2/8:0, since 00:03:06, 384 weight, 378 frag size HQF2_R2#Multilink2Service-policy output: policy_MLPLFIClass-map: prec_5 (match-all)217196 packets, 14334936 bytes30 second offered rate 264000 bps, drop rate 0 bpsMatch: ip precedence 5Output queue: 0/128; 217688/14367408 packets/bytes output, 0/0 dropsAbsolute priorityPolice:512000 bps, 9216 limit, 12000 extended limitconformed 214828 packets, 14178648 bytes; action: transmitexceeded 0 packets, 0 bytes; action: set-prec-transmit 3violated 0 packets, 0 bytes; action: dropClass-map: class-default (match-any)34314 packets, 2264904 bytes30 second offered rate 0 bps, drop rate 0 bpsMatch: anyOutput queue: 0/128; 33823/2232498 packets/bytes output, 0/0 dropsBandwidth : 46 kbps (Weight 3)Verification Examples for FRF.12 Fragmentation
Example 16-24 shows sample output from the show frame-relay fragment command. In this example, the command does not specify a specific interface or DLCI. Therefore, the output displays a summary of each subinterface and DLCI configured for fragmentation.
Example 16-24 show frame-relay fragment Command Sample Output—All Subinterfaces and DLCIs
Router# show frame-relay fragmentinterface dlci frag-type size in-frag out-frag dropped-fragse5/0/0/1:0.1 17 end-to-end 300 0 0 0se5/0/0/1:0.1 18 end-to-end 300 0 0 0Example 16-25 shows sample output from the show frame-relay fragment command when a specific interface is specified. The output displays fragmentation information for only the specified subinterface and DLCI (serial subinterface 3/0/0.1/1:0.1, DLCI 109).
Example 16-25 show frame-relay fragment Command Sample Output—Specific Subinterface and DLCI
Router# show frame-relay fragment interface serial 3/0/0.1/1:0.1 109fragment size 300 fragment type end-to-end in fragmented pkts 0 out fragmented pkts 1320 in fragmented bytes 0 out fragmented bytes 331760 in un-fragmented pkts 0 out un-fragmented pkts 0 in un-fragmented bytes 0 out un-fragmented bytes 0 in assembled pkts 0 out pre-fragmented pkts 0 in assembled bytes 0 out pre-fragmented bytes 0 in dropped reassembling pkts 0 out dropped fragmenting pkts 0 in DE fragmented pkts 0 out DE fragmented pkts 0 in DE un-fragmented pkts 0 out DE un-fragmented pkts 0 in timeouts 0 in out-of-sequence fragments 0 in fragments with unexpected B bit set 0 in fragments with skipped sequenceExample 16-26 shows sample output from the debug frame-relay fragment command for the specified interface and DLCI (serial interface 0/0, DLCI 109).
Example 16-26 debug frame-relay fragment Command Sample Output—Specific Interface and DLCI
Router# debug frame-relay fragment interface serial 0/0 109This may severely impact network performance.You are advised to enable 'no logging console debug'. Continue?[confirm]Frame Relay fragment/packet debugging is onDisplaying fragments/packets on interface Serial0/0 dlci 109 onlySerial0/0(i): dlci 109, rx-seq-num 126, exp_seq-num 126, BE bits set, frag_hdr 04 C0 7ESerial0/0(o): dlci 109, tx-seq-num 82, BE bits set, frag_hdr 04 C0 52
Related Documentation
This section provides hyperlinks to additional Cisco documentation for the features discussed in this chapter. To display the documentation, click the document title or a section of the document highlighted in blue. When appropriate, paths to applicable sections are listed below the documentation title.
FRF.12 End-to-End Fragmentation
Frame Relay Fragmentation Implementation Agreement, Frame Relay Forum, December, 1997
Voice over Frame Relay Using FRF.11 and FRF.12, Release 12.0(4)T feature module
Understanding and Troubleshooting Frame Relay Fragmentation
VoIP over Frame Relay with Quality of Service (Fragmentation, Traffic Shaping, LLQ / IP RTP Priority)
Interface-Based FRF.12 Fragmentation
Frame Relay Queuing and Fragmentation at the Interface, Release 12.2(14)S feature module
Cisco IOS Wide-Area Networking Configuration Guide, Release 12.3
Part 1: Wide-Area Networking Protocols > Configuring Frame Relay > Frame Relay Queueing and Fragmentation at the Interface
Link Fragmentation and Interleaving
Link Fragmentation and Interleaving for Frame Relay and ATM Virtual Circuits, Release 12.1(5)T feature module
Cisco IOS Quality of Service Solutions Configuration Guide
Link Efficiency Mechanisms > Link Efficiency Mechanisms Overview > Link Fragmentation and Interleaving for Frame Relay and ATM VCs
Configuring Link Fragmentation and Interleaving for Frame Relay and ATM Virtual Circuits
Multilink PPP (MLP)
Cisco 10000 Series Router Broadband Aggregation, Leased-Line, and MPLS Configuration Guide
RFC 1990, The PPP Multilink Protocol
Policy Maps
Cisco 10000 Series Router Quality of Service Configuration Guide
PPP Encapsulation
RFC 1661, The Point-to-Point Protocol
PPP in Frame Relay
RFC 1973, PPP in Frame Relay
PVC-Based FRF.12 Fragmentation
Release Notes for the Cisco 10000 Series for Cisco IOS Release 12.0(23)SX
