-
Cisco IOS Wide-Area Networking Configuration Guide, Release 12.2
-
About Cisco IOS Software Documentation
-
Using Cisco IOS Software
-
Wide-Area Networking Overview
-
Configuring ATM
-
Configuring Broadband Access: PPP and Routed Bridge Encapsulation
-
Configuring Frame Relay
-
Configuring Frame Relay-ATM Interworking
-
Configuring SMDS
-
Configuring X.25 and LAPB
- Appendixes
-
Index
-
Table Of Contents
Frame Relay Hardware Configurations
Frame Relay Configuration Task List
Enabling Frame Relay Encapsulation on an Interface
Configuring Dynamic or Static Address Mapping
Configuring Dynamic Address Mapping
Configuring Static Address Mapping
Explicitly Configuring the LMI
Setting the LMI Keepalive Interval
Setting the LMI Polling and Timer Intervals
Enabling Frame Relay SVC Service
Configuring SVCs on a Physical Interface
Configuring SVCs on a Subinterface
Configuring a Map Group with E.164 or X.121 Addresses
Associating the Map Class with Static Protocol Address Maps
Configuring Frame Relay Traffic Shaping
Defining VCs for Different Types of Traffic
Enabling Frame Relay Traffic Shaping on the Interface
Frame Relay ForeSight Prerequisites
Frame Relay Congestion Notification Methods
Configuring Enhanced Local Management Interface
Disabling Automatic IP Address Selection
Configuring the IP Address to Be Used for ELMI Address Registration
Enabling ELMI Address Registration on an Interface
Verifying ELMI Address Registration
Specifying a Traffic-Shaping Map Class for the Interface
Defining a Map Class with Queueing and Traffic-Shaping Parameters
Defining Priority Queue Lists for the Map Class
Defining Custom Queue Lists for the Map Class
Configuring Frame Relay Switching
Frame Relay Switching over ISDN B Channels
Frame Relay Switching Configuration Task List
Enabling Frame Relay Switching
Configuring a Frame Relay DTE Device, DCE Switch, or NNI Support
Configuring Frame Relay Traffic Shaping on Switched PVCs
Configuring Traffic Policing on UNI DCE Devices
Configuring Congestion Management on Switched PVCs
Configuring FRF.12 Fragmentation on Switched PVCs
Verifying Frame Relay Switching
Troubleshooting Frame Relay Switching
Customizing Frame Relay for Your Network
Configuring Frame Relay End-to-End Keepalives
Verifying Frame Relay End-to-End Keepalives
Configuring PPP over Frame Relay
Configuring Frame Relay Subinterfaces
Understanding Frame Relay Subinterfaces
Defining Subinterface Addressing
Configuring Transparent Bridging for Frame Relay
Configuring a Backup Interface for a Subinterface
Disabling or Reenabling Frame Relay Inverse ARP
Creating a Broadcast Queue for an Interface
Configuring Frame Relay Fragmentation
End-to-End FRF.12 Fragmentation
Frame Relay Fragmentation Using FRF.11 Annex C
Cisco-Proprietary Fragmentation
Frame Relay Fragmentation and Hardware Compression Interoperability
Frame Relay Fragmentation Conditions and Restrictions
Configuring Payload Compression
Configuring Packet-by-Packet Payload Compression
Configuring Standard-Based FRF.9 Compression
Configuring Data-Stream Compression
Configuring TCP/IP Header Compression
Configuring an Individual IP Map for TCP/IP Header Compression
Configuring an Interface for TCP/IP Header Compression
Disabling TCP/IP Header Compression
Configuring Real-Time Header Compression with Frame Relay Encapsulation
Configuring Discard Eligibility
Configuring DLCI Priority Levels
Monitoring and Maintaining the Frame Relay Connections
Frame Relay Configuration Examples
IETF Encapsulation on the Interface Example
IETF Encapsulation on a Per-DLCI Basis Example
Static Address Mapping Examples
Two Routers in Static Mode Example
Frame Relay Multipoint Subinterface with Dynamic Addressing Example
IPX Routes over Frame Relay Subinterfaces Example
Unnumbered IP over a Point-to-Point Subinterface Example
Transparent Bridging Using Subinterfaces Example
Frame Relay Traffic Shaping Examples
Traffic Shaping with Three Point-to-Point Subinterfaces Example
Traffic Shaping with ForeSight Example
Backward Compatibility Example
Booting from a Network Server over Frame Relay Example
Frame Relay Switching Examples
PVC Switching Configuration Example
Hybrid DTE/DCE PVC Switching Example
Switching over an IP Tunnel Example
Frame Relay Switching over ISDN B Channels Example
Traffic Shaping on Switched PVCs Example
Traffic Policing on a UNI DCE Example
Congestion Management on Switched PVCs Example
Congestion Management on the Traffic-Shaping Queue of a Switched PVC Example
FRF.12 Fragmentation on a Switched PVC Configuration Example
Frame Relay End-to-End Keepalive Examples
End-to-End Keepalive Bidirectional Mode with Default Configuration Example
End-to-End Keepalive Request Mode with Default Configuration Example
End-to-End Keepalive Request Mode with Modified Configuration Example
PPP over Frame Relay DTE Example
PPP over Frame Relay DCE Example
Frame Relay Fragmentation Configuration Examples
Frame Relay Fragmentation with Hardware Compression Example
Payload Compression Configuration Examples
FRF.9 Compression for Subinterfaces Using the frame-relay map Command Example
FRF.9 Compression for Subinterfaces Example
Data-Stream Hardware Compression with TCP/IP Header Compression on a Multipoint
Subinterface ExampleData-Stream Hardware Compression with RTP Header Compression and Frame Relay Fragmentation Example
TCP/IP Header Compression Examples
IP Map with Inherited TCP/IP Header Compression Example
Using an IP Map to Override TCP/IP Header Compression Example
Disabling Inherited TCP/IP Header Compression Example
Disabling Explicit TCP/IP Header Compression Example
Configuring Frame Relay
This chapter describes the tasks for configuring Frame Relay on a router or access server. For further general information about Frame Relay, see the chapter "Wide-Area Networking Overview" at the beginning of this book.
For a complete description of the Frame Relay commands mentioned in this chapter, refer to the chapter "Frame Relay Commands" in the Cisco IOS Wide-Area Networking Command Reference. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.
To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the section "Identifying Supported Platforms" in the chapter "Using Cisco IOS Software."
For information on the following related topics, see the corresponding chapters in other Cisco publications:
Cisco Frame Relay MIB
The Cisco Frame Relay MIB adds extensions to the standard Frame Relay MIB (RFC 1315). It provides additional link-level and virtual circuit (VC)-level information and statistics that are mostly specific to Cisco Frame Relay implementation. This MIB provides SNMP network management access to most of the information covered by the show frame-relay commands such as, show frame-relay lmi, show frame-relay pvc, show frame-relay map, and show frame-relay svc.
Frame Relay Hardware Configurations
You can create Frame Relay connections using one of the following hardware configurations:
•
Routers and access servers connected directly to the Frame Relay switch
•
Note
The CSU/DSU converts V.35 or RS-449 signals to the properly coded T1 transmission signal for successful reception by the Frame Relay network. Figure 22 illustrates the connections among the components.
Figure 22 Typical Frame Relay Configuration
The Frame Relay interface actually consists of one physical connection between the network server and the switch that provides the service. This single physical connection provides direct connectivity to each device on a network.
Frame Relay Configuration Task List
You must follow certain required, basic steps to enable Frame Relay for your network. In addition, you can customize Frame Relay for your particular network needs and monitor Frame Relay connections. The following sections outline these tasks:
•
•
Note
The tasks described in the following sections are used to enhance or customize your Frame Relay:
•
•
•
•
•
•
See the section "Frame Relay Configuration Examples" at the end of this chapter for ideas about how to configure Frame Relay on your network. See the chapter "Frame Relay Commands" in the Cisco IOS Wide-Area Networking Command Reference for information about the Frame Relay commands listed in the following tasks. Use the index or search online for documentation of other commands.
Enabling Frame Relay Encapsulation on an Interface
To enable Frame Relay encapsulation on the interface level, use the following commands beginning in global configuration mode:
Frame Relay supports encapsulation of all supported protocols in conformance with RFC 1490, allowing interoperability among multiple vendors. Use the Internet Engineering Task Force (IETF) form of Frame Relay encapsulation if your router or access server is connected to another vendor's equipment across a Frame Relay network. IETF encapsulation is supported either at the interface level or on a per-VC basis.
Shut down the interface prior to changing encapsulation types. Although shutting down the interface is not required, it ensures that the interface is reset for the new encapsulation.
For an example of enabling Frame Relay encapsulation on an interface, see the section "IETF Encapsulation Examples" later in this chapter.
Configuring Dynamic or Static Address Mapping
Dynamic address mapping uses Frame Relay Inverse ARP to request the next-hop protocol address for a specific connection, given its known DLCI. Responses to Inverse ARP requests are entered in an address-to-DLCI mapping table on the router or access server; the table is then used to supply the next-hop protocol address or the DLCI for outgoing traffic.
Inverse ARP is enabled by default for all protocols it supports, but can be disabled for specific protocol-DLCI pairs. As a result, you can use dynamic mapping for some protocols and static mapping for other protocols on the same DLCI. You can explicitly disable Inverse ARP for a protocol-DLCI pair if you know that the protocol is not supported on the other end of the connection. See the section "Disabling or Reenabling Frame Relay Inverse ARP" later in this chapter for more information.
See the following sections for further details on configuring dynamic or static address mapping:
•
•
Configuring Dynamic Address Mapping
Inverse ARP is enabled by default for all protocols enabled on the physical interface. Packets are not sent out for protocols that are not enabled on the interface.
Because Inverse ARP is enabled by default, no additional command is required to configure dynamic mapping on an interface.
Configuring Static Address Mapping
A static map links a specified next-hop protocol address to a specified DLCI. Static mapping removes the need for Inverse ARP requests; when you supply a static map, Inverse ARP is automatically disabled for the specified protocol on the specified DLCI.
You must use static mapping if the router at the other end either does not support Inverse ARP at all or does not support Inverse ARP for a specific protocol that you want to use over Frame Relay.
To establish static mapping according to your network needs, use one of the following commands in interface configuration mode:
The supported protocols and the corresponding keywords to enable them are as follows:
•
•
•
•
•
•
•
You can greatly simplify the configuration for the Open Shortest Path First (OSPF) protocol by adding the optional broadcast keyword when doing this task. Refer to the frame-relay map command description in the Cisco IOS Wide-Area Networking Command Reference and the examples at the end of this chapter for more information about using the broadcast keyword.
For examples of establishing static address mapping, refer to the section "Static Address Mapping Examples" later in this chapter.
Configuring the LMI
Beginning with Cisco IOS Release 11.2, the software supports Local Management Interface (LMI) autosense, which enables the interface to determine the LMI type supported by the switch. Support for LMI autosense means that you are no longer required to configure the LMI explicitly.
See the following sections for further details on configuring the LMI:
•
For information on using Enhanced Local Management Interface with traffic shaping, see the section "Configuring Frame Relay Traffic Shaping" later in this chapter.
For an example of configuring the LMI, see the section "Pure Frame Relay DCE Example" later in this chapter.
Activating LMI Autosense
LMI autosense is active in the following situations:
•
•
•
•
See the following sections for additional information concerning activating LMI autosense:
Status Request
When LMI autosense is active, it sends out a full status request, in all three LMI types, to the switch. The order is ANSI, ITU, cisco, but it is done in rapid succession. Cisco IOS software provides the ability to listen in on both DLCI 1023 (cisco LMI) and DLCI 0 (ANSI and ITU) simultaneously.
Status Messages
One or more of the status requests will elicit a reply (status message) from the switch. The router will decode the format of the reply and configure itself automatically. If more than one reply is received, the router will configure itself with the type of the last received reply. This is to accommodate intelligent switches that can handle multiple formats simultaneously.
LMI Autosense
If LMI autosense is unsuccessful, an intelligent retry scheme is built in. Every N391 interval (default is 60 seconds, which is 6 keep exchanges at 10 seconds each), LMI autosense will attempt to ascertain the LMI type. For more information about N391, see the frame-relay lmi-n391dte command in the chapter "Frame Relay Commands" in the Cisco IOS Wide-Area Networking Command Reference.
The only visible indication to the user that LMI autosense is under way is that debug frame lmi is turned on. At every N391 interval, the user will now see three rapid status inquiries coming out of the serial interface: one in ANSI, one in ITU, and one in cisco LMI-type.
Configuration Options
No configuration options are provided; LMI autosense is transparent to the user. You can turn off LMI autosense by explicitly configuring an LMI type. The LMI type must be written into NVRAM so that next time the router powers up, LMI autosense will be inactive. At the end of autoinstall, a frame-relay lmi-type xxx statement is included within the interface configuration. This configuration is not automatically written to NVRAM; you must explicitly write the configuration to NVRAM by using the copy system:running-config or copy nvram:startup-config command.
Explicitly Configuring the LMI
Frame Relay software supports the industry-accepted standards for addressing the LMI, including the Cisco specification. If you want to configure the LMI and thus deactivate LMI autosense, perform the tasks in the following sections:
•
•
•
Setting the LMI Type
If the router or access server is attached to a public data network (PDN), the LMI type must match the type used on the public network. Otherwise, the LMI type can be set to suit the needs of your private Frame Relay network.
You can set one of the following three types of LMIs on Cisco devices: ANSI T1.617 Annex D, Cisco, and ITU-T Q.933 Annex A. To do so, use the following commands beginning in interface configuration mode:
Step 1
Router(config-if)# frame-relay lmi-type {ansi | cisco | q933a}
Sets the LMI type.
Step 2
Router# copy nvram:startup-config destination
Writes the LMI type to NVRAM.
For an example of setting the LMI type, see the section "Pure Frame Relay DCE Example" later in this chapter.
Setting the LMI Keepalive Interval
A keepalive interval must be set to configure the LMI. By default, this interval is 10 seconds and, according to the LMI protocol, must be less than the corresponding interval on the switch. To set the keepalive interval, use the following command in interface configuration mode:
To disable keepalives on networks that do not utilize LMI, use the no keepalive interface configuration command. For an example of how to specify an LMI keepalive interval, see the section "Two Routers in Static Mode Example" later in this chapter.
Setting the LMI Polling and Timer Intervals
You can set various optional counters, intervals, and thresholds to fine-tune the operation of your LMI DTE and DCE devices. Set these attributes by using one or more of the following commands in interface configuration mode:
See the chapter "Frame Relay Commands" in the Cisco IOS Wide-Area Networking Command Reference for polling and timing interval commands.
Configuring Frame Relay SVCs
Access to Frame Relay networks is made through private leased lines at speeds ranging from 56 kbps to 45 Mbps. Frame Relay is a connection-oriented packet-transfer mechanism that establishes VCs between endpoints.
Switched virtual circuits (SVCs) allow access through a Frame Relay network by setting up a path to the destination endpoints only when the need arises and tearing down the path when it is no longer needed.
SVCs can coexist with PVCs in the same sites and routers. For example, routers at remote branch offices might set up PVCs to the central headquarters for frequent communication, but set up SVCs with each other as needed for intermittent communication. As a result, any-to-any communication can be set up without any-to-any PVCs.
On SVCs, quality of service (QoS) elements can be specified on a call-by-call basis to request network resources.
SVC support is offered in the Enterprise image on Cisco platforms that include a serial or HSSI interface.
You must have the following services before Frame Relay SVCs can operate:
•
•
For examples of configuring Frame Relay SVCs, see the section "SVC Configuration Examples" later in this chapter.
Operating SVCs
SVC operation requires that the Data Link layer (Layer 2) be set up, running ITU-T Q.922 Link Access Procedures to Frame mode bearer services (LAPF), prior to signalling for an SVC. Layer 2 sets itself up as soon as SVC support is enabled on the interface, if both the line and the line protocol are up. When the SVCs are configured and demand for a path occurs, the Q.933 signalling sequence is initiated. Once the SVC is set up, data transfer begins.
Q.922 provides a reliable link layer for Q.933 operation. All Q.933 call control information is transmitted over DLCI 0; this DLCI is also used for the management protocols specified in ANSI T1.617 Annex D or Q.933 Annex A.
You must enable SVC operation at the interface level. Once it is enabled at the interface level, it is enabled on any subinterfaces on that interface. One signalling channel, DLCI 0, is set up for the interface, and all SVCs are controlled from the physical interface.
Enabling Frame Relay SVC Service
To enable Frame Relay SVC service and set up SVCs, perform the tasks in the following sections. The subinterface tasks are not required, but offer additional flexibility for SVC configuration and operation. The LAPF tasks are not required and not recommended unless you understand thoroughly the impacts on your network.
•
•
•
•
•
•
For examples of configuring Frame Relay SVCs, see the section "SVC Configuration Examples" later in this chapter.
Configuring SVCs on a Physical Interface
To enable SVC operation on a Frame Relay interface, use the following commands beginning in global configuration mode:
Map group details are specified with the map-list command.
Configuring SVCs on a Subinterface
To configure Frame Relay SVCs on a subinterface, complete all the commands in the preceding section, except assigning the map group. After the physical interface is configured, use the following commands beginning in global configuration mode:
Configuring a Map Class
Perform the following tasks to configure a map class:
•
•
•
•
•
To configure a map class, use the following commands beginning in global configuration mode:
Step 1
Router(config)# map-class frame-relay map-class-name
Specifies Frame Relay map class name and enters map class configuration mode.
Step 2
Router(config-map-class)# frame-relay custom-queue-list list-number
Specifies a custom queue list to be used for the map class.
Step 3
Router(config-map-class)# frame-relay priority-group list-number
Assigns a priority queue to VCs associated with the map class.
Step 4
Router(config-map-class)# frame-relay adaptive-shaping [becn | foresight]1
Enables the type of BECN feedback to throttle the frame-transmission rate.
Step 5
Router(config-map-class)# frame-relay cir in bps
Specifies the inbound committed information rate (CIR), in bits per second.
Step 6
Router(config-map-class)# frame-relay cir out bps
Specifies the outbound CIR, in bits per second.
Step 7
Router(config-map-class)# frame-relay mincir in bps2
Sets the minimum acceptable incoming CIR, in bits per second.
Step 8
Router(config-map-class)# frame-relay mincir out bps2
Sets the minimum acceptable outgoing CIR, in bits per second.
Step 9
Router(config-map-class)# frame-relay bc in bits2
Sets the incoming committed burst size (Bc), in bits.
Step 10
Router(config-map-class)# frame-relay bc out bits2
Sets the outgoing Bc, in bits.
Step 11
Router(config-map-class)# frame-relay be in bits2
Sets the incoming excess burst size (Be), in bits.
Step 12
Router(config-map-class)# frame-relay be out bits2
Sets the outgoing Be, in bits.
Step 13
Router(config-map-class)# frame-relay idle-timer seconds2
Sets the idle timeout interval, in seconds.
1 This command replaces the frame-relay becn-response-enable command, which will be removed in a future Cisco IOS release. If you use the frame-relay becn-response-enable command in scripts, you should replace it with the frame-relay adaptive-shaping becn command.
2 The in and out keywords are optional. Configuring the command without the in and out keywords will apply that value to both the incoming and the outgoing traffic values for the SVC setup. For example, frame-relay cir 56000 applies 56000 to both incoming and outgoing traffic values for setting up the SVC.
You can define multiple map classes. A map class is associated with a static map, not with the interface or subinterface itself. Because of the flexibility this association allows, you can define different map classes for different destinations.
Configuring a Map Group with E.164 or X.121 Addresses
After you have defined a map group for an interface, you can associate the map group with a specific source and destination address to be used. You can specify E.164 addresses or X.121 addresses for the source and destination. To specify the map group to be associated with a specific interface, use the following command in global configuration mode:
Associating the Map Class with Static Protocol Address Maps
To define the protocol addresses under a map-list command and associate each protocol address with a specified map class, use the class command. Use this command for each protocol address to be associated with a map class. To associate a map class with a protocol address, use the following command in map list configuration mode:
The ietf keyword specifies RFC 1490 encapsulation; the broadcast keyword specifies that broadcasts must be carried. The trigger keyword, which can be configured only if broadcast is also configured, enables a broadcast packet to trigger an SVC. If an SVC already exists that uses this map class, the SVC will carry the broadcast.
Configuring LAPF Parameters
Frame Relay Link Access Procedure for Frame Relay (LAPF) commands are used to tune Layer 2 system parameters to work well with the Frame Relay switch. Normally, you do not need to change the default settings. However, if the Frame Relay network indicates that it does not support the Frame Reject frame (FRMR) at the LAPF Frame Reject procedure, use the following command in interface configuration mode:
Router(config-if)# no frame-relay lapf frmr
Selects not to send FRMR frames at the LAPF Frame Reject procedure.
By default, the Frame Reject frame is sent at the LAPF Frame Reject procedure.
Note
If you must change Layer 2 parameters for your network environment and you understand the resulting functional change, use the following commands as needed:
Configuring Frame Relay Traffic Shaping
Traffic shaping applies to both PVCs and SVCs. For information about creating and configuring SVCs, see the section "Configuring Frame Relay SVCs" earlier in this chapter.
To configure Frame Relay traffic shaping, perform the tasks in the following sections:
•
•
•
•
•
•
•
•
Note
For examples of configuring Frame Relay traffic shaping, see the section "Frame Relay Traffic Shaping Examples" later in this chapter.
Defining VCs for Different Types of Traffic
By defining separate VCs for different types of traffic and specifying queueing and an outbound traffic rate for each VC, you can provide guaranteed bandwidth for each type of traffic. By specifying different traffic rates for different VCs over the same line, you can perform virtual time division multiplexing. By throttling outbound traffic from high-speed lines in central offices to lower-speed lines in remote locations, you can ease congestion and data loss in the network; enhanced queueing also prevents congestion-caused data loss.
Enabling Frame Relay Traffic Shaping on the Interface
Enabling Frame Relay traffic shaping on an interface enables both traffic shaping and per-VC queueing on all the PVCs and SVCs on the interface. Traffic shaping enables the router to control the circuit's output rate and react to congestion notification information if also configured.
To enable Frame Relay traffic shaping on the specified interface, use the following command in interface configuration mode:
Router(config-if)# frame-relay traffic-shaping
Enables Frame Relay traffic shaping and per-VC queueing.
Note
—When traffic shaping is enabled (by using the frame-relay traffic-shaping command), but a map class is not assigned to the VC
—When traffic shaping is enabled (by using the frame-relay traffic-shaping command) and a map class is assigned to the VC, but traffic-shaping parameters have not been defined in the map classTo configure a map class with traffic-shaping and per-VC queueing parameters, see the sections "Specifying a Traffic-Shaping Map Class for the Interface" and "Defining a Map Class with Queueing and Traffic-Shaping Parameters".
Frame Relay ForeSight
ForeSight is the network traffic control software used in some Cisco switches. The Cisco Frame Relay switch can extend ForeSight messages over a User-to-Network Interface (UNI), passing the backward congestion notification for VCs.
ForeSight allows Cisco Frame Relay routers to process and react to ForeSight messages and adjust VC level traffic shaping in a timely manner.
ForeSight must be configured explicitly on both the Cisco router and the Cisco switch. ForeSight is enabled on the Cisco router when Frame Relay traffic shaping is configured. However, the router's response to ForeSight is not applied to any VC until the frame-relay adaptive-shaping foresight command is added to the VCs map-class. When ForeSight is enabled on the switch, the switch will periodically send out a ForeSight message based on the time value configured. The time interval can range from 40 to 5000 milliseconds.
When a Cisco router receives a ForeSight message indicating that certain DLCIs are experiencing congestion, the Cisco router reacts by activating its traffic-shaping function to slow down the output rate. The router reacts as it would if it were to detect the congestion by receiving a packet with the backward explicit congestion notification (BECN) bit set.
When ForeSight is enabled, Frame Relay traffic shaping will adapt to ForeSight messages and BECN messages.
For an example of configuring Foresight, see the section "Traffic Shaping with ForeSight Example" later in this chapter.
Frame Relay ForeSight Prerequisites
For router ForeSight to work, the following conditions must exist on the Cisco router:
•
•
The following additional condition must exist on the Cisco switch:
•
Frame Relay router ForeSight is enabled automatically when you use the frame-relay traffic-shaping command. However, you must issue the map-class frame-relay command and the frame-relay adaptive-shaping foresight command before the router will respond to ForeSight and apply the traffic-shaping effect on a specific interface, subinterface, or VC.
Frame Relay Congestion Notification Methods
The difference between the BECN and ForeSight congestion notification methods is that BECN requires a user packet to be sent in the direction of the congested DLCI to convey the signal. The sending of user packets is not predictable and, therefore, not reliable as a notification mechanism. Rather than waiting for user packets to provide the congestion notification, timed ForeSight messages guarantee that the router receives notification before congestion becomes a problem. Traffic can be slowed down in the direction of the congested DLCI.
Configuring Enhanced Local Management Interface
Enhanced Local Management Interface (ELMI) allows the router to learn QoS parameters and connectivity information from the Cisco switch and to use this information for traffic shaping, configuration, or management purposes. ELMI simplifies the process of configuring traffic shaping on the router and reduces chances of specifying inconsistent or incorrect values when configuring the router. ELMI works between Cisco routers and Cisco switches (BPX and IGX platforms).
ELMI QoS Autosense
When used in conjunction with traffic shaping, ELMI enables the router to respond to changes in the network dynamically. ELMI enables automated exchange of Frame Relay QoS parameter information between the Cisco router and the Cisco switch. Figure 23 illustrates a Cisco switch and a Cisco router, both configured with ELMI enabled. The switch sends QoS information to the router, which uses it for traffic rate enforcement.
Figure 23 Enhanced Local Management Interface—Sent Between the Cisco Switch and the Cisco Router
Routers can base congestion management and prioritization decisions on known QoS values, such as the Committed Information Rate (CIR), Committed Burst Size (Bc), and Excess Burst Size (Be). The router senses QoS values from the switch and can be configured to use those values in traffic shaping.
It is not necessary to configure traffic shaping on the interface to enable ELMI, but you may want to do so in order to know the values being used by the switch. If you want the router to respond to the QoS information received from the switch by adjusting the output rate, you must configure traffic shaping on the interface. To configure traffic shaping, use the frame-relay traffic-shaping command in interface configuration mode.
ELMI Address Registration
ELMI address registration enables a network management system (NMS) to detect connectivity among Cisco switches and routers in a network using the ELMI protocol. During ELMI version negotiation, neighboring devices exchange their management IP addresses and ifIndex. The NMS polls the devices and uses the Cisco Frame Relay MIB to collect this connectivity information. ELMI address registration allows for autodetection of the complete network topology.
Figure 24 shows a typical network in which ELMI address registration is in use.
Figure 24 Connectivity Detection Using ELMI Address Registration
ELMI address registration takes place on all interfaces on which ELMI is enabled, even if all the interfaces are connected to the same router or switch. The router periodically sends a version inquiry message with version information, the management IP address, and ifIndex to the switch. The switch sends its management IP address and ifIndex using the version status message. When the management IP address of the switch changes, an asynchronous ELMI version status message is immediately sent to the neighboring device.
Note
When ELMI is enabled, the router automatically chooses the IP address of one of the interfaces to use for ELMI address registration purposes. The router will choose the IP address of an Ethernet interface first, and then serial and other interfaces. You have the option to use the IP address chosen by the router or to disable the autoaddress mechanism and configure the management IP address yourself. You can also choose to disable ELMI address registration on a specific interface or on all interfaces.
To configure ELMI, complete the tasks in the following sections:
•
•
•
•
•
For examples of the configurations in this section, see the section "ELMI Configuration Examples" at the end of this chapter.
Enabling ELMI
To enable ELMI, use the following commands beginning in interface configuration mode:
Disabling Automatic IP Address Selection
Automatic IP address selection is enabled by default when ELMI is enabled.
To disable the automatic selection of the IP address to be used for ELMI address registration, use the following global configuration command:
Router(config)# no frame-relay address registration auto-address
Disables the automatic selection of the IP address to be used for ELMI address registration.
Note
Configuring the IP Address to Be Used for ELMI Address Registration
To configure the IP address for ELMI address registration, use the following global configuration command:
Router(config)# frame-relay address registration ip address
Configures the IP address to be used for ELMI address registration.
Note
Enabling ELMI Address Registration on an Interface
To enable ELMI address registration on an interface, use the following interface configuration command:
Verifying ELMI Address Registration
To verify that ELMI address registration is configured correctly, use the following privileged EXEC configuration command:
Router# show frame-relay qos-autosense [interface interface]
Displays the QoS values and ELMI address registration information sensed from the switch.
Specifying a Traffic-Shaping Map Class for the Interface
If you specify a Frame Relay map class for a main interface, all the VCs on its subinterfaces inherit all the traffic-shaping parameters defined for the class.
To specify a map class for the specified interface, use the following command beginning in interface configuration mode:
Router(config-if)# frame-relay class map-class-name
Specifies a Frame Relay map class for the interface.
You can override the default for a specific DLCI on a specific subinterface by using the class VC configuration command to assign the DLCI explicitly to a different class. See the section "Configuring Frame Relay Subinterfaces" for information about setting up subinterfaces.
For an example of assigning some subinterface DLCIs to the default class and assigning others explicitly to a different class, see the section "Frame Relay Traffic Shaping Examples" later in this chapter.
Defining a Map Class with Queueing and Traffic-Shaping Parameters
When defining a map class for Frame Relay, you can specify the average and peak rates (in bits per second) allowed on VCs associated with the map class. You can also specify either a custom queue list or a priority queue group to use on VCs associated with the map class.
To define a map class, use the following commands beginning in global configuration mode:
Step 1
Router(config)# map-class frame-relay map-class-name
Specifies a map class to define.
Step 2
Router(config-map-class)# frame-relay traffic-rate average [peak]
Defines the traffic rate for the map class.
Step 3
Router(config-map-class)# frame-relay custom-queue-list list-number
Specifies a custom queue list.
Step 4
Router(config-map-class)# frame-relay priority-group list-number
Specifies a priority queue list.
Step 5
Router(config-map-class)# frame-relay adaptive-shaping {becn | foresight}1
Selects BECN or ForeSight as congestion backward-notification mechanism to which traffic shaping adapts.
1 This command replaces the frame-relay becn-response-enable command, which will be removed in a future Cisco IOS release. If you use the frame-relay becn-response-enable command in scripts, you should replace it with the frame-relay adaptive-shaping software command.
For an example of map class backward compatibility and interoperability, see the section "Backward Compatibility Example" later in this section.
Defining Access Lists
You can specify access lists and associate them with the custom queue list defined for any map class. The list number specified in the access list and the custom queue list tie them together. See the appropriate protocol chapters for information about defining access lists for the protocols you want to transmit on the Frame Relay network.
Defining Priority Queue Lists for the Map Class
You can define a priority list for a protocol and you can also define a default priority list. The number used for a specific priority list ties the list to the Frame Relay priority group defined for a specified map class.
For example, if you enter the frame relay priority-group 2 command for the map class "fast_vcs" and then you enter the priority-list 2 protocol decnet high command, that priority list is used for the "fast_vcs" map class. The average and peak traffic rates defined for the "fast_vcs" map class are used for DECnet traffic.
Defining Custom Queue Lists for the Map Class
You can define a queue list for a protocol and a default queue list. You can also specify the maximum number of bytes to be transmitted in any cycle. The number used for a specific queue list ties the list to the Frame Relay custom queue list defined for a specified map class.
For example, if you enter the frame relay custom-queue-list 1 command for the map class "slow_vcs" and then you enter the queue-list 1 protocol ip list 100 command, that queue list is used for the "slow_vcs" map class; access-list 100 definition is also used for that map class and queue. The average and peak traffic rates defined for the "slow_vcs" map class are used for IP traffic that meets the access list 100 criteria.
Configuring Frame Relay Switching
Frame Relay switching is a means of switching packets based on the DLCI, which can be considered the Frame Relay equivalent of a MAC address. You perform switching by configuring your Cisco router or access server into a Frame Relay network. There are two parts to a Frame Relay network:
•
•
