Finding Feature Information

Your software release may not support all the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the Feature Information for ASR1K Frame Relay - Multilink (MLFR-FRF.16).

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to
http:/​/​www.cisco.com/​go/​cfn
.
An account on Cisco.com is not required.

Prerequisites for ASR1K Frame Relay - Multilink (MLFR-FRF.16)

MFR must be configured on the peer device.

Restrictions for ASR1K Frame Relay - Multilink (MLFR-FRF.16)

Only the 2-octet Frame Relay format is supported.

Only T1 and E1 speed members are supported in a bundle.

All member links of a bundle must be of the same type.

The following Shared Port Adapter (SPA) types are supported:

SPA-2XCT3/DS0

SPA-4XCT3/DS0

SPA-8XCHT1/E1

SPA-1XCHOC12/DS0

SPA-1XCHSTM1/OC3

The following features are not supported with the ASR1K Frame Relay - Multilink (MLFR-FRF.16) feature:

Benefits of ASR1K Frame Relay - Multilink (MLFR-FRF.16)

Flexible Pool of Bandwidth

By combining multiple physical interfaces into a bundle, you can design a Frame Relay interface that has more bandwidth than is available from any single physical interface. For example, many new network applications require more bandwidth than is available on a T1 line. One option is to invest in a T3 line; however, T3 lines can be expensive and are not available in some locations. MFR provides a cost-effective solution to this problem by allowing multiple T1 lines to be aggregated into a single bundle of bandwidth.

Increased Service Resilience

When multiple physical interfaces are provisioned as a single bundle, they provide more service resilience than a single physical interface. If a link fails, the bundle continues to support the Frame Relay service by transmitting across the remaining bundle links.

Scalability

ASR1K supports up to 992 MFR bundles.

MFR bundles—The following table shows the maximum number of MFR bundles supported on ASR1K based on the number of links in a bundle:

Table 1 Maximum MFR Bundles

Links per Bundle

Number of MFR Bundles

1

992

2

496

3

330

4

248

Frame Relay DLCI—The number of Frame Relay DLCIs that can be configured on MFR subinterfaces equals the maximum number of MFR bundles on ASR1K. The maximum number of Frame Relay DLCIs that you can configure on MFR subinterfaces and in one MFR bundle is 992.

MFR subinterface—Because only point-to-point interfaces are supported, the number of DLCIs supported is equal to the number of MFR subinterfaces. Therefore, the maximum number of MFR subinterfaces and the maximum number of MFR interfaces supported in one bundle is 992.

Physical Links—The maximum number of physical links supported in a bundle is 10.

Link Integrity Protocol Control Messages

For link management, each end of a bundle link follows the MFR Link Integrity Protocol and exchanges link control messages with its peer (the other end of the bundle link). To bring up a bundle link, both ends of the link must complete an exchange of ADD_LINK and ADD_LINK_ACK messages. To maintain the link, both ends periodically exchange HELLO and HELLO_ACK messages. This exchange of hello messages and acknowledgments serve as a keepalive mechanism for the link. If a router is sending hello messages but not receiving acknowledgments, it will resend the hello message up to a configured maximum number of times. If the router exhausts the maximum number of retries, the bundle link line protocol is considered down (unoperational).

The bundle link interface’s line protocol status is considered up (operational) when the peer device acknowledges that it will use the same link for the bundle. The line protocol remains up when the peer device acknowledges the hello messages from the local router.

The bundle interface’s line status becomes up when at least one bundle link has its line protocol status up. The bundle interface’s line status goes down when the last bundle link is no longer in the up state. This behavior complies with the class A bandwidth requirement defined in FRF.16.

The bundle interface’s line protocol status is considered up when the Frame Relay data-link layer at the local router and peer device synchronize using the Local Management Interface (LMI), when LMI is enabled. The bundle line protocol remains up as long as the LMI keepalives are successful.

Variable Bandwidth Class Support

MFR FRF.16 variable bandwidth class support allows you to specify the criterion used to activate or deactivate a Frame Relay bundle.

Class A Single Link

The Frame Relay bundle is provisioned when one or more bundle links issue a BL_ACTIVATE message to indicate that an operational bandwidth is available. When this occurs, the bundle emulates a physical link by issuing a PH_ACTIVATE message to the data link layer.

When the operational bandwidth of a bundle link fails to meet operational requirements (for instance, if a bundle link is in rollback mode), the bundle link issues a BL_DEACTIVATE message. When all bundle links are down in a class A bundle, a PH_DEACTIVATE message is sent to the data link layer, indicating that the Frame Relay bundle cannot accept frames.

Note

Activate and deactivate messages are implementation-oriented messages only. They are not visible in the output of the debug commands.

Class B All Links

The Frame Relay bundle is provisioned when all bundle links issue a BL_ACTIVATE message to indicate that an operational bandwidth is available. When this occurs, the bundle emulates a physical link by issuing a PH_ACTIVATE message to the data link layer.

When the operational bandwidth of a bundle link fails to meet operational requirements (for instance, if it is in loopback mode), the bundle link issues a BL_DEACTIVATE message. When any bundle link is down in a class B bundle, a PH_DEACTIVATE message is sent to the data link layer, indicating that the Frame Relay bundle cannot accept frames.

Class C Threshold

A Frame Relay bundle is provisioned when a minimum number of links in the configured bundle issue a BL_ACTIVATE message, causing the bundle to emulate a physical link by issuing a PH_ACTIVATE message to the data link layer.

When the number of bundle links issuing a BL_ACTIVATE message falls below the configured threshold value, a PH_DEACTIVATE message is sent to the data link layer, indicating that the Frame Relay bundle cannot accept frames.

Load Balancing

MFR provides load balancing across bundle links within a bundle. If a bundle link that is chosen for transmission happens to be busy transmitting a long packet, the load-balancing mechanism can try another link, thus solving problems encountered when delay-sensitive packets have to wait.

ASR1K FRF.12 Support on MFR Interfaces

The ASR1K FRF.12 Support on MFR Interfaces feature enables the transport of realtime, delay-sensitive (voice) and nonrealtime, delay-insensitive (data) packets over the same, relatively slow-speed PVC.

During the transmission of packets, the larger, nonrealtime packets are fragmented into a sequence of smaller, mostly fixed-sized packets, also called fragments. The realtime packets are interleaved among the fragments. While receiving the packets, the nonrealtime fragments are reassembled and the resulting packets are forwarded along with the realtime packets. This approach minimizes the delay that can occur when nonrealtime and realtime traffic flow over the same PVC.

Benefits of ASR1K FRF.12

The ASR1K FRF.12 functionality prevents delay in Frame Relay networks by allowing edge routers to fragment large data packets before transmitting them across the network.

Limitations of ASR1K FRF.12

If a Frame Relay access device does not support FRF.12 fragmentation, the ASR1K FRF.12 Support on MFR Interfaces feature will not benefit the interface between the Frame Relay access device and the edge router. Fragmentation and reassembly occur on the interface between the edge router and the Frame Relay network.

If the Frame Relay access device is sending voice and unfragmented data on the same PVC, voice quality will suffer. The edge router will not reorder packets on PVCs.

Selecting a Fragment Size

You should set the fragment size based on the lowest port speed between routers. For example, for a hub-and-spoke Frame Relay topology, where the hub has a T1 speed and the remote routers have 64 kb/s port speeds, the fragmentation size must be set for 64 kb/s speed on both routers. Any other PVCs that share the same physical interface must use the same fragmentation size used by the voice PVC.

With pure end-to-end FRF.12 fragmentation, you should select a fragment size that is larger than the voice packet size.

The following table shows the recommended fragmentation sizes for a serialization delay of 10 ms:

(Optional) Specifies the bandwidth class criterion used to activate or deactivate a Frame Relay bundle.

Class A (single link)—The bundle will activate when any bundle link is up and deactivate when all bundle links are down (default).

Class B (all links)—The bundle will activate when all bundle links are up and deactivate when any bundle link is down.

Class C (threshold)—The bundle will activate when the minimum configured number of bundle links is up (the threshold) and deactivate when the minimum number of configured bundle links fails to meet the threshold.

Note

If no bandwidth class criterion is specified by using the
frame-relaymultilinkbandwidth-class command, the Frame Relay bundle will default to class A (single link).

Step 5

frame-relayintf-type [dce |
dte]

Example:

Router(config-if)# frame-relay intf-type dce

Configures a device to function as data communication equipment (DCE).

dce—(Optional) The router or access server functions as a switch connected to a router.

dte—(Optional) The router or access server is connected to a Frame Relay network.

Note

Only one end of a link should be configured as DCE. The other end will function as data terminal equipment (DTE), which is the default setting.

Step 6

frame-relaymultilinkbidname

Example:

Router(config-if)# frame-relay multilink bid router1

(Optional) Assigns a bundle identification name to an MFR bundle.

The bundle identification (BID) will not go into effect until the interface has gone from the “down” state to the “up” state. One way to bring the interface down and back up again is by using theshutdown and
noshutdown commands in interface configuration mode (assuming that the physical state of the link is always up).

Configuring an MFR Bundle Link

To minimize the latency that results from the arrival order of packets, Cisco recommends bundling physical links of the same line speed in one bundle.

Perform this task to configure an MFR bundle link.

SUMMARY STEPS

1.enable

2.configureterminal

3.interfaceserialnumber

4.encapsulationframe-relaymfrnumber [name]

5.frame-relaymultilinklidname

6.frame-relaymultilinkhelloseconds

7.frame-relaymultilinkackseconds

8.frame-relaymultilinkretrynumber

9.end

10.showframe-relaymultilink

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Router> enable

Enables privileged EXEC mode.

Enter your password if prompted.

Step 2

configureterminal

Example:

Router# configure terminal

Enters global configuration mode.

Step 3

interfaceserialnumber

Example:

Router(config)# interface serial 5/0

Selects a physical interface and enters interface configuration mode.

Step 4

encapsulationframe-relaymfrnumber [name]

Example:

Router(config-if)# encapsulation frame-relay mfr1

Creates an MFR bundle link and associates the link with a bundle.

Step 5

frame-relaymultilinklidname

Example:

Router(config-if)# frame-relay multilink lid first-link

(Optional) Assigns a bundle link identification name to an MFR bundle link.

The bundle link identification (LID) is not functional until the interface has gone from the “down” state to the “up” state. One way to bring the interface down and back up again is by using the
shutdown and
no shutdown commands in interface configuration mode.

Step 6

frame-relaymultilinkhelloseconds

Example:

Router(config-if)# frame-relay multilink hello 9

(Optional) Configures the interval in seconds after which a bundle link will send out hello messages.

The default value is 10 seconds.

Step 7

frame-relaymultilinkackseconds

Example:

Router(config-if)# frame-relay multilink ack 6

(Optional) Configures the interval (in seconds) for which a bundle link will wait for a hello message acknowledgment before resending the hello message.

The default value is 4 seconds.

Step 8

frame-relaymultilinkretrynumber

Example:

Router(config-if)# frame-relay multilink retry 3

(Optional) Configures the maximum number of times a bundle link will resend a hello message while waiting for an acknowledgment.

The default value is 2 tries.

Step 9

end

Example:

Router(config-if)# end

Ends the configuration session and returns to privileged EXEC mode.

Step 10

showframe-relaymultilink

Example:

Router# show frame-relay multilink

(Optional) Displays the current Frame Relay multilink configuration.

Configuring FRF.12 on an MFR Bundle Interface

Before You Begin

You must create a class map and a policy map before enabling FRF.12 fragmentation of Frame Relay frames. For the class map, define a differentiated services code point (DSCP) value as the match criterion.

The following is sample output from the
show frame-relay multilink command when the
serialnumber keyword and argument pair and the
detailed option are specified. Detailed information about the specified bundle links is displayed.

Standards and RFCs

Standard/RFC

Title

FRF.16.1

Multilink Frame Relay UNI/NNI Implementation Agreement,
May 2002

Technical Assistance

Description

Link

The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.

Feature Information for ASR1K Frame Relay - Multilink (MLFR-FRF.16)

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to
www.cisco.com/​go/​cfn. An account on Cisco.com is not required.

Glossary

BID--Bundle identification. The BID is the name used to identify the bundle. The BID can be assigned, or the default can be used.

BL_ACTIVATE--A message that controls the addition of a bundle link to a Frame Relay bundle.

BL_DEACTIVATE--A message that controls the removal a bundle link from a Frame Relay bundle.

bundle--A logical grouping of one or more physical interfaces using the formats and procedures of multilink Frame Relay. A bundle emulates a physical interface to the Frame Relay data-link layer. The bundle is also referred to as the MFR interface
.

bundlelink--An individual physical interface that is a member of a bundle.

HELLOmessage--A message that notifies a peer endpoint that the local endpoint is in the operational state (up).

HELLO_ACK--A message that notifies a peer endpoint that a hello message has been received.

LID--link identification. The LID is the name used to identify a bundle link. The LID can be assigned, or the default can be used.

LMI--Local Management Interface. A set of enhancements to the basic Frame Relay specification. LMI includes support for a keepalive mechanism, which verifies that data is flowing; a multicast mechanism, which provides the network server with its local DLCI and the multicast DLCI; global addressing, which gives DLCIs global rather than local significance in Frame Relay networks; and a status mechanism, which provides an ongoing status report on the DLCIs known to the switch.

NNI--Network-to-Network Interface. The interface between two Frame Relay devices that are both located in a private network or both located in a public network.

PH_ACTIVATE--A message that indicates that the Frame Relay bundle is up.

PH_DEACTIVATE--A message that indicates that the Frame Relay bundle is down.

UNI--User-to-Network Interface. The interface between a Frame Relay device in a public network and a Frame Relay device in a private network.