Cisco 10000 Series Router Quality of Service Configuration Guide
Fragmenting and Interleaving Real-Time and Nonreal-Time Packets
Downloads: This chapterpdf (PDF - 895.0KB) The complete bookPDF (PDF - 21.32MB) | Feedback

Fragmenting and Interleaving Real-Time and Nonreal-Time Packets

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

interface multilink Command History

ppp multilink Command

ppp multilink fragment-delay Command

ppp multilink interleave Command

ppp multilink fragmentation Command

ppp multilink fragment disable Command

ppp multilink group Command

Multilink PPP-Based Link Fragmentation and Interleaving

How MLP-Based LFI Works

MLP Over Serial-Based LFI

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

Transmit Processing

Receive Processing

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

Transmit Processing

Receive Processing

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

Configuring MLP-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

FRF.12 Fragmentation

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

Attaching the 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

Related Documentation


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

Multilink PPP-Based Link Fragmentation and Interleaving

FRF.12 Fragmentation

Configuration Examples for Link Fragmentation and Interleaving

Verifying and Monitoring Link Fragmentation and Interleaving

Related Documentation

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):

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 defines the mechanisms to fragment, reassemble, and sequence large datagrams across multiple logical data links. MLP over serial-based LFI supports up to 10 member links per MLP bundle, one of which is LFI-enabled. You can 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 router supports subrate T1 interfaces as member links. The link speeds must be the same for all of the links in the bundle.

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. Single-VC MLP over ATM-based LFI supports only one member link per MLP bundle and the link is LFI-enabled.

Multi-VC MLP over ATM-based LFI—Uses the fragmentation and interleaving capability of MLP to integrate real-time packets and nonreal-time packets on the same link while reducing real-time packet latency. MLP implements link fragmentation and interleaving at the bundle level. Multi-VC MLP over ATM-based LFI supports up to 10 member links, one of which is LFI-enabled.

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 uses the fragmentation and packet sequencing specifications defined in RFC 1990 to implement link fragmentation and interleaving at the bundle level. MLP over Frame Relay-based LFI supports only one member link per MLP bundle and the link is LFI-enabled.

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 fragments 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.

Feature History for Link Fragmentation and Interleaving

Cisco IOS Release
Description
Required PRE

Release 12.0(23)SX

The PVC-based FRF.12 Fragmentation feature and the MLP over Serial-based LFI feature were introduced on the router.

PRE1

Release 12.0(27)S

The FRF.12 Fragmentation feature was enhanced to enable interface-based FRF.12 fragmentation.

PRE1

Release 12.2(27)SBB

The following features were introduced on the PRE2: MLP over Serial-based LFI, MLP over Frame Relay-based LFI, Single-VC and Multi-VC MLP over ATM-based LFI, and PVC-based and Interface-based FRF.12 Fragmentation.

PRE2

Release 12.2(31)SB2

The following features were introduced on the PRE3: MLP over Serial-based LFI, MLP over Frame Relay-based LFI, Single-VC and Multi-VC MLP over ATM-based LFI, and PVC-based and Interface-based FRF.12 Fragmentation.

PRE3


System Limits for Link Fragmentation and Interleaving

Table 16-1 lists the system limits for link fragmentation and interleaving (LFI).

Table 16-1 System Limits for Link Fragmentation and Interleaving

Feature
Maximum No. of Members Per Bundle
Maximum No. of Bundles
Per System
Maximum No. of Member Links Per System
Multilink Interface Range
LFI
Supported

MLP over Serial-based LFI

10

1250

2500

1 to 9999
(Release12.2(28)SB and later)

1 to 9999 and 65,536 to 2,147,483,647 (Release 12.2(31)SB2 and later)

Yes

Interleaving on 1 member link

Single-VC MLP over ATM-based LFI

1

8192

8192

10,000 and higher

Yes

Interleaving on 1 member link

Multi-VC MLP over ATM-based LFI

10

1250

2500

1 to 9999
(Release12.2(28)SB and later)

1 to 9999 and 65,536 to 2,147,483,647 (Release 12.2(31)SB2 and later)

Yes

Interleaving on 1 member link

MLP over Frame Relay-based LFI

1

2048

2048

10,000 and higher

Yes

Interleaving on 1 member link

FRF.12 Fragmentation

NA

NA

4096

NA

Yes



Note The multilink interface ranges described in Table 16-1 require Cisco IOS Release 12.2(28)SB and later releases. For releases prior to Cisco IOS Release 12.2(28)SB, the valid multilink interface range is 1 to 2,147,483,647.


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

ppp multilink Command

ppp multilink fragment-delay Command

ppp multilink interleave Command

ppp multilink fragmentation Command

ppp multilink fragment disable Command

ppp multilink group Command

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-number
 
   
no interface multilink multilink-bundle-number

Syntax Description

multilink-bundle-number

A nonzero number that identifies the multilink bundle.


interface multilink Command History

Cisco IOS Release
Description

Release 12.0

The interface multilink command was introduced on the PRE1.

Release 12.2(16)BX

This command was introduced on the PRE2.

Release 12.2(28)SB

This command was integrated in Cisco IOS Release 12.2(28)SB for the PRE2.

Release 12.2(31)SB2

The range of valid values for multilink interfaces was changed from 1 to 9999 (Release 12.2(28)SB and later) to from 1 to 9999 and 65,536 to 2,147,483,647 for MLP over serial and multi-VC MLP over ATM.


Usage Guidelines for the interface multilink Command

The following describes the range of valid values for multilink interfaces:

MLP over Serial-based LFI

1 to 9999 (Cisco IOS Release 12.2(28)SB and later releases)

1 to 9999 and 65,536 to 2,147,483,647 (Cisco IOS Release 12.2(31)SB2 and later releases)

Single-VC MLP over ATM-based LFI

10,000 and higher (Cisco IOS Release 12.2(28)SB and later releases)

Multi-VC MLP over ATM-based LFI

1 to 9999 (Cisco IOS Release 12.2(28)SB and later releases)

1 to 9999 and 65,536 to 2,147,483,647 (Cisco IOS Release 12.2(31)SB2 and later releases)

MLP over Frame Relay-based LFI

10,000 and higher

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 multilink
 
   
no ppp multilink

ppp multilink Command History

Cisco IOS Release
Description

Release 12.0(23)SX

The ppp multilink command was introduced on the PRE1.

Release 12.2(16)BX

This command was introduced on the PRE2.

Release 12.2(28)SB

This command was integrated in Cisco IOS Release 12.2(28)SB for the PRE2.

Release 12.2(31)SB2

This command was introduced on the PRE3.


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-max
 
   
no ppp multilink fragment-delay delay-max

Syntax 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

Cisco IOS Release
Description

Release 12.0(23)SX

The ppp multilink fragment-delay command was introduced on the PRE1.

Release 12.2(16)BX

This command was introduced on the PRE2.

Release 12.2(28)SB

This command was integrated in Cisco IOS Release 12.2(28)SB for the PRE2.

Release 12.2(31)SB2

This command was introduced on the PRE3.


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 interleave
 
   
no ppp multilink interleave

ppp multilink interleave Command History

Cisco IOS Release
Description

Release 12.0(23)SX

The ppp multilink interleave command was introduced on the PRE1.

Release 12.2(16)BX

This command was introduced on the PRE2.

Release 12.2(28)SB

This command was integrated in Cisco IOS Release 12.2(28)SB for the PRE2.

Release 12.2(31)SB2

This command was introduced on the PRE3.


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 fragmentation
 
   
no ppp multilink fragmentation

ppp multilink fragmentation Command History

Cisco IOS Release
Description

Release 12.0(23)SX

The ppp multilink fragmentation command was introduced on the PRE1.

Release 12.2(16)BX

This command was introduced on the PRE2.

Release 12.2

The no ppp multilink fragmentation command was changed to ppp multilink fragment disable. The no ppp multilink fragmentation command is recognized and accepted through Cisco IOS Release 12.2.

Release 12.2(28)SB

This command was integrated in Cisco IOS Release 12.2(28)SB for the PRE2.

Release 12.2(31)SB2

This command was introduced on the PRE3.


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 disable
 
   
no ppp multilink fragment disable

ppp multilink fragment disable Command History

Cisco IOS Release
Description

Release 11.3

This command was introduced as ppp multilink fragmentation.

Release 12.2

The no ppp multilink fragmentation command was changed to ppp multilink fragment disable. The no ppp multilink fragmentation command was recognized and accepted through Cisco IOS Release 12.2.

Release 12.2(28)SB

This command was integrated in Cisco IOS Release 12.2(28)SB for the PRE2.

Release 12.2(31)SB2

This command was introduced on the PRE3.


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 delay
Router(config-if)# no ppp multilink interleave
Router(config-if)# ppp multilink fragment disable

ppp 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-number
 
   
no ppp multilink group group-number

Syntax Description

group-number

Identifies the multilink group. This number must be identical to the multilink-bundle-number you assigned to the multilink interface. Valid values are:

MLP over Serial-based LFI

1 to 9999 (Cisco IOS Release 12.2(28)SB and later releases)

1 to 9999 and 65,536 to 2,147,483,647 (Cisco IOS Release 12.2(31)SB2 and later releases)

Single-VC MLP over ATM-based LFI

10,000 and higher

Multi-VC MLP over ATM-based LFI

1 to 9999 (Cisco IOS Release 12.2(28)SB and later releases)

1 to 9999 and 65,536 to 2,147,483,647 (Cisco IOS Release 12.2(31)SB2 and later releases)

MLP over Frame Relay-based LFI

10,000 and higher


ppp multilink group Command History

Cisco IOS Release
Description

Release 12.0

The ppp multilink group command was introduced on the PRE1 as multilink-group command.

Release 12.2

The multilink-group command was changed on the PRE2 to ppp multilink group. The multilink-group command was accepted by the command line interpreter through Cisco IOS Release 12.2.

Release 12.2(28)SB

This command was integrated in Cisco IOS Release 12.2(28)SB for the PRE2.

Release 12.2(31)SB2

This command was introduced on the PRE3.


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

MLP Over Serial-Based LFI

Single-VC MLP Over ATM-Based LFI

Multi-VC MLP Over ATM-Based LFI

MLP Over Frame Relay-Based LFI

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

Cisco IOS Release
Description
Required PRE

Release 12.0(23)SX

The MLP over serial-based LFI feature was introduced on the PRE1.

PRE1

Release 12.2(27)SBB

This feature was introduced on the PRE2.

PRE2

Release 12.2(31)SB2

This feature was introduced on the PRE3 and the valid multilink interface values changed from 1 to 9999 (Release 12.2(28)SB and later) to from 1 to 9999 and 65,536 to 2,147,483,647.

PRE3


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 in
 
   

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 MLP Over Serial-Based LFI

A multilink bundle can have up to 10 member links. The router supports subrate T1 interfaces as member links. The link speeds must be the same for all of the links in the bundle.

The router supports a maximum of 1250 bundles per system and a maximum of 2500 member links per system.

The valid multilink interface values are from 1 to 9999 (Release 12.2(28)SB and later), or from 1 to 9999 and 65,536 to 2,147,483,647 (Release 12.2(31)SB2 and later). For example:

Router(config)# interface multilink 8
 
   

Interleaving is supported on one member link. MLP over Serial-based LFI must be enabled on an interface that has interleaving turned on.

All member links in a MLP bundle must have the same encapsulation type and bandwidth. Performance is not guaranteed when member links have different bandwidths.

We strongly recommend that you use only strict priority queues when configuring MLP over Serial-based LFI. For more information, see Chapter 8 "Prioritizing Services."

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:

24-port Channelized T1/E1

6-port Channelized T3

4-port Channelized OC-3/STM-1

1-port Channelized OC-12/STM-4

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:

Delay-Sensitive, Real-Time Packets—On transmit, MLP encapsulates the packets as PPP over ATM (PPPoA) and sends the packets to a special 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.

Delay-Insensitive, Nonreal-Time Packets—On transmit, 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 transmit queue to enable the router to transmit the fragments at the same time over multiple point-to-point links to the same remote address. The receiving fragmentation peer reassembles the fragments to the original packet and then processes it as Point-to-Point Protocol over ATM (PPPoA). The underlying PPP encapsulation conforms to RFC 1661. All outbound MLP packets with a payload larger than the specified fragment size are fragmented. The minimum fragment size depends on the AAL5 encapsulation type and whether or not protocol compression is enabled (see Table 16-2).

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

Cisco IOS Release
Description
Required PRE

Release 12.2(27)SBB

The single-VC MLP over ATM-based LFI feature was introduced on the router for the PRE2.

PRE2

Release 12.2(31)SB2

This feature was introduced on the PRE3.

PRE3


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.

Table 16-2 ATM Minimum Fragment Size

AAL5 Encapsulation Type
Protocol Compression
Minimum Fragment Size

AAL5 MUX

OFF

82 Bytes

AAL5 SNAP

OFF

78 Bytes

AAL5 Cisco

OFF

80 Bytes

AAL5 MUX

ON

83 Bytes

AAL5 SNAP

ON

79 Bytes

AAL5 Cisco

ON

81 Bytes


To calculate the fragment size, do the following:


Step 1 Calculate the nominal fragment size (link weight) by using the following formula:

(Link Bandwidth * Fragment-Delay) / 8
 
   

Step 2 Determine the number of whole ATM cells the nominal fragment size represents.

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 Calculate the total bytes per fragment, including the MLP header bytes and AAL5 trailer bytes, by multiplying the number of ATM cells you calculated in Step 2 by 48:

Number of Cells * 48
 
   

Step 4 Subtract the MLP header bytes and AAL5 trailer bytes.

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.

Table 16-3 MLP Header Bytes and AAL5 Trailer Bytes

AAL5 Encapsulation
Type
Protocol Compression
No. of MLP Header
Bytes
No. of AAL5 Trailer
Bytes

AAL5 MUX

OFF

6 Bytes

8 Bytes

AAL5 SNAP

OFF

10 Bytes

8 Bytes

AAL5 Cisco

OFF

8 Bytes

8 Bytes

AAL5 MUX

ON

5 Bytes

8 Bytes

AAL5 SNAP

ON

9 Bytes

8 Bytes

AAL5 Cisco

ON

7 Bytes

8 Bytes


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:

Fragments nonreal-time traffic

Encapsulates the fragments with MLP

Transmits the fragments

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:

Configure the following commands and recommended values on the virtual template interface:

ppp max-configure 110

ppp max-failure 100

ppp timeout retry 5

keepalive 30

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 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

Single-VC MLP over ATM member links are restricted to non-aggregated PVCs (for example, variable bit rate-nonreal-time (VBR-nrt) and constant bit rate (CBR) ATM traffic classes only).

The multilink interface can have only one PPP link that is between 64 and 2048 kbps. The router supports a maximum of one member link per bundle.

The router supports a maximum of 8192 bundles per system and a maximum of 8192 member links per system.

The valid multilink interface values are 10,000 and higher.

Interleaving occurs on one member link.

MLP VCs cannot be on-demand VCs that are automatically provisioned.

Associating MLP over ATM VCs with ATM virtual paths (VPs) is discouraged, though not prevented.

Cisco IOS software supports a maximum of 4096 total virtual template interfaces.

We strongly recommend that you use only strict priority queues when configuring MLP over ATM-based LFI. For more information, see Chapter 8 "Prioritizing Services."

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:

8-Port E3/DS3 ATM

4-Port OC-3/STM-1 ATM

1-Port OC-12 ATM

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

Cisco IOS Release
Description
Required PRE

Release 12.2(27)SBB

The Multi-VC MLP over ATM-based LFI feature was introduced on the router for the PRE2.

PRE2

Release 12.2(31)SB2

This feature was introduced on the PRE3 and the valid multilink interface values changed from 1 to 9999 (Release 12.2(28)SB and later) to from 1 to 9999 and 65,536 to 2,147,483,647.

PRE3


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:

Configure the following commands and recommended values on the virtual template interface:

ppp max-configure 110

ppp max-failure 100

ppp timeout retry 5

keepalive 30

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 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

Multi-VC MLP over ATM member links are restricted to non-aggregated PVCs (for example, variable bit rate-nonreal-time (VBR-nrt) and constant bit rate (CBR) ATM traffic classes only).

Each MLP over ATM member link can be up to 2048 kbps.

The router supports a maximum of 10 member links (ATM PVCs) per bundle.

The router supports a maximum of 1250 bundles per system and a maximum of 2500 member links per system.

For Cisco IOS Release 12.2(28)SB and later releases, the valid multilink interface values are from 1 to 9999. For Cisco IOS Release 12.2(31)SB2 and later releases, valid values are from 1 to 9999 and 65,536 to 2,147,483,647.

All member links in a MLP bundle must have the same encapsulation type and bandwidth. Performance is not guaranteed when member links have different bandwidths.

Interleaving occurs on one member link.

MLP VCs cannot be on-demand VCs that are automatically provisioned.

Associating MLP over ATM VCs with ATM virtual paths (VPs) is discouraged, though not prevented.

Cisco IOS software supports a maximum of 4096 total virtual template interfaces.

We strongly recommend that you use only strict priority queues when configuring Multi-VC MLP over ATM-based LFI. For more information, see Chapter 8 "Prioritizing Services."

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:

8-Port E3/DS3 ATM

4-Port OC-3/STM-1 ATM

1-Port OC-12 ATM

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

Cisco IOS Release
Description
Required PRE

Release 12.2(27)SBB

The MLP over Frame Relay-based LFI feature was introduced on the router for the PRE2.

PRE2

Release 12.2(31)SB2

This feature was introduced on the PRE3.

PRE3


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:

Fragments nonreal-time traffic

Encapsulates the fragments with MLP

Transmits the fragments

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 Calculate the nominal fragment size (link weight) by using the following formula:

(Link Bandwidth * Fragment-Delay) / 8
 
   

Step 2 Subtract the Frame Relay encapsulation bytes and the MLP header bytes by using the following formula:

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 If PPP protocol compression is on, subtract 1 byte.

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 Size
 
   

where:

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:

Configure the following commands and recommended values on the virtual template interface:

ppp max-configure 110

ppp max-failure 100

ppp timeout retry 5

keepalive 30

Configure the hold-queue command in interface configuration mode for all Frame Relay physical interfaces.

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

The router supports a maximum of one member link per bundle. The member link can be up to 2048 kbps.

The router supports a maximum of 2048 bundles per system and a maximum of 2048 member links per system.

The valid multilink interface values are 10,000 and higher.

Interleaving occurs on only one member link.

Interface fragmentation and Frame Relay traffic shaping cannot be configured at the same time on an interface. Do not configure the frame-relay traffic-shaping command on an interface with Frame Relay interface fragmentation configured.

The frame-relay fair-dlci queuing command cannot be configured on an interface with Frame Relay interface fragmentation configured. To specify QoS on LFI-enabled interfaces, use service policies (see Chapter 13 "Defining QoS for Multiple Policy Levels").

Local Management Interface (LMI) traffic is not fragmented.

Cisco IOS software supports a maximum of 4096 total virtual template interfaces.

We strongly recommend that you use only strict priority queues when configuring MLP over Frame Relay-based LFI. For more information, see Chapter 8 "Prioritizing Services."

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

LFI Type
MLP Bundle
Member Links
Virtual Template
Service Policy

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

Enabling MLP on a Virtual Template Interface

Configuring a Shaping Policy for MLP Over Frame Relay-Based LFI

Configuring a Shaping Policy for MLP Over Frame Relay-Based LFI

Adding an ATM Member Link to a MLP Bundle

Adding a Frame Relay Member Link to a MLP Bundle

Creating a MLP Bundle Interface

To create a MLP bundle interface, enter the following commands beginning in global configuration mode:

 
Command
Purpose

Step 1 

Router(config)# interface multilink multilink-bundle-number

Creates a multilink bundle. Enters interface configuration mode to configure the bundle.

multilink-bundle-number is a nonzero number that identifies the multilink bundle. For Cisco IOS Release 12.2(28)SB and later releases, valid values are:

MLP over Serial-based LFI

1 to 9999 (Cisco IOS Release 12.2(28)SB and later releases)

1 to 9999 and 65,536 to 2,147,483,647 (Cisco IOS Release 12.2(31)SB2 and later releases)

Single-VC MLP over ATM-based LFI

10,000 and higher

Multi-VC MLP over ATM-based LFI

1 to 9999 (Cisco IOS Release 12.2(28)SB and later releases)

1 to 9999 and 65,536 to 2,147,483,647 (Cisco IOS Release 12.2(31)SB2 and later releases)

MLP over Frame Relay-based LFI

10,000 and higher

Note For releases prior to Cisco IOS Release 12.2(28)SB, valid values are from 1 to 2,147,483,647.

Step 2 

Router(config-if)# ip address address mask

Specifies the IP address and subnet mask assigned to the interface.

address is the IP address.

mask is the subnet mask for the associated IP address.

Step 3 

Router(config-if)# ppp chap hostname hostname

Identifies the hostname sent in the Challenge Handshake Authentication Protocol (CHAP) challenge.

hostname is the name of the bundle group. This is the unique identifier that identifies the bundle.

Note If more than one bundle transmits packets to a peer system, use this command to distinguish the bundle. If you configure this command on the bundle and its member links, specify the same identifier for both the bundle and the member links.

Step 4 

Router(config-if)# service-policy {input | output} policy-map-name

Attaches the policy map you specify to the multilink interface.

input indicates to apply the service policy to the traffic on the inbound interface.

output indicates to apply the service policy to the traffic on the outbound interface.

Note For QoS policies containing the bandwidth, priority, random-detect, queue-limit, and shape commands, you must specify the output keyword. The router ignores these commands when you use them with the input keyword.

policy-map-name is the name of the policy map.

Step 5 

Router(config-if)# ppp multilink

Enables MLP on the interface.

Note MLP fragmentation is enabled by default.

Step 6 

Router(config-if)# ppp multilink fragment-delay delay-max

Configures the maximum delay allowed for the transmission of a packet fragment on an MLP bundle.

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.

Step 7 

Router(config-if)# ppp multilink interleave

Enables interleaving of real-time packets among the fragments of larger nonreal-time packets on a MLP bundle.

Step 8 

Router(config-if)# ppp multilink group group-number

Restricts a physical link to joining only a designated multilink group interface.

group-number is a nonzero number that identifies the multilink group. The number you specify must be identical to the multilink-bundle-number you specified in Step 1.

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 8
Router(config-if)# ip address 172.16.48.209 255.255.0.0
Router(config-if)# ppp chap hostname cambridge
Router(config-if)# service-policy output bronze
Router(config-if)# ppp multilink
Router(config-if)# ppp multilink fragment-delay 50
Router(config-if)# ppp multilink interleave
Router(config-if)# ppp multilink group 8
Router(config-if)# exit

Enabling 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:

 
Command
Purpose

Step 1 

Router(config)# interface virtual-template number

Creates or modifies a virtual template interface that can be configured and applied dynamically to virtual access interfaces. Enters interface configuration mode.

number is a number that identifies the virtual template interface. You can configure up to 5061 total virtual template interfaces (requires Cisco IOS Release 12.2(28)SB and later releases).

Step 2 

Router(config-if)# ppp max-configure retries

Specifies the maximum number of configure requests to attempt before stopping the requests due to no response.

retries specifies the maximum number of retries. Valid values are from 1 to 255. The default is 10 retries. We recommend 110 retries.

Step 3 

Router(config-if)# ppp max-failure retries

Configures the maximum number of consecutive Configure Negative Acknowledgements (CONFNAKs) to permit before terminating a negotiation.

retries is the maximum number of retries. Valid values are from 1 to 255. The default is 5 retries. We recommend 100 retries.

Step 4 

Router(config-if)# ppp timeout retry response-time

Sets the maximum time to wait for Point-to-Point Protocol (PPP) negotiation messages.

response-time specifies the maximum time, in seconds, to wait for a response during PPP negotiation. We recommend 5 seconds.

Step 5 

Router(config-if)# keepalive [period]

Enables keepalive packets to be sent at the specified time interval to keep the interface active.

period specifies a time interval, in seconds. The default is 10 seconds. We recommend 30 seconds.

Step 6 

Router(config-if)# no ip address

Removes an IP address.

Step 7 

Router(config-if)# ppp multilink

Enables MLP on the virtual template interface.

Step 8 

Router(config-if)# ppp multilink group group-number

(MLP over FR only) Associates the interface with a MLP bundle. Use this command only for MLP over Frame-Relay-based LFI.

group-number is a nonzero number that identifies the multilink group. Valid values are from 10,000 and higher.

The group-number must be identical to the specified multilink-bundle-number of the MLP bundle to which you want to add this link.

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-template1
Router(config-if)# ppp max-configure 110
Router(config-if)# ppp max-failure 100
Router(config-if)# ppp timeout retry 5
Router(config-if)# keepalive 30
Router(config-if)# no ip address
Router(config-if)# ip mroute-cache
Router(config-if)# ppp authentication chap
Router(config-if)# ppp multilink
Router(config-if)# exit

Configuring 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:

 
Command
Purpose

Step 1 

Router(config)# policy-map policy-map-name

Configures the QoS policy. Enters policy-map configuration mode.

policy-map-name is the name of the policy map.

Step 2 

Router(config-pmap)# class class-default

Configures the class-default class. Enters policy-map class configuration mode.

Step 3 

Router(config-pmap-c)# shape kbps-value

Shapes traffic to a specified bit rate.

kbps-value is the bit rate (in kilobits per second) used to shape the traffic.

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:

 
Command
Purpose

Step 1 

Router(config-if)# interface serial slot/module/port.channel:controller-number

Specifies the interface that you want to add to the MLP bundle. Enters interface configuration mode.

slot/module/port identifies the line card. The slashes are required.

channel: is the channel group number. The colon is required.

controller-number is the member link controller number.

Step 2 

Router(config-if)# hold-queue length {in | out}

Limits the size of the IP output queue on an interface. We recommend that you configure this command on all physical interfaces.

length is a number that specifies the maximum number of packets in the queue. Valid values are from 0 to 4096. We recommend 4096 packets for all line cards. By default, the input queue is 75 packets and the output queue is 40 packets.

in specifies the input queue.

out specifies the output queue.

Step 3 

Router(config-if)# ppp chap hostname hostname

(Optional) Identifies the hostname sent in the Challenge Handshake Authentication Protocol (CHAP) challenge.

hostname is the name of the bundle group. This is the unique identifier that identifies the bundle.

Note If you configure this command on the bundle and its member links, specify the same identifier for both the bundle and the member links.

Step 4 

Router(config-if)# encapsulation ppp

Specifies Point-to-Point Protocol (PPP) encapsulation for the interface.

Step 5 

Router(config-if)# no ip address

Removes any existing IP address from the main interface.

Step 6 

Router(config-if)# ppp multilink

Enables MLP on the interface.

Step 7 

Router(config-if)# ppp multilink group group-number

Associates the interface with a MLP bundle.

group-number is a nonzero number that identifies the multilink group. Valid values are from 1 to 9999 (Cisco IOS Release 12.2(28)SB and later releases) or from 1 to 9999 and 65,536 to 2,147,483,647 (Cisco IOS Release 12.2(31)SB2 and later releases).

The group-number must be identical to the specified multilink-bundle-number of the MLP bundle to which you want to add this link.

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:

 
Command
Purpose

Step 1 

Router(config-if)# interface atm slot/module/port

Configures or modifies the ATM interface you specify and enters interface configuration mode.

Step 2 

Router(config-if)# hold-queue length {in | out}

Limits the size of the IP output queue on an interface. We recommend that you configure this command on all physical interfaces, except when using the OC-12 ATM line card.

length is a number that specifies the maximum number of packets in the queue. Valid values are from 0 to 4096. We recommend 4096 packets for all line cards, except the ATM OC-12 line card. By default, the input queue is 75 packets and the output queue is 40 packets.

in specifies the input queue.

out specifies the output queue.

Step 3 

Router(config-if)# interface atm slot/module/port.subinterface point-to-point

Creates or modifies a point-to-point subinterface. Enters subinterface configuration mode.

Step 4 

Router(config-subif)# ppp chap hostname hostname

(Optional) Identifies the hostname sent in the Challenge Handshake Authentication Protocol (CHAP) challenge.

hostname is the name of the bundle group. This is the unique identifier that identifies the bundle.

Note If you configure this command on the bundle and its member links, specify the same identifier for both the bundle and the member links.

Step 5 

Router(config-subif)# no ip address

Removes any existing IP address from the main interface.

Step 6 

Router(config-subif)# pvc [name] vpi/vci

Creates or modifies an ATM PVC. Enters ATM VC configuration mode.

name is the name of the ATM PVC.

vpi/ is the virtual path identifier. If you do not specify a VPI value and the slash character (/), the VPI value defaults to 0.

vci is the virtual channel identifier.

Step 7 

Router(config-if-atm-vc)# vbr-nrt output-pcr output-scr output-mbs

Configures the variable bit rate-nonreal time (VBR-nrt) quality of service (QoS).

output-pcr is the output peak cell rate (PCR), in kbps.

output-scr is the sustainable cell rate (SCR), in kbps.

output-mbs is the output maximum burst cell size (MBS), expressed in number of cells.

Step 8 

Router(config-if-atm-vc)# encapsulation {aal5mux ppp virtual-template number | aal5ciscoppp virtual-template number | aal5snap}

Configures the ATM adaptation layer (AAL) and encapsulation type for an ATM virtual circuit (VC).

aal5mux ppp specifies the AAL and encapsulation type for multiplex (MUX)-type VCs. The keyword ppp is Internet Engineering Task Force (IETF)-compliant PPP over ATM. It specifies the protocol type being used by the MUX encapsulated VC. Use this protocol type for Multi-VC MLP over ATM-based LFI to identify the virtual template. This protocol is supported on ATM PVCs only.

aal5ciscoppp specifies the AAL and encapsulation type for Cisco PPP over ATM. Supported on ATM PVCs only.

aal5snap specifies the AAL and encapsulation type that supports Inverse ARP. Logical Link Control/Subnetwork Access Protocol (LLC/SNAP) precedes the protocol datagram.

virtual-template number is the number used to identify the virtual template.

Step 9 

Router(config-if-atm-vc)# protocol ppp virtual-template number

Enables PPP sessions to be established over the ATM PVC using the configuration from the virtual template you specify. Use this command only if you specified aal5snap as the encapsulation type in Step 11 and you are configuring multiple VCs for LFI with MLP.

number is a nonzero number that identifies the virtual template that you want to apply to this ATM PVC.

Step 10 

Router(config-if-atm-vc)# ppp multilink group group-number

Associates the PVC with a MLP bundle.

group-number is a nonzero number that identifies the multilink group. Valid values are:

Single-VC MLP over ATM-based LFI

10,000 and higher

Multi-VC MLP over ATM-based LFI

1 to 9999 (Cisco IOS Release 12.2(28)SB and later releases)

1 to 9999 and 65,536 to 2,147,483,647 (Cisco IOS Release 12.2(31)SB2 and later releases)

The group-number must be identical to the specified multilink-bundle-number of the MLP bundle to which you want to add this link.

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 Bronze
Router(config-cmap)# match access-group 100
!
Router(config-pmap)# policy-map Business
Router(config-pmap)# class Bronze
Router(config-pmap-c)# priority
Router(config-pmap-c)# police 48
!
Router(config)# interface Multilink 10000
Router(config-if)# ip address 10.6.6.1 255.255.255.0
Router(config-if)# service-policy output Premium
Router(config-if)# ppp multilink
Router(config-if)# ppp multilink fragment-delay 8
Router(config-if)# ppp multilink interleave
Router(config-if)# ppp multilink group 10000
Router(config-if)# exit
Router(config)# interface virtual-template1
Router(config-if)# ppp max-configure 110
Router(config-if)# ppp max-failure 100
Router(config-if)# ppp timeout retry 5
Router(config-if)# keepalive 30
Router(config-if)# no ip address
Router(config-if)# ppp multilink
Router(config-if)# exit
Router(config)# interface atm 4/0/0
Router(config-if)# hold-queue 4096 in
Router(config-if)# interface atm 4/0/0.1 point-to-point
Router(config-subif)# pvc 1/33
Router(config-if-atm-vc)# vbr-nrt 128 128 1
Router(config-if-atm-vc)# encapsulation aal5snap
Router(config-if-atm-vc)# protocol ppp virtual-template1
Router(config-if-atm-vc)# ppp multilink group 10000

Adding 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:

 
Command
Purpose

Step 1 

Router(config-if)# interface serial slot/module/port

Configures or modifies the interface you specify and enters interface configuration mode.

Step 2 

Router(config-if)# hold-queue length {in | out}

Limits the size of the IP output queue on an interface. We recommend that you configure this command on all physical interfaces.

length is a number that specifies the maximum number of packets in the queue. Valid values are from 0 to 4096. We recommend 4096 packets for all line cards. By default, the input queue is 75 packets and the output queue is 40 packets.

in specifies the input queue.

out specifies the output queue.

Step 3 

Router(config-if)# ppp chap hostname hostname

(Optional) Identifies the hostname sent in the Challenge Handshake Authentication Protocol (CHAP) challenge.

hostname is the name of the bundle group. This is the unique identifier that identifies the bundle.

Note If more than one bundle transmits packets to a peer system, use this command to distinguish the bundle. If you configure this command on the bundle and its member links, specify the same identifier for both the bundle and the member links.

Step 4 

Router(config-if)# encapsulation frame-relay [ietf | cisco]

Specifies Frame Relay as the interface encapsulation type.

(Optional) ietf sets the encapsulation method to comply with the Internet Engineering Task Force (IETF) standard (RFC 1490). Use this keyword when connecting to another vendor's equipment across a Frame Relay network.

(Optional) cisco indicates to use Cisco's own encapsulation, which is a 4-byte header, with 2 bytes to identify the data-link connection identifier (DLCI) and 2 bytes to identify the packet type. This is the default encapsulation type.

Step 5 

Router(config-if)# interface serial slot/module/port.subinterface point-to-point

Configures or modifies the subinterface you specify. Enters subinterface configuration mode.

Step 6 

Router(config-subif)# frame-relay interface-dlci dlci ppp virtual-template-name

Assigns a data-link connection identifier (DLCI) to the Frame Relay subinterface and applies a virtual template configuration for a PPP session.

dlci is a number that identifies the connection. This number is specific to the local subinterface.

ppp enables the circuit to use PPP in Frame Relay encapsulation.

virtual-template-name specifies which virtual template interface to apply the PPP connection to.

Step 7 

Router(config-subif)# service-policy {input | 
output} policy-map-name

Applies the service policy you specify to the subinterface.

input indicates to apply the service policy to the traffic on the inbound interface.

output indicates to apply the service policy to the traffic on the outbound interface.

Note For QoS policies containing the bandwidth, priority, random-detect, queue-limit, and shape commands, you must specify the output keyword. The router ignores these commands when you use them with the input keyword.

policy-map-name is the name of the policy map.

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 switching
 
   
class-map match-all voip
  match ip rtp 16384 1000
 
   
policy-map voip
  class voip
 	priority
    police 24000 1000 0 conform-action transmit exceed-action drop violate-action drop
 
   
policy-map shape
  class class-default
    shape 100
 
   
interface Multilink20009
 ip address 10.1.2.2 255.255.255.0
 ppp multilink
 ppp multilink fragment disable
 ppp multilink fragment delay 8
 ppp multilink interleave
 ppp multilink group 20009
 service-policy output voip
 
   
interface serial 3/0/1
 no ip address
 encapsulation frame-relay
 no keepalive
!
interface serial 3/0/1.1 point-to-point
 no keepalive
 frame-relay interface-dlci 18 ppp Virtual-Template209
 service-policy output shape
!
 
   
interface Virtual-Template209
 description mlp_lfi_c10k
 no ip address
 ppp chap hostname lfiofr-20009
 ppp multilink
 ppp 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:

 
Command
Purpose

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 If more than one bundle transmits packets to a peer system, use this command to distinguish the bundle. If you configure this command on the bundle and its member links, specify the same identifier for both the bundle and the member links.

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:

MLP over Serial-based LFI

1 to 9999 (Cisco IOS Release 12.2(28)SB and later releases)

1 to 9999 and 65,536 to 2,147,483,647 (Cisco IOS Release 12.2(31)SB2 and later releases)

Single-VC MLP over ATM-based LFI

10,000 and higher

Multi-VC MLP over ATM-based LFI

1 to 9999 (Cisco IOS Release 12.2(28)SB and later releases)

1 to 9999 and 65,536 to 2,147,483,647 (Cisco IOS Release 12.2(31)SB2 and later releases)

MLP over Frame-Relay-based LFI

10,000 and higher

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:

 
Command
Purpose

Step 1 

Router(config)# interface type number slot/module/port.channel:controller-number

Specifies the member link that you want to remove from the MLP bundle. Enters interface configuration mode.

Step 2 

Router(config-if)# no ppp multilink group group-number

Removes the member link from the MLP group.

group-number identifies the multilink group.

Step 3 

Router(config-if)# no ppp multilink

Disables Multilink PPP for the link.

Step 4 

Router(config-if)# no ppp chap hostname

Removes PPP authentication.

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:

Nonreal-Time Transmit—The transmitting LFI-enabled data terminal equipment (DTE) fragments large nonreal-time packets into smaller frames and encapsulates the frames as FRF.12 end-to-end packets.

Real-Time Transmit—The DTE encapsulates real-time packets as Frame Relay packets and interleaves the real-time packets between the nonreal-time fragments.

Nonreal-Time Receive—The receiving LFI-enabled DTE reassembles the nonreal-time fragments and processes the reassembled packets as Frame Relay packets.

Real-Time Receive—Because real-time packets are whole packets and not fragments, reassembly is not required. Instead, the receiving DTE simply processes and forwards the Frame Relay 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

Cisco IOS Release
Description
Required PRE

Release 12.0(23)SX

The PVC-based FRF.12 Fragmentation feature was introduced on the router.

PRE1

Release 12.0(27)S

This feature was enhanced to allow interface-based FRF.12 fragmentation.

PRE1

Release 12.2(27)SBB

This feature was introduced on the PRE2 to allow PVC-based and interface-based FRF.12 fragmentation only.

PRE2

Release 12.2(31)SB2

This feature was introduced on the PRE3.

PRE3


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.1
 no frame-relay class mfr
 no service-policy out mfr1
 int mfr2001.1
 service-policy out mfr1

frame-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.1
 no service-policy out mfr1
 int mfr2001.1
 service-policy out mfr1

Example 16-7 Remove the Service Policy Before Removing the Map-Class.

int mfr2001.1
 no service-policy out mfr1
 no frame-relay class mfr
 int mfr2001.1
 frame-relay class mfr
 service-policy out mfr1

FRF.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

LFI Enabled
Traffic Subject to LFI

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:

Directly using the service-policy command

Using a Frame Relay map class

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_q2
Router(config-cmap)# match ip precedence 2
Router(config-cmap)# class-map match-all prec_q0
Router(config-cmap)# match ip precedence 0
Router(config-cmap)# class-map match-all prec_q1
Router(config-cmap)# match ip precedence 1
!
Router(config)# policy-map policy_12_p0
Router(config-pmap)# class prec_q0
Router(config-pmap-c)# priority
Router(config-pmap-c)# police 64000
Router(config-pmap-c)# class prec_q1
Router(config-pmap-c)# bandwidth percent 39
Router(config-pmap-c)# class prec_q2
Router(config-pmap-c)# bandwidth percent 4
!
Router(config)# policy-map policy_13
Router(config-pmap)# class class-default
Router(config-pmap-c)# shape 256
Router(config-pmap-c)# service-policy policy_12_p0
 
   

For 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)

frame-relay fragment end-to-end Command (Interface)

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_size
 
   
no frame-relay fragment fragment_size

Syntax Description

fragment_size

Specifies the number of payload bytes from the original Frame Relay frame that go into each fragment. This number excludes the Frame Relay header of the original frame. Valid values are from 16 to 1600 bytes. However, the minimum supported fragment size is 44 bytes. The default is 53 bytes.


frame-relay fragment Command History

Cisco IOS Release
Description

Release 12.0(23)SX

The frame-relay fragment command was introduced on the PRE1.

Release 12.2(27)SBB

This command was introduced on the PRE2.

Release 12.2(31)SB2

This command was introduced on the PRE3.


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-end
 
   
no frame-relay fragment fragment_size end-to-end

Syntax Description

fragment_size

Specifies the number of payload bytes from the original Frame Relay frame that go into each fragment. This number excludes the Frame Relay header of the original frame. Valid values are from 16 to 1600 bytes. There is no default fragment size.

Note You must specify the fragment_size. If you do not, an error message displays.


frame-relay fragment end-to-end Command History

Cisco IOS Release
Description

Release 12.0(27)S

The frame-relay fragment end-to-end command was introduced on the PRE1.

Release 12.2(27)SBB

This command was introduced on the PRE2.

Release 12.2(31)SB2

This command was introduced on the PRE3.


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 in

Prerequisites for FRF.12 Fragmentation

A hierarchical service policy must be configured and applied to a Frame Relay interface, subinterface, or DLCI either directly using the service-policy command or using a map class. For more information, see the "FRF.12 Fragmentation and Hierarchical Policies" section.

The router must be running Cisco IOS Release 12.0(27)S or Release 12.2(27)SBB, or later releases, and the appropriate processor card must be installed in the router chassis. Cisco IOS Release 12.0(27)S and later releases require the PRE1 processor card. Cisco IOS Release 12.2SBB and later releases require the PRE2.

Frame Relay traffic shaping must be disabled on the interface for PVC-based and interface-based fragmentation.


Note The PRE2 does not support Frame Relay traffic shaping. However, for FRF.12 to function properly, a service policy that shapes traffic is required.


Priority queuing (PQ) must be configured on the interface.


Note The Cisco 10000 series router does not require that you configure priority (low-latency) queuing to use interface-based fragmentation. However, the purpose of LFI is to reduce delay for priority traffic; therefore, the benefit of LFI is realized when you do configure priority queuing. The class of delay-sensitive traffic is mapped through a service policy to the priority queue.


Restrictions and Limitations for FRF.12 Fragmentation

PVC-Based Fragmentation

Fragmentation is performed after frames are removed from the bundle.

The frame-relay route command does not support fragmentation.

The show frame-relay fragment command does not provide information about the number of fragments received, dropped, and transmitted.

The show frame-relay fragment interface command does not provide information about the number of:

Fragmented packets and bytes received

Packets dropped while being reassembled

Received packets in timeouts

Interleaved packets transmitted

Fragmented packets and bytes transmitted

Fragmented packets dropped when transmitted

We strongly recommend that you use only strict priority queues when configuring PVC-based FRF.12 fragmentation. For more information, see Chapter 8 "Prioritizing Services."

Interface-Based Fragmentation

PVC-based and interface-based fragmentation cannot be configured at the same time.

The rate of the interface or subinterface must be between 64 and 2048 kbps.

Interface fragmentation and Frame Relay traffic shaping cannot be configured at the same time on an interface. Do not configure the frame-relay traffic-shaping command on an interface with Frame Relay interface fragmentation configured.

The frame-relay fair-dlci queuing command cannot be configured on an interface with Frame Relay interface fragmentation configured. To specify QoS on FRF.12-enabled interfaces, use service policies (see Chapter 13 "Defining QoS for Multiple Policy Levels.").

Local Management Interface (LMI) traffic is not fragmented.

We strongly recommend that you use only strict priority queues when configuring interface-based FRF.12 fragmentation. For more information, see Chapter 8 "Prioritizing Services."

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

Attaching the Map Class

Configuring a Hierarchical Policy and PVC-Based FRF.12 Fragmentation

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:

 
Command
Purpose

Step 1 

Router(config)# map-class frame-relay map-class-name

Creates or modifies a map class and enters map-class configuration mode.

map-class-name identifies the map class.

Step 2 

Router(config-map-c)# frame-relay fragment fragment_size

Enables the fragmentation of Frame Relay frames on a Frame Relay map class.

fragment_size specifies the number of payload bytes from the original Frame Relay frame that go into each fragment. This number excludes the Frame Relay header of the original frame. Valid values are from 16 to 1600 bytes. The default is 53 bytes.

Note All of the fragments of a Frame Relay frame, except the last, 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.

Step 3 

Router(config-map-c)# service-policy 
{input | output} policy-map-name

Applies the service policy you specify to the map class.

input indicates to apply the service policy to the traffic on the inbound interface.

output indicates to apply the service policy to the traffic on the outbound interface.

Note For QoS policies containing the bandwidth, priority, random-detect, queue-limit, and shape commands, you must specify the output keyword. The router ignores these commands when you use them with the input keyword.

policy-map-name is the name of the policy map.

Step 4 

Router(config-map-c)# no frame-relay 
adaptive-shaping

Disables Frame Relay adaptive traffic shaping.

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

Attaching a Map Class to a Frame Relay DLCI

Attaching a Map Class to a Frame Relay Interface and a Service Policy to a Subinterface

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:

 
Command
Purpose

Step 1 

Router(config)# interface serial slot/module/port.T1#:channel

Creates or modifies a serial interface. Enters interface configuration mode.

Step 2 

Router(config-if)# hold-queue length {in | out}

Limits the size of the IP output queue on an interface. We recommend that you configure this command on all physical interfaces.

length is a number that specifies the maximum number of packets in the queue. Valid values are from 0 to 4096. We recommend 4096 packets for all line cards, except the ATM OC-12 line card. By default, the input queue is 75 packets and the output queue is 40 packets.

in specifies the input queue.

out specifies the output queue.

Step 3 

Router(config-if)# no ip address

Removes any existing IP address from the main interface.

Step 4 

Router(config-if)# no ip directed-broadcast

Disables the translation of a directed broadcast to physical broadcasts. Instead, the directed broadcasts are dropped.

Step 5 

Router(config-if)# encapsulation frame-relay [ietf | cisco]

Specifies Frame Relay as the interface encapsulation type.

(Optional) ietf sets the encapsulation method to comply with the Internet Engineering Task Force (IETF) standard (RFC 1490). Use this keyword when connecting to another vendor's equipment across a Frame Relay network.

(Optional) cisco indicates to use Cisco's own encapsulation, which is a 4-byte header, with 2 bytes to identify the data-link connection identifier (DLCI) and 2 bytes to identify the packet type. This is the default encapsulation type.

Step 6 

Router(config-if)# frame-relay class name

Associates a map class with the Frame Relay interface.

name is the name of the map class.

Note The router applies the service policy configured in the map class to this main interface, any subinterfaces configured on the main interface, and any DLCIs configured on the subinterfaces.

Step 7 

Router(config-if)# interface serial slot/module/port.T1#:channel.subinterface- number [point-to-point]

Creates or modifies a serial subinterface. Enters subinterface configuration mode.

The point-to-point subinterface is used to establish a PVC connection to an interface on the remote end of the Frame Relay connection.

Step 8 

Router(config-subif)# ip address address mask

Specifies the IP address and subnet mask assigned to the subinterface.

address is the IP address.

mask is the subnet mask for the associated IP address.

Step 9 

Router(config-subif)# no ip directed-broadcast

Disables the translation of a directed broadcast to physical broadcasts. Instead, the directed broadcasts are dropped.

Step 10 

Router(config-subif)# frame-relay class name

Associates a map class with the subinterface.

name is the name of the map class.

Note The router applies the service policy configured in the map class to this subinterface and any DLCIs configured on the subinterface.

Step 11 

Router(config-subif)# frame-relay interface-dlci dlci [ietf | cisco]

Assigns a data-link connection identifier (DLCI) to the Frame Relay subinterface. Enters Frame Relay DLCI configuration mode.

dlci is a number that identifies the data-link connection on the interface or subinterface.

(Optional) ietf sets the encapsulation method to comply with the Internet Engineering Task Force (IETF) standard (RFC 1490). Use this keyword when connecting to another vendor's equipment across a Frame Relay network.

(Optional) cisco indicates to use Cisco's own encapsulation, which is a 4-byte header, with 2 bytes to identify the data-link connection identifier (DLCI) and 2 bytes to identify the packet type. This is the default encapsulation type.

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_class
Router(config-map-c)# frame-relay fragment 300
Router(config-map-c)# service-policy output policy_13
Router(config-map-c)# no frame-relay adaptive-shaping
!
Router(config)# interface serial 5/0/0/1:0
Router(config-if)# hold-queue 4096 in
Router(config-if)# no ip address
Router(config-if)# no ip directed-broadcast
Router(config-if)# encapsulation frame-relay
Router(config-if)# frame-relay class lfi_map_class
!
Router(config)# interface serial 5/0/0/1:0.1 point-to-point
Router(config-subif)# ip address 192.168.1.1 255.255.255.0
Router(config-subif)# no ip directed-broadcast
Router(config-subif)# frame-relay interface-dlci 17
!
Router(config)# interface serial 5/0/0/1:0.2 point-to-point
Router(config-subif)# ip address 192.168.2.1 255.255.255.0
Router(config-subif)# no ip directed-broadcast
Router(config-subif)# frame-relay interface-dlci 18
 
   

Example 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 If the configuration example specified to apply another map class to subinterface 5/0/0/1:0.2, and that map class did not enable fragmentation, then DLCI 18 traffic would not be subject to LFI—only DLCI 17 traffic would be fragmented and interleaved.


Example 16-10 Attaching a Map Class to a Frame Relay Subinterface

Router(config)# map-class frame-relay lfi_map_class
Router(config-map-c)# service-policy output policy_13
Router(config-map-c)# frame-relay fragment 300
Router(config-map-c)# no frame-relay adaptive-shaping
!
Router(config)# interface serial 5/0/0/1:0
Router(config-if)# hold-queue 4096 in
Router(config-if)# no ip address
Router(config-if)# no ip directed-broadcast
Router(config-if)# encapsulation frame-relay
!
Router(config)# interface serial 5/0/0/1:0.1 point-to-point
Router(config-subif)# ip address 192.168.1.1 255.255.255.0
Router(config-subif)# no ip directed-broadcast
Router(config-subif)# frame-relay class lfi_map_class
Router(config-subif)# frame-relay interface-dlci 17
!
Router(config)# interface serial 5/0/0/1:0.2 point-to-point
Router(config-subif)# ip address 192.168.2.1 255.255.255.0
Router(config-subif)# no ip directed-broadcast
Router(config-subif)# frame-relay class lfi_map_class 
Router(config-subif)# frame-relay interface-dlci 18

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:

 
Command
Purpose

Step 1 

Router(config)# interface serial slot/module/port.T1#:channel

Creates or modifies a serial interface. Enters interface configuration mode.

Step 2 

Router(config-if)# hold-queue length {in | out}

Limits the size of the IP output queue on an interface. We recommend that you configure this command on all physical interfaces.

length is a number that specifies the maximum number of packets in the queue. Valid values are from 0 to 4096. We recommend 4096 packets for all line cards. By default, the input queue is 75 packets and the output queue is 40 packets.

in specifies the input queue.

out specifies the output queue.

Step 3 

Router(config-if)# no ip address

Removes any existing IP address from the main interface.

Step 4 

Router(config-if)# no ip directed-broadcast

Disables the translation of a directed broadcast to physical broadcasts. Instead, the directed broadcasts are dropped.

Step 5 

Router(config-if)# encapsulation frame-relay [ietf | cisco]

Specifies Frame Relay as the interface encapsulation type.

(Optional) ietf sets the encapsulation method to comply with the Internet Engineering Task Force (IETF) standard (RFC 1490). Use this keyword when connecting to another vendor's equipment across a Frame Relay network.

(Optional) cisco indicates to use Cisco's own encapsulation, which is a 4-byte header, with 2 bytes to identify the data-link connection identifier (DLCI) and 2 bytes to identify the packet type. This is the default encapsulation type.

Step 6 

Router(config)# interface serial slot/module/port.T1#:channel.subinterface- number [point-to-point]

Creates or modifies a serial interface or subinterface. Enters interface or subinterface configuration mode.

Step 7 

Router(config-subif)# ip address address mask

Specifies the IP address and subnet mask assigned to the subinterface.

address is the IP address.

mask is the subnet mask for the associated IP address.

Step 8 

Router(config-subif)# no ip directed-broadcast

Disables the translation of a directed broadcast to physical broadcasts. Instead, the directed broadcasts are dropped.

Step 9 

Router(config-subif)# frame-relay interface-dlci dlci [ietf | cisco]

Assigns a data-link connection identifier (DLCI) to the Frame Relay interface or subinterface. Enters Frame Relay DLCI configuration mode.

dlci is a number that identifies the data-link connection on the interface or subinterface.

(Optional) ietf sets the encapsulation method to comply with the Internet Engineering Task Force (IETF) standard (RFC 1490). Use this keyword when connecting to another vendor's equipment across a Frame Relay network.

(Optional) cisco indicates to use Cisco's own encapsulation, which is a 4-byte header, with 2 bytes to identify the data-link connection identifier (DLCI) and 2 bytes to identify the packet type. This is the default encapsulation type.

Step 10 

Router(config-fr-dlci)# frame-relay class name

Associates a map class with the DLCI.

name is the name of the map class.

Note When a map class is associated with a DLCI, only traffic on the DLCI is fragmented.

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_class
Router(config-map-c)# frame-relay fragment 300
Router(config-map-c)# service-policy output policy_13
Router(config-map-c)# no frame-relay adaptive-shaping
!
Router(config)# interface serial 5/0/0/1:0
Router(config-if)# hold-queue 4096 in
Router(config-if)# no ip address
Router(config-if)# no ip directed-broadcast
Router(config-if)# encapsulation frame-relay
!
Router(config)# interface serial 5/0/0/1:0.1 point-to-point
Router(config-subif)# ip address 192.168.1.1 255.255.255.0
Router(config-subif)# no ip directed-broadcast
Router(config-subif)# frame-relay interface-dlci 17
Router(config-fr-dlci)# frame-relay class lfi_map_class
!
Router(config)# interface serial 5/0/0/1:0.2 point-to-point
Router(config-subif)# ip address 192.168.2.1 255.255.255.0
Router(config-subif)# no ip directed-broadcast
Router(config-subif)# frame-relay interface-dlci 18

Attaching 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:

 
Command
Purpose

Step 1 

Router(config)# interface serial slot/module/port.T1#:channel

Creates or modifies a serial interface. Enters interface configuration mode.

Step 2 

Router(config-if)# hold-queue length {in | out}

Limits the size of the IP output queue on an interface. We recommend that you configure this command on all physical interfaces.

length is a number that specifies the maximum number of packets in the queue. Valid values are from 0 to 4096. We recommend 4096 packets for all line cards. By default, the input queue is 75 packets and the output queue is 40 packets.

in specifies the input queue.

out specifies the output queue.

Step 3 

Router(config-if)# no ip address

Removes any existing IP address from the main interface.

Step 4 

Router(config-if)# no ip directed-broadcast

Disables the translation of a directed broadcast to physical broadcasts. Instead, the directed broadcasts are dropped.

Step 5 

Router(config-if)# encapsulation frame-relay [ietf | cisco]

Specifies Frame Relay as the interface encapsulation type.

(Optional) ietf sets the encapsulation method to comply with the Internet Engineering Task Force (IETF) standard (RFC 1490). Use this keyword when connecting to another vendor's equipment across a Frame Relay network.

(Optional) cisco indicates to use Cisco's own encapsulation, which is a 4-byte header, with 2 bytes to identify the data-link connection identifier (DLCI) and 2 bytes to identify the packet type. This is the default encapsulation type.

Step 6 

Router(config-if)# frame-relay class name

Associates a map class with the main interface.

name is the name of the map class.

Note The router applies the service policy configured in the map class to this interface, its subinterfaces, and any DLCIs configured on the main interface and its subinterfaces.

Step 7 

Router(config-if)# interface serial slot/module/port.T1#:channel.subinterface- number [point-to-point]

Creates or modifies a serial subinterface. Enters subinterface configuration mode.

The point-to-point subinterface is used to establish a PVC connection to an interface on the remote end of the Frame Relay connection.

Step 8 

Router(config-subif)# ip address address mask

Specifies the IP address and subnet mask assigned to the subinterface.

address is the IP address.

mask is the subnet mask for the associated IP address.

Step 9 

Router(config-subif)# no ip directed-broadcast

Disables the translation of a directed broadcast to physical broadcasts. Instead, the directed broadcasts are dropped.

Step 10 

Router(config-subif)# service-policy {input | output} policy-map-name

Attaches the policy map you specify to the subinterface.

input indicates to apply the service policy to the traffic on the inbound interface.

output indicates to apply the service policy to the traffic on the outbound interface.

Note For QoS policies containing the bandwidth, priority, random-detect, queue-limit, and shape commands, you must specify the output keyword. The router ignores these commands when you use them with the input keyword.

policy-map-name is the name of the policy map.

Step 11 

Router(config-subif)# frame-relay interface-dlci dlci [ietf | cisco]

Assigns a data-link connection identifier (DLCI) to the Frame Relay subinterface. Enters Frame Relay DLCI configuration mode.

dlci is a number that identifies the data-link connection on the interface or subinterface.

(Optional) ietf sets the encapsulation method to comply with the Internet Engineering Task Force (IETF) standard (RFC 1490). Use this keyword when connecting to another vendor's equipment across a Frame Relay network.

(Optional) cisco indicates to use Cisco's own encapsulation, which is a 4-byte header, with 2 bytes to identify the data-link connection identifier (DLCI) and 2 bytes to identify the packet type. This is the default encapsulation type.

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_one
Router(config-map-c)# frame-relay fragment 300
Router(config-map-c)# no frame-relay adaptive-shaping
!
Router(config)# interface serial 5/0/0/1:0
Router(config-if)# hold-queue 4096 in
Router(config-if)# no ip address
Router(config-if)# no ip directed-broadcast
Router(config-if)# encapsulation frame-relay
Router(config-if)# frame-relay class lfi_map_class
!
Router(config)# interface serial 5/0/0/1:0.1 point-to-point
Router(config-subif)# ip address 192.168.1.1 255.255.255.0
Router(config-subif)# no ip directed-broadcast
Router(config-subif)# frame-relay interface-dlci 17
Router(config-fr-dlci)# service-policy output policy_13
!
Router(config)# interface serial 5/0/0/1:0.2 point-to-point
Router(config-subif)# ip address 192.168.2.1 255.255.255.0
Router(config-subif)# no ip directed-broadcast
Router(config-subif)# frame-relay interface-dlci 18
Router(config-fr-dlci)# service-policy output policy_13

Configuring 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

Configuring the Parent QoS Policy

Enabling FRF.12 Fragmentation on a Frame Relay Map Class

Attaching a Map Class to a Frame Relay DLCI

Configuring the Child QoS Policy

To configure a child QoS policy, enter the following commands beginning in global configuration mode:

 
Command
Purpose

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 Repeat this step to create additional traffic classes in the child policy map. Define policy map actions for each class such as the action defined in Step 4. Be sure that you define only one traffic class as the priority class.

Step 3 

Router(config-pmap-c)# priority

Configures a traffic class as a priority queue.

Note In Cisco IOS Release 12.0(25)S and Release 12.3(7)XI, and later releases, this command has no arguments. To specify a bandwidth rate, use the police command. For more information, see Chapter 6 "Policing Traffic."

Step 4 

Router(config-pmap-c) police [cir] bps 
[bcburst-normal [be] burst-excess 
[conform-action action] [exceed-action 
action] [violate-action action]

or

Router(config-pmap-c)# police [cir] percent percent [bc] normal-burst-in-msec [beexcess-burst-in-msec [conform-action action] [exceed-action action] [violate-action action]

or

police {cir cir} [bcburst-normal [pir 
pir] [bepeak-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:

 
Command
Purpose

Step 1 

Router(config)# policy-map policy-map-name

Configures the parent policy. Enters policy-map configuration mode.

policy-map-name is the name of the policy map.

Step 2 

Router(config-pmap)# class class-default

Configures the class-default class in the parent policy. Enters policy-map class configuration mode.

Step 3 

Router(config-pmap-c)# shape kbps-value

Shapes traffic to a specified bit rate.

kbps-value is the bit rate (in kilobits per second) used to shape the traffic.

Step 4 

Router(config-pmap-c)# service-policy policy-map-name

Applies the child policy to the parent class-default class.

policy-map-name is the name of the previously configured child policy map.

Note Do not specify the input or output keyword when applying a service policy to another child policy or to a parent policy.

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:

 
Command
Purpose

Step 1 

Router(config)# map-class frame-relay map-class-name

Creates or modifies a map class. Enters map-class configuration mode.

map-class-name is the name of the map class.

Step 2 

Router(config-map-c)# service-policy 
{input | output} policy-map-name

Applies the service policy you specify to the map class.

input indicates to apply the service policy to the traffic on the inbound interface.

output indicates to apply the service policy to the traffic on the outbound interface. For FRF.12 Fragmentation, specify the output keyword.

Note For QoS policies containing the bandwidth, priority, random-detect, queue-limit, and shape commands, you must specify the output keyword. The router ignores these commands when you use them with the input keyword.

policy-map-name is the name of the policy map.

Step 3 

Router(config-map-c)# frame-relay fragment fragment_size

Enables the fragmentation of Frame Relay frames on a Frame Relay map class.

fragment_size specifies the number of payload bytes from the original Frame Relay frame that go into each fragment. This number excludes the Frame Relay header of the original frame. Valid values are from 16 to 1600 bytes. The default is 53 bytes.

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:

 
Command
Purpose

Step 1 

Router(config)# interface serial slot/module/port.T1#:channel

Creates or modifies a serial interface. Enters interface configuration mode.

Step 2 

Router(config-if)# hold-queue length {in | out}

Limits the size of the IP output queue on an interface. We recommend that you configure this command on all physical interfaces.

length is a number that specifies the maximum number of packets in the queue. Valid values are from 0 to 4096. We recommend 4096 packets for all line cards. By default, the input queue is 75 packets and the output queue is 40 packets.

in specifies the input queue.

out specifies the output queue.

Step 3 

Router(config-if)# no ip address

(Optional) Removes any existing IP address from the main interface.

Step 4 

Router(config-if)# no ip directed broadcast

(Optional) Disables IP directed broadcasts. Instead, these broadcasts are dropped.

Step 5 

Router(config-if)# encapsulation frame-relay [ietf | cisco]

Specifies Frame Relay as the interface encapsulation type.

(Optional) ietf sets the encapsulation method to comply with the Internet Engineering Task Force (IETF) standard (RFC 1490). Use this keyword when connecting to another vendor's equipment across a Frame Relay network.

(Optional) cisco indicates to use Cisco's own encapsulation, which is a 4-byte header, with 2 bytes to identify the data-link connection identifier (DLCI) and 2 bytes to identify the packet type. This is the default encapsulation type.

Step 6 

Router(config-if)# interface serial slot/module/port/T1#:channel subinterface-number [point-to-point]

Creates or modifies a serial subinterface. Enters subinterface configuration mode.

Step 7 

Router(config-subif)# frame-relay interface-dlci dlci [ietf | cisco]

Assigns a data-link connection identifier (DLCI) to the Frame Relay interface or subinterface. Enters Frame Relay DLCI configuration mode.

dlci is a number that identifies the data-link connection on the interface or subinterface.

(Optional) ietf sets the encapsulation method to comply with the Internet Engineering Task Force (IETF) standard (RFC 1490). Use this keyword when connecting to another vendor's equipment across a Frame Relay network.

(Optional) cisco indicates to use Cisco's own encapsulation, which is a 4-byte header, with 2 bytes to identify the data-link connection identifier (DLCI) and 2 bytes to identify the packet type. This is the default encapsulation type.

Step 8 

Router(config-fr-dlci)# frame-relay class name

Associates a map class with the individual DLCI.

name is the name of the map class that you want to associate with the DLCI.

Note The router applies the service policy configured in the map class to only this individual DLCI.

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 16384
Router(config)# access-list 102 permit udp any eq 3000 any eq 3000
Router(config)# class-map match-all acl_101
Router(config-cmap)# match access-group 101
Router(config-cmap)# class-map match-all acl_102
Router(config-cmap)# match access-group 102
!
Router(config)# policy-map qos_pq_cbwfq_0
Router(config-pmap)# class acl_101
Router(config-pmap-c)# priority 
Router(config-pmap-c)# police percent 10
Router(config-pmap-c)# class acl_102
Router(config-pmap-c)# bandwidth percent 30
!
Router(config-pmap)# policy-map outer_policy
Router(config-pmap)# class class-default
Router(config-pmap-c)# shape 768
Router(config-pmap-c)# service-policy qos_pq_cbwfq_0
!
Router(config)# map-class frame-relay PQ_FR_CLASS_0
Router(config-map-c)# service-policy output outer_policy
Router(config-map-c)# frame-relay fragment 768
!
Router(config)# interface serial 5/0/0/1:0
Router(config-if)# hold-queue 4096 in
Router(config-if)# no ip address
Router(config-if)# no ip directed-broadcast
Router(config-if)# encapsulation frame-relay
!
Router(config-if)# interface serial 5/0/0/1:0.1 point-to-point
Router(config-if)# ip address 10.1.1.102 255.255.255.0
Router(config-subif)# frame-relay interface-dlci 27
Router(config-fr-dlci)# frame-relay class PQ_FR_CLASS_0

Configuring Interface-Based FRF.12 Fragmentation

To configure interface-based FRF.12 Fragmentation, enter the following commands beginning in global configuration mode:

 
Command
Purpose

Step 1 

Router(config)# interface serial slot/module/port.T1#:channel

Creates or modifies a serial interface. Enters interface configuration mode.

Step 2 

Router(config-if)# hold-queue length {in | out}

Limits the size of the IP output queue on an interface. We recommend that you configure this command on all physical interfaces.

length is a number that specifies the maximum number of packets in the queue. Valid values are from 0 to 4096. We recommend 4096 packets for all line cards. By default, the input queue is 75 packets and the output queue is 40 packets.

in specifies the input queue.

out specifies the output queue.

Step 3 

Router(config-if)# no ip address

(Optional) Removes any existing IP address from the main interface.

Step 4 

Router(config-if)# no ip directed broadcast

(Optional) Disables IP directed broadcasts. Instead, these broadcasts are dropped.

Step 5 

Router(config-if)# encapsulation frame-relay [ietf | cisco]

Specifies Frame Relay as the interface encapsulation type.

(Optional) ietf sets the encapsulation method to comply with the Internet Engineering Task Force (IETF) standard (RFC 1490). Use this keyword when connecting to another vendor's equipment across a Frame Relay network.

(Optional) cisco indicates to use Cisco's own encapsulation, which is a 4-byte header, with 2 bytes to identify the data-link connection identifier (DLCI) and 2 bytes to identify the packet type. This is the default encapsulation type.

Step 6 

Router(config-if)# frame-relay fragment fragment_size end-to-end

Enables the fragmentation of Frame Relay frames on a Frame Relay interface.

fragment_size specifies the number of payload bytes from the original Frame Relay frame that go into each fragment. This number excludes the Frame Relay header of the original frame. Valid values are from 16 to 1600 bytes. However, the minimum supported fragment size is 44 bytes. There is no default value.

Step 7 

Router(config-if)# service-policy {input | output} policy-map-name

Applies the service policy you specify to the map class.

input indicates to apply the service policy to the traffic on the inbound interface.

output indicates to apply the service policy to the traffic on the outbound interface.

Note For QoS policies containing the bandwidth, priority, random-detect, queue-limit, and shape commands, you must specify the output keyword. The router ignores these commands when you use them with the input keyword.

policy-map-name is the name of the policy map.

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:0
Router(config-if)# hold-queue 4096 in
Router(config-if)# no ip address
Router(config-if)# no ip directed-broadcast
Router(config-if)# encapsulation frame-relay
Router(config-if)# frame-relay fragment 200 end-to-end
Router(config-if)# service-policy output Premium
Router(config-if)# interface serial 5/0/0/1:0.1 point-to-point
Router(config-subif)# ip address 192.168.1.1 255.255.255.0
Router(config-subif)# no ip directed broadcast
Router(config-subif)# frame-relay interface-dlci 27
Router(config-subif)# interface serial 5/0/0/1:0.2 point-to-point
Router(config-subif)# ip address 192.16.2.1 255.255.255.0
Router(config-subif)# no ip directed broadcast
Router(config-subif)# frame-relay interface-dlci 28

Configuration Examples for Link Fragmentation and Interleaving

This section provides the following configuration examples:

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 Examples for PVC-Based FRF.12 Fragmentation

Configuration Example for Interface-Based FRF.12 Fragmentation

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/0
Router(config-controller)# framing SONET
Router(config-controller)# path 2 controller t3
!
Router(config)# controller T3 8/0/0.2
Router(config-controller)# overhead c2 4
Router(config-controller)# framing m23
Router(config-controller)# t1 7 channel-group 0 timeslots 1-24
Router(config-controller)# t1 8 channel-group 0 timeslots 1-24
Router(config-controller)# t1 9 channel-group 0 timeslots 1-24
!
Router(config)# class-map match-all prec_5
Router(config-cmap)# match ip precedence 5
!
Router(config)# policy-map policy_MLPLFI
Router(config-pmap)# class prec_5
Router(config-pmap-c)# priority
Router(config-pmap-c)# police 512000 9216 12000 conform-action transmit exceed-action 
set-prec-transmit 3 violate-action drop
Router(config-pmap-c)# class class-default
Router(config-pmap-c)# bandwidth remaining percent 20
!
Router(config)# interface Multilink2
Router(config-if)# ip address 10.0.0.6 255.255.255.252
Router(config-if)# load-interval 30
Router(config-if)# ppp acfc local request
Router(config-if)# ppp acfc remote apply
Router(config-if)# ppp chap hostname group2
Router(config-if)# ppp multilink
Router(config-if)# ppp multilink fragment delay 2
Router(config-if)# ppp multilink interleave
Router(config-if)# ppp multilink group 2
Router(config-if)# service-policy output policy_MLPLFI
!
Router(config)# interface serial 8/0/0.2/7:0
Router(config-subif)# no ip address
Router(config-subif)# encapsulation ppp
Router(config-subif)# load-interval 30
Router(config-subif)# no fair-queue
Router(config-subif)# no keepalive
Router(config-subif)# ppp chap hostname group2
Router(config-subif)# ppp multilink
Router(config-subif)# ppp multilink group 2
!
Router(config)# interface serial 8/0/0.2/8:0
Router(config-subif)# no ip address
Router(config-subif)# encapsulation ppp
Router(config-subif)# load-interval 30
Router(config-subif)# no fair-queue
Router(config-subif)# no keepalive
Router(config-subif)# ppp chap hostname group2
Router(config-subif)# ppp multilink
Router(config-subif)# ppp multilink group 2
!
Router(config)# interface serial 8/0/0.2/9:0
Router(config-subif)# no ip address
Router(config-subif)# encapsulation ppp
Router(config-subif)# load-interval 30
Router(config-subif)# no fair-queue
Router(config-subif)# no keepalive
Router(config-subif)# ppp chap hostname group2
Router(config-subif)# ppp multilink
Router(config-subif)# ppp multilink group 2

Configuration 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 Business
Router(config-cmap)# match access-group 100
!
Router(config-pmap)# policy-map Premium
Router(config-pmap)# class Business
Router(config-pmap-c)# priority
Router(config-pmap-c)# police 48
!
Router(config)# interface Multilink10020
Router(config-if)# ip address 172.16.0.1 255.255.0.0
Router(config-if)# service-policy output Premium
Router(config-if)# ppp multilink
Router(config-if)# ppp multilink fragment-delay 8
Router(config-if)# ppp multilink interleave
Router(config-if)# ppp multilink group 10020
Router(config-if)# ppp chap hostname router2
!
Router(config)# interface virtual-template1
Router(config-if)# ppp max-configure 110
Router(config-if)# ppp max-failure 100
Router(config-if)# ppp timeout retry 5
Router(config-if)# keepalive 30
Router(config-if)# no ip address
Router(config-if)# ppp authentication chap
Router(config-if)# ppp multilink
!
Router(config)# interface atm 4/0/0
Router(config-if)# hold-queue 4096 in
!
Router(config)# interface atm 4/0/0.1 point-to-point
Router(config-if)# pvc 0/32
Router(config-if-atm-vc)# vbr-nrt 100 80 1
Router(config-if-atm-vc)# encapsulation aal5snap
Router(config-if-atm-vc)# protocol ppp virtual-template1
Router(config-if-atm-vc)# ppp multilink group 10020

Configuration 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 Gold
Router(config-cmap)# match access-group 100
!
Router(config-pmap)# policy-map Business
Router(config-pmap)# class Gold
Router(config-pmap-c)# priority
Router(config-pmap-c)# police 48
!
Router(config)# interface Multilink8
Router(config-if)# ip address 172.16.0.1 255.255.0.0
Router(config-if)# service-policy output Premium
Router(config-if)# ppp multilink
Router(config-if)# ppp multilink fragment-delay 8
Router(config-if)# ppp multilink interleave
Router(config-if)# ppp multilink group 8
Router(config-if)# ppp chap hostname router2
 
   
Router(config)# interface virtual-template2
Router(config-if)# ppp max-configure 110
Router(config-if)# ppp max-failure 100
Router(config-if)# ppp timeout retry 5
Router(config-if)# keepalive 30
Router(config-if)# no ip address
Router(config-if)# ip mroute-cache
Router(config-if)# ppp authentication chap
Router(config-if)# ppp multilink
!
Router(config)# interface atm 6/0/0
Router(config-if)# no ip address
Router(config-if)# hold-queue 4096 in
Router(config-if)# no atm ilmi-keepalive
!
Router(config)# interface atm 6/0/0.1 point-to-point
Router(config-if)# no ip address
Router(config-if)# pvc 101/34
Router(config-if-atm-vc)# vbr-nrt 512 256 20
Router(config-if-atm-vc)# encapsulation aal5mux
Router(config-if-atm-vc)# ppp virtual-template 2
Router(config-if-atm-vc)# ppp multilink group 8
!
Router(config)# interface atm 6/0/0.2 point-to-point
Router(config-if)# no ip address
Router(config-if)# pvc 101/35
Router(config-if-atm-vc)# vbr-nrt 512 256 20
Router(config-if-atm-vc)# encapsulation aal5mux
Router(config-if-atm-vc)# ppp virtual-template 2
Router(config-if-atm-vc)# ppp multilink group 8
!
Router(config)# interface atm 6/0/0.3 point-to-point
Router(config-if)# no ip address
Router(config-if)# pvc 101/36
Router(config-if-atm-vc)# vbr-nrt 512 256 20
Router(config-if-atm-vc)# encapsulation aal5mux
Router(config-if-atm-vc)# ppp virtual-template 2
Router(config-if-atm-vc)# ppp multilink group 8

Configuration 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 Multilink10002
Router(config-if)# ip address 10.1.2.2 255.255.255.0
Router(config-if)# ppp multilink
Router(config-if)# ppp multilink fragment disable
Router(config-if)# ppp multilink fragment delay 8
Router(config-if)# ppp multilink interleave
Router(config-if)# ppp multilink group 10002
Router(config-if)# service-policy output Business
!
Router(config)# interface serial1/0/1
Router(config-if)# no ip address
Router(config-if)# encapsulation frame-relay
Router(config-if)# no keepalive
!
Router(config)# interface serial1/0/1.1 point-to-point
Router(config-if)# no keepalive
Router(config-if)# frame-relay interface-dlci 18 ppp Virtual-Template209
Router(config-if)# service-policy output Premium
!
Router(config)# interface Virtual-Template1
Router(config-if)# description mlp_lfi_c10k
Router(config-if)# no ip address
Router(config-if)# ppp chap hostname lfiofr-10002
Router(config-if)# ppp multilink
Router(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 frag
Router(config-map-c)# frame-relay cir 128000
Router(config-map-c)# frame-relay bc 1280
Router(config-map-c)# frame-relay fragment 40
Router(config-map-c)# frame-relay fair-queue
Router(config-map-c)# service-policy output Bronze
Router(config-map-c)# no frame-relay adaptive-shaping
!
Router(config)# interface serial 1/0/0/1:0
Router(config-if)# hold-queue 4096 in
Router(config-if)# no ip address
Router(config-if)# no ip directed-broadcast
Router(config-if)# encapsulation frame-relay
Router(config-if)# frame-relay class frag
!
Router(config)# interface serial 1/0/0/1:0.1 point-to-point
Router(config-subif)# ip address 192.168.1.1 255.255.255.0
Router(config-subif)# no ip directed-broadcast
Router(config-if)# frame-relay interface-dlci 100
!
Router(config)# interface serial 1/0/0/1:0.2 point-to-point
Router(config-subif)# ip address 192.168.2.1 255.255.255.0
Router(config-subif)# no ip directed-broadcast
Router(config-subif)# frame-relay interface-dlci 101
 
   

Example 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-class1
Router(config-map-c)# frame-relay fragment 300
Router(config-map-c)# no frame-relay adaptive-shaping
!
Router(config)# interface serial 5/0/0/1:0
Router(config-if)# hold-queue 4096 in
Router(config-if)# no ip address
Router(config-if)# no ip directed-broadcast
Router(config-if)# encapsulation frame-relay
!
Router(config)# interface serial 5/0/0/1:0.1 point-to-point
Router(config-subif)# ip address 192.168.10.1 255.255.255.0
Router(config-subif)# no ip directed-broadcast
Router(config-subif)# service-policy Business
Router(config-subif)# frame-relay class lfi-class1
Router(config-subif)# frame-relay interface-dlci 101
!
Router(config)# interface serial 5/0/0/1:0.2 point-to-point
Router(config-subif)# ip address 192.168.10.2 255.255.255.0
Router(config-subif)# no ip directed-broadcast
Router(config-subif)# frame-relay interface-dlci 102
 
   

Example 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 Voice
Router(config-map-c)# frame-relay fragment 320
Router(config-map-c)# frame-relay ip rtp priority 16384 16383 25
Router(config-map-c)# service-policy output Business
Router(config-map-c)# exit
Router(config)# interface serial 7/0/0/1:0
Router(config-if)# hold-queue 4096 in
Router(config-if)# no ip address
Router(config-if)# encapsulation frame-relay ietf
Router(config-if)# frame-relay intf-type dce 
Router(config-if)# interface serial 7/0/0/1:0.1 point-to-point
Router(config-subif)# ip address 10.32.0.1 255.255.255.0
Router(config-subif)# frame-relay interface-dlci 20
Router(config-fr-dlci)# frame-relay class Voice

Configuration 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.2
Router(config)# class-map voice
Router(config-cmap)# match access-group 101
!
Router(config)# policy-map llq
Router(config-pmap)# class voice
Router(config-pmap-c)# priority 
Router(config-pmap-c)# police 64000
Router(config-pmap-c)# class video
Router(config-pmap-c)# bandwidth 32
!
Router(config)# interface serial 3/0/0.1/1:0
Router(config-if)# hold-queue 4096 in
Router(config-if)# ip address 10.16.0.1 255.0.0.0
Router(config-if)# encapsulation frame-relay
Router(config-if)# bandwidth 128
Router(config-if)# clock rate 128000
Router(config-if)# service-policy output llq
Router(config-if)# frame-relay fragment 300 end-to-end
Router(config-if)# end
!
Router(config)# interface serial 3/0/0.1/1:0.1 point-to-point 
Router(config-if)# ip address 172.16.1.2 255.255.255.0 
Router(config-if)# no ip directed-broadcast 
Router(config-if)# frame-relay interface-dlci 109

Verifying and Monitoring Link Fragmentation and Interleaving

The Cisco 10000 series routers collect information about the number of:

Fragments and bytes sent

Unfragmented packets and bytes sent and received

Assembled packets and bytes received

Received fragments and bytes dropped due to excessive size of coalesced packets, out-of-sequence arrival, duplicate sequence numbers, unexpected begin fragment, or arrival without a begin fragment

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:

Command
Purpose

Router# debug atm lfi

Displays debug information for MLP over ATM-based LFI.

Router# debug frame-relay fragment

Displays information related to Frame Relay fragmentation on a PVC.

Router# debug frame-relay ppp

Displays error messages for link states and Local Management Interface (LMI) status changes for PPP over Frame Relay sessions.

Router# debug ppp multilink events

Displays information about events affecting multilink groups established for Bandwidth Allocation Control Protocol (BACP).

Router# debug ppp multilink fragments

Displays information about individual multilink fragments and important multilink events.

Note This command has memory overhead and should not be used when memory is scarce or when traffic is very high.

Router# show atm pvc

Displays all ATM permanent virtual connections (PVCs) and traffic information.

Router# show frame-relay fragment [interface interface] [dlci]

(FRF.12 Fragmentation only) Displays information about Frame Relay fragmentation such as fragmentation type, configured fragment size, and the number of fragments transmitted, received, and dropped. When you specify a specific interface and DLCI, additional information appears.

For the PRE2, the show frame-relay fragment command displays the number of output fragments.

interface is the type of interface for which you want to view Frame Relay fragmentation information.

interface is the number of the interface containing the data-link connection identifier (DLCI) for which you want to display fragmentation information.

dlci is a specific number that identifies a DLCI on the interface.

If you do not specify any parameter options, the command displays a summary of each DLCI configured for fragmentation.

Router# show frame-relay pvc [interface interface] [dlci]

Displays statistics about PVCs for Frame Relay interfaces.

Note For MLP over Frame Relay-based LFI, this command currently displays statistics for system traffic only. Data statistics do not display.

interface is the type of interface for which you want to view Frame Relay fragmentation information.

interface is the number of the interface containing the data-link connection identifier (DLCI) for which you want to display fragmentation information.

dlci is a specific number that identifies a DLCI on the interface. Statistics for the specified PVC also display when you specify a DLCI.

Router# show interfaces interface

Displays fragment and packet statistics for the interface you specify.

interface is the type and number of the interface.

(FRF.12) For the PRE1, this command displays the number of output fragments.

(FRF.12) For the PRE2 this command displays the number of output packets. Output fragments display using the show frame-relay fragment.

Interleaving data displays only if there are interleaves. For example, the following line shows interleaves:

Output queue: 315/64/164974/31191
(size/threshold/drops/interleaves)

Router# show interfaces virtual-access number [configuration]

Displays status, traffic data, and configuration information about the virtual access interface you specify.

Note This command currently displays statistics for system traffic only. Statistics for bundle traffic do not display. For information about bundle traffic, see the show interfaces or show ppp multilink command.

number is the number of the virtual access interface.

(Optional) configuration restricts output to configuration information.

Router# show ppp multilink [bundle-interface]

Displays bundle information for all of the MLP bundles and their PPP links configured on the router.

If you specify bundle-interface, the command displays information for only that specific bundle.

(Optional) bundle-interface specifies the multilink interface (for example, Multilink 5).

Router# show running-config

Displays information about the current router configuration, including information about each interface configuration.


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 Multilink2
 
   
Multilink2, bundle name is group2
  Endpoint discriminator is group2
  Bundle up for 02:31:57, 1/255 load
  Receive buffer limit 36000 bytes, frag timeout 1000 ms
  Bundle is Distributed
    0/0 fragments/bytes in reassembly list
    0 lost fragments, 0 reordered
    0/0 discarded fragments/bytes, 0 lost received
    0x0 received sequence, 0x1 sent sequence
  C10K Multilink PPP info
    Bundle transmit info
        send_seq_num   0x1
    Bundle reassembly info
        expected_seq_num:  0x000000
  Member links: 3 active, 0 inactive (max 10, min not set)
    Se8/0/0.2/7:0, since 02:31:57, 384 weight, 378 frag size
    Se8/0/0.2/9:0, since 00:03:46, 384 weight, 378 frag size
    Se8/0/0.2/8:0, since 00:03:06, 384 weight, 378 frag size HQF2_R2#
Multilink2 
 
   
  Service-policy output: policy_MLPLFI
 
   
    Class-map: prec_5 (match-all)
      217196 packets, 14334936 bytes
      30 second offered rate 264000 bps, drop rate 0 bps
      Match: ip precedence 5 
      Output queue: 0/128; 217688/14367408 packets/bytes output, 0/0 drops
      Absolute priority
      Police:
        512000 bps, 9216 limit, 12000 extended limit
        conformed 214828 packets, 14178648 bytes; action: transmit
        exceeded 0 packets, 0 bytes; action: set-prec-transmit 3
        violated 0 packets, 0 bytes; action: drop
 
   
    Class-map: class-default (match-any)
      34314 packets, 2264904 bytes
      30 second offered rate 0 bps, drop rate 0 bps
      Match: any 
      Output queue: 0/128; 33823/2232498 packets/bytes output, 0/0 drops
      Bandwidth : 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 fragment
 
   
interface	dlci	frag-type	size	in-frag	out-frag	dropped-frag
se5/0/0/1:0.1	17	end-to-end	300	0	0	0
se5/0/0/1:0.1	18	end-to-end	300	0	0	0
 
   

Example 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 109 
 
   
fragment 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 sequence
 
   

Example 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 109
 
   
This may severely impact network performance.
You are advised to enable 'no logging console debug'. Continue?[confirm]
Frame Relay fragment/packet debugging is on
Displaying fragments/packets on interface Serial0/0  dlci 109 only
 
   
 
   
Serial0/0(i): dlci 109, rx-seq-num 126, exp_seq-num 126, BE bits set, frag_hdr 04 C0 7E
 
   

Serial0/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.

Feature
Documentation

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

Configuring QoS Policy Actions and Rules

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