![]() |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Multilink Frame Relay FRF.16.1
![]() |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Contents
Multilink Frame Relay FRF.16.1Last Updated: November 27, 2011
The Multilink Frame Relay (FRF.16.1) feature introduces functionality based on the Frame Relay Forum Multilink Frame Relay UNI/NNI Implementation Agreement (FRF.16.1). This feature provides a cost-effective way to increase bandwidth for particular applications by enabling multiple serial links to be aggregated into a single bundle of bandwidth. Multilink Frame Relay (MFR) is supported on User-to-Network Interfaces (UNI) and Network-to-Network Interfaces (NNI) in Frame Relay networks.
Finding Feature InformationYour 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 Table at the end of this document. 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. Restrictions for Multilink Frame Relay FRF.16.1
Information About Multilink Frame Relay FRF.16.1
Benefits of Multilink Frame Relay FRF.16.1Flexible Pool of BandwidthBy 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. Multilink Frame Relay provides a cost-effective solution to this problem by allowing multiple T1 lines to be aggregated into a single bundle of bandwidth. Link Integrity Protocol Control MessagesFor 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). For a bundle link to be brought up, each end of the link must complete an exchange of ADD_LINK and ADD_LINK_ACK messages. To maintain the link, both ends periodically initiate the exchange of HELLO and HELLO_ACK messages. This exchange of hello messages and acknowledgments serves 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 (nonoperational). 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 protocol status is considered up when the Frame Relay data-link layer at the local router and peer device is synchronized 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 SupportMultilink Frame Relay (FRF.16.1) variable bandwidth class support allows you to specify the criterion used to activate or deactivate a Frame Relay bundle. Consistent with the Frame Relay Forum Multilink Frame Relay UNI/NNI Implementation Agreement (FRF.16.1), bandwidth classes A (single link), B (all links), and C (threshold) are supported. Class A (Single Link)The Frame Relay bundle is provisioned when one or more bundle links indicate by issuing a BL_ACTIVATE message that 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 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. Class B (All Links)The Frame Relay bundle is provisioned when all bundle links indicate by issuing a BL_ACTIVATE message that 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)The Frame Relay bundle is provisioned when the minimum number of links in the configured bundle issue a BL_ACTIVATE message. When this occurs, the bundle emulates a physical link by issuing a PH_ACTIVATE message to the data-link layer. When the number of bundle links that are 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 with Multilink Frame Relay FRF.16.1Multilink Frame Relay provides load balancing across the bundle links within a bundle. If a bundle link chosen for transmission happens to be busy transmitting a long packet, the load-balancing mechanism can try another link, thus solving the problems seen when delay-sensitive packets have to wait. How to Enable Multilink Frame Relay FRF.16.1
Configuring a Multilink Frame Relay Bundle
SUMMARY STEPS
DETAILED STEPS Configuring a Multilink Frame Relay Bundle LinkTo configure a bundle link interface for multilink Frame Relay, perform the steps in this section.
DETAILED STEPS
Monitoring and Maintaining Multilink Frame Relay FRF.16.1
SUMMARY STEPS
DETAILED STEPS
ExamplesThe following example shows output for the show frame-relay multilink command. Because a particular bundle or bundle link is not specified, information for all bundles and bundle links is displayed:
Router# show frame-relay multilink
Bundle: MFR0, state up, class A, no fragmentation
ID: Bundle-Dallas
Serial5/1, state up/up, ID: BL-Dallas-1
Serial5/3, state up/add-sent, ID: BL-Dallas-3
Bundle: MFR1, state down, class B, fragmentation
ID: Bundle-NewYork#1
Serial3/0, state up/up, ID: BL-NewYork-1
Serial3/2, state admin-down/idle, ID: BL-NewYork-2
The following example shows output for the show frame-relay multilink command when a Frame Relay bundle is configured as bandwidth class C (threshold):
Router# show frame-relay multilink
Bundle: MFR0, state down, class C (threshold 3), no fragmentation
ID: Bundle-Dallas
Serial5/1, state up/up, ID: BL-Dallas-1
Serial5/3, state up/add-sent, ID: BL-Dallas-3
The following example shows output for the show frame-relay multilink command when the serial number keyword and argument are specified. It displays information about the specified bundle link:
Router# show frame-relay multilink serial 3/2
Bundle links :
Serial3/2, HW state :down, Protocol state :Down_idle, LID :Serial3/2
Bundle interface = MFR0, BID = MFR0
The following examples show output for the show frame-relay multilink command when the serial number keyword and argument and the detailed option are specified. Detailed information about the specified bundle links is displayed. The first example shows a bundle link in the "idle" state. The second example shows a bundle link in the "up" state: Router# show frame-relay multilink serial 3 detail Bundle links: Serial3, HW state = up, link state = Idle, LID = Serial3 Bundle interface = MFR0, BID = MFR0 Cause code = none, Ack timer = 4, Hello timer = 10, Max retry count = 2, Current count = 0, Peer LID = Serial5/3, RTT = 0 ms Statistics: Add_link sent = 0, Add_link rcv'd = 10, Add_link ack sent = 0, Add_link ack rcv'd = 0, Add_link rej sent = 10, Add_link rej rcv'd = 0, Remove_link sent = 0, Remove_link rcv'd = 0, Remove_link_ack sent = 0, Remove_link_ack rcv'd = 0, Hello sent = 0, Hello rcv'd = 0, Hello_ack sent = 0, Hello_ack rcv'd = 0, outgoing pak dropped = 0, incoming pak dropped = 0 Router# show frame-relay multilink serial 3 detail Bundle links: Serial3, HW state = up, link state = Up, LID = Serial3 Bundle interface = MFR0, BID = MFR0 Cause code = none, Ack timer = 4, Hello timer = 10, Max retry count = 2, Current count = 0, Peer LID = Serial5/3, RTT = 4 ms Statistics: Add_link sent = 1, Add_link rcv'd = 20, Add_link ack sent = 1, Add_link ack rcv'd = 1, Add_link rej sent = 19, Add_link rej rcv'd = 0, Remove_link sent = 0, Remove_link rcv'd = 0, Remove_link_ack sent = 0, Remove_link_ack rcv'd = 0, Hello sent = 0, Hello rcv'd = 1, Hello_ack sent = 1, Hello_ack rcv'd = 0, outgoing pak dropped = 0, incoming pak dropped = 0 Configuration Examples for Multilink Frame Relay FRF.16.1Configuring Multilink Frame Relay ExampleThe following example shows the configuration of bundle "MFR1." Serial interfaces 5/0 and 6/0 are configured as bundle links: interface MFR1 no ip address mls qos trust dscp frame-relay intf-type dce frame-relay multilink bid router1 ! interface MFR1.1 point-to-point ip address 10.0.1.1 255.255.255.0 ip pim sparse-mode mls qos trust dscp frame-relay interface-dlci 100 interface Serial5/0 encapsulation frame-relay MFR1 frame-relay multilink lid first-link frame-relay multilink hello 9 frame-relay multilink retry 3 interface Serial6/0 encapsulation frame-relay MFR1 frame-relay multilink ack 4 Configuring Variable Bandwidth Class Support ExampleThe following example configures the Frame Relay bundle "MFR1" to use the class B (all links) criterion to be activated or deactivated: interface MFR1 ip address 10.1.1.1 255.255.255.0 frame-relay interface-dlci 100 frame-relay multilink bandwidth-class b Additional ReferencesMIBsTechnical Assistance
Feature Information for Multilink Frame Relay FRF.16.1The 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.
GlossaryBID --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 . bundle link --An individual physical interface that is a member of a bundle. DLCI --data-link connection identifier. A value that identifies a permanent virtual circuit (PVC) in a Frame Relay network. HELLO message --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. Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R) Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental. © 2011 Cisco Systems, Inc. All rights reserved.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||