Cisco IOS Wide-Area Networking Configuration Guide, Release 12.1
Configuring Frame Relay

Table Of Contents

Configuring Frame Relay

Cisco Frame Relay MIB

Frame Relay Hardware Configurations

Frame Relay Configuration Task List

Enabling Frame Relay Encapsulation on an Interface

Configuring Dynamic or Static Address Mapping

Configuring Dynamic Mapping

Configuring Static Mapping

Configuring the LMI

Activating LMI Autosense

Status Request

Status Messages

LMI Autosense

Configuration Options

Explicitly Configuring the LMI

Setting the LMI Type

Setting the LMI Keepalive Interval

Setting the LMI Polling and Timer Intervals

Configuring Frame Relay SVCs

Operating SVCs

Enabling Frame Relay SVC Service

Configuring SVCs on a Physical Interface

Configuring SVCs on a Subinterface

Configuring a Map Class

Configuring a Map Group with E.164 or X.121 Addresses

Associating the Map Class with Static Protocol Address Maps

Configuring LAPF Parameters

Configuring Frame Relay Traffic Shaping

Defining VCs for Different Types of Traffic

Enabling Frame Relay Traffic Shaping on the Interface

Frame Relay ForeSight

Frame Relay ForeSight Prerequisites

Frame Relay Congestion Notification Methods

Enabling Enhanced Local Management Interface

Specifying a Traffic Shaping Map Class for the Interface

Defining a Map Class with Queueing and Traffic Shaping Parameters

Defining Access Lists

Defining Priority Queue Lists for the Map Class

Defining Custom Queue Lists for the Map Class

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

Enabling 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

Configuring Frame Relay Switching

Enabling Frame Relay Switching

Configuring a Frame Relay DTE Device, DCE Switch, or NNI Support

Specifying the Static Route

Disabling or Reenabling Frame Relay Inverse ARP

Creating a Broadcast Queue for an Interface

Configuring Payload Compression

Configuring Standard-Based FRF.9 Compression

Selecting FRF.9 Compression Method

Configuring FRF.9 Compression Using Map Statements

Configuring FRF.9 Compression on the Subinterface

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

AppleTalk Routing Example

DECnet Routing Example

IPX Routing Example

Subinterface Examples

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

SVC Configuration Examples

SVC Interface Example

SVC Subinterface Example

Frame Relay Traffic Shaping Examples

Traffic Shaping with Three Point-to-Point Subinterfaces Example

Traffic Shaping with ForeSight Example

Enhanced Local Management Interface Example

Backward Compatibility Example

Booting from a Network Server over Frame Relay 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 Examples

PPP over Frame Relay DTE Example

PPP over Frame Relay DCE Example

Frame Relay Switching Examples

PVC Switching Configuration Example

Pure Frame Relay DCE Example

Hybrid DTE/DCE PVC Switching Example

Switching over an IP Tunnel Example

FRF.9 Compression Configuration Examples

FRF.9 Compression for Subinterfaces Using the frame-relay map Command Example

FRF.9 Compression for Subinterfaces 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 TCP/IP Header Compression Examples

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 "Wide-Area Networking Overview" chapter at the beginning of this book. The following new features are included in this chapter:

Frame Relay end-to-end keepalives

Configuring PPP over Frame Relay

For a complete description of the Frame Relay commands mentioned in this chapter, refer to the "Frame Relay Commands" chapter 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.

See the following chapters in other Cisco publications for information on the topics indicated below:

To. . .
Refer to the. . .

Send DDR traffic over Frame Relay

"Configuring Legacy DDR Spokes" and "Configuring Legacy DDR Hubs" chapters in the "Dial-on-Demand Routing Configuration" part in the Cisco IOS Dial Services Configuration Guide: Terminal Services.

Install software on a new router or access server by downloading from a central server over an interface that supports Frame Relay

"Loading and Maintaining System Images, Microcode, and Firmware" chapter in the Cisco IOS Configuration Fundamentals Configuration Guide.

Use AutoInstall over Frame Relay

"Using Configuration Tools" chapter in the Cisco IOS Configuration Fundamentals Configuration Guide.

Configure transparent bridging between devices over a Frame Relay network

"Configuring Transparent Bridging" chapter in the Cisco IOS Bridging and IBM Networking Configuration Guide.

Configure source-route bridging between SNA devices over a Frame Relay network

"Configuring Source-Route Bridging" chapter in the Cisco IOS Bridging and IBM Networking Configuration Guide.

Configure serial tunnel (STUN) and block serial tunnel encapsulation between devices over a Frame Relay network

"Configuring Serial Tunnel and Block Serial Tunnel" chapter in the Cisco IOS Bridging and IBM Networking Configuration Guide.

Configure access between SNA devices over a Frame Relay network

"Configuring SNA Frame Relay Access Support" chapter in the Cisco IOS Bridging and IBM Networking Configuration Guide.

Configure Voice over Frame Relay Using FRF.11 and FRF.12

"Configuring Voice over Frame Relay" chapter in the Cisco IOS Multiservice Applications Configuration Guide.

Configure Frame Relay traffic shaping (additional information)

"Configuring Frame Relay and Frame Relay Traffic Shaping" chapter in the Cisco IOS Quality of Service Solutions Configuration Guide.


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

Connect routers and access servers directly to the Frame Relay switch.

Connect routers and access servers directly to a channel service unit/digital service unit (CSU/DSU), which then connects to a remote Frame Relay switch.


Note Routers can connect to Frame Relay networks either by direct connection to a Frame Relay switch or through CSU/DSUs. However, a single router interface configured for Frame Relay can only be configured for one of these methods.


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 13 illustrates the connections between the different components.

Figure 13 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:

Enabling Frame Relay Encapsulation on an Interface (Required)

Configuring Dynamic or Static Address Mapping (Required)

The tasks described in the following sections are used to enhance or customize your Frame Relay:

Configuring the LMI (Optional)

Configuring Frame Relay SVCs (Optional)

Configuring Frame Relay Traffic Shaping (Optional)

Customizing Frame Relay for Your Network (Optional)

Monitoring and Maintaining the Frame Relay Connections (Optional)

See the "Frame Relay Configuration Examples" section at the end of this chapter for ideas of how to configure Frame Relay on your network. See the "Frame Relay Commands" chapter 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:

 
Command
Purpose

Step 1 

interface type number

Specifies the interface, and enters interface configuration mode.

Step 2 

encapsulation frame-relay [ietf]

Enables and specifies Frame Relay encapsulation method.

Frame Relay supports encapsulation of all supported protocols in conformance with RFC 1490, allowing interoperability between 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 "IETF Encapsulation Examples" section 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 "Disabling or Reenabling Frame Relay Inverse ARP" section later in this chapter for more information.

See the following sections for further details on configuring dynamic or static address mapping:

Configuring Dynamic Mapping

Configuring Static Mapping

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

Command
Purpose

frame-relay map protocol protocol-address dlci [broadcast] [ietf] [cisco]

Maps between a next hop protocol address and DLCI destination address.

frame-relay map clns dlci [broadcast]

Defines a DLCI used to send ISO CLNS frames.

frame-relay map bridge dlci [broadcast] [ietf]

Defines a DLCI destination bridge.


The supported protocols and the corresponding keywords to enable them are as follows:

IP—ip

DECnet—decnet

AppleTalk—appletalk

XNS—xns

Novell IPX—ipx

VINES—vines

ISO CLNS—clns

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:

Activating LMI Autosense

Explicitly Configuring the LMI

For information on using Enhanced Local Management Interface with traffic shaping, see the "Configuring Frame Relay Traffic Shaping" section later in this chapter.

For an example of configuring the LMI, see the "Pure Frame Relay DCE Example" section later in this chapter.

Activating LMI Autosense

LMI autosense is active in the following situations:

The router is powered up or the interface changes state to up.

The line protocol is down but the line is up.

The interface is a Frame Relay DTE.

The LMI type is not explicitly configured.

See the following sections for additional information concerning activating LMI autosense:

Status Request

Status Messages

LMI Autosense

Configuration Options

Status Request

When LMI autosense is active, it sends out a full status request, in all three LMI flavors, to the switch. The order is ANSI, ITU, cisco but is done in rapid succession. Unlike previous software capability, we can now 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 "Frame Relay Commands" chapter of the Cisco IOS Wide-Area Networking Command Reference.

The only visible indication to the user that LMI autosense is underway is when debug frame lmi is turned on. Every N391 interval, the user will now see three rapid status enquiries 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 commands.

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 (Required)

Setting the LMI Keepalive Interval (Required)

Setting the LMI Polling and Timer Intervals (Optional)

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 three types of LMIs on our 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:

 
Command
Purpose

Step 1 

frame-relay lmi-type {ansi | cisco | q933a}

Sets the LMI type.

Step 2 

copy nvram:startup-config destination

Writes the LMI type to NVRAM.

For an example of setting the LMI type, see the "Pure Frame Relay DCE Example" section 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, per 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:

Command
Purpose

keepalive number

Sets the LMI keepalive interval.


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 "Two Routers in Static Mode Example" section 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:

Command
Purpose

frame-relay lmi-n392dce threshold

Sets the DCE and Network-to-Network Interface (NNI) error threshold.

frame-relay lmi-n393dce events

Sets the DCE and NNI monitored events count.

frame-relay lmi-t392dce seconds

Sets the polling verification timer on a DCE or NNI interface.

frame-relay lmi-n391dte keep-exchanges

Sets a full status polling interval on a DTE or NNI interface.

frame-relay lmi-n392dte threshold

Sets the DTE or NNI error threshold.

frame-relay lmi-n393dte events

Sets the DTE and NNI monitored events count.


See the "Frame Relay Commands" chapter 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:

Frame Relay SVC support by the service provider—The service provider's switch must be capable of supporting SVC operation.

Physical loop connection—A leased line or dedicated line must exist between the router (DTE) and the local Frame Relay switch.

For examples of configuring Frame Relay SVCs, see the "SVC Configuration Examples" section 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.

Configuring SVCs on a Physical Interface (Required)

Configuring SVCs on a Subinterface (Optional)

Configuring a Map Class (Required)

Configuring a Map Group with E.164 or X.121 Addresses (Required)

Associating the Map Class with Static Protocol Address Maps (Required)

Configuring LAPF Parameters (Optional)

For examples of configuring Frame Relay SVCs, see the "SVC Configuration Examples" section 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:

 
Command
Purpose

Step 1 

interface type number

Specifies the physical interface.

Step 2 

ip address ip-address mask

Specifies the interface IP address, if needed.

Step 3 

encapsulation frame-relay

Enables Frame Relay encapsulation on the interface.

Step 4 

map-group group-name

Assigns a map group to the interface.

Step 5 

frame-relay svc

Enables Frame Relay SVC support on the interface.

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 previous section, except assigning a the map group. After the physical interface is configured, use the following commands beginning in global configuration mode:

 
Command
Purpose

Step 1 

interface type number.subinterface-number {multipoint | point-to-point}

Specifies a subinterface configured for SVC operation.

Step 2 

ip address ip-address mask

Specifies the subinterface IP address, if needed.

Step 3 

map-group group-name

Assigns a map group to the subinterface.

Configuring a Map Class

Perform the following tasks to configure a map class:

Specify the map class name. (Required)

Specify a custom queue list for the map class. (Optional)

Specify a priority queue list for the map class. (Optional)

Enable BECN feedback to throttle the output rate on the SVC for the map class. (Optional)

Set nondefault QoS values for the map class (no need to set the QoS values; default values are provided). (Optional)

To configure a map class, use the following commands beginning in global configuration mode:

 
Command
Purpose

Step 1 

map-class frame-relay map-class-name

Specifies Frame Relay map class name and enters map class configuration mode.

Step 2 

frame-relay custom-queue-list list-number

Specifies a custom queue list to be used for the map class.

Step 3 

frame-relay priority-group list-number

Assigns a priority queue to VCs associated with the map class.

Step 4 

frame-relay adaptive-shaping [becn | foresight]1

Enables the type of BECN feedback to throttle the frame-transmission rate.

Step 5 

frame-relay cir in bps

Specifies the inbound committed information rate (CIR).

Step 6 

frame-relay cir out bps

Specifies the outbound committed information rate (CIR).

Step 7 

frame-relay mincir in bps 2

Sets the minimum acceptable incoming CIR.

Step 8 

frame-relay mincir out bps 2

Sets the minimum acceptable outgoing CIR.

Step 9 

frame-relay bc in bits 2

Sets the incoming committed burst size (Bc).

Step 10 

frame-relay bc out bits 2

Sets the outgoing committed burst size (Bc).

Step 11 

frame-relay be in bits 2

Sets the incoming excess burst size (Be).

Step 12 

frame-relay be out bits 2

Sets the outgoing excess burst size (Be).

Step 13 

frame-relay idle-timer seconds 2

Sets the idle timeout interval.

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

Command
Purpose

map-list map-group-name source-addr {e164 | x121} source-address dest-addr {e164 | x121} destination-address

Specifies the map group associated with specific source and destination addresses for the SVC.


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:

Command
Purpose

class protocol protocol-address class class-name [ietf] [broadcast [trigger]]

Specifies a destination protocol address and a Frame Relay map class name from which to derive QoS information.


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:

Command
Purpose

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 Manipulation of Layer 2 parameters is not recommended if you do not know well the resulting functional change. For more information, refer to the ITU-T Q.922 specification for LAPF.


If you must change Layer 2 parameters for your network environment and you understand the resulting functional change, use the following commands as needed:

Command
Purpose

frame-relay lapf k number

Sets the LAPF window size k.

frame-relay lapf n200 retries

Sets the LAPF maximum retransmission count N200.

frame-relay lapf n201 bytes

Sets maximum length of the Information field of the LAPF I frame N201.

frame-relay lapf t200 tenths-of-a-second

Sets the LAPF retransmission timer value T200.

frame-relay lapf t203 seconds

Sets the LAPF link idle timer value T203 of DLCI 0.


Configuring Frame Relay Traffic Shaping

Traffic shaping applies to both PVCs and SVCs. For information about creating and configuring SVCs, see the "Configuring Frame Relay SVCs" section of this chapter.

To configure Frame Relay traffic shaping, perform the tasks in the following sections:

Enabling Frame Relay Encapsulation on an Interface (earlier in this chapter)

Defining VCs for Different Types of Traffic

Enabling Frame Relay Traffic Shaping on the Interface

Enabling Enhanced Local Management Interface

Specifying a Traffic Shaping Map Class for the Interface

Defining a Map Class with Queueing and Traffic Shaping Parameters

Defining Access Lists

Defining Priority Queue Lists for the Map Class

Defining Custom Queue Lists for the Map Class

The following Frame Relay traffic shaping capabilities were introduced with Cisco IOS Release 11.2:

Rate Enforcement on a Per-VC Basis—The peak rate for outbound traffic. The value can be set to match CIR or another value.

Dynamic Traffic Throttling on a Per-VC Basis—When BECN packets indicate congestion on the network, the outbound traffic rate is automatically stepped down; when congestion eases, the outbound traffic rate is increased. This feature is enabled by default.

Enhanced Queueing Support on a Per-VC Basis—Either custom queueing or priority queueing can be configured for individual VCs.


Note Frame Relay traffic shaping is not effective for Layer 2 PVC switching using the frame-relay route command.


For examples of configuring Frame Relay traffic shaping, see the "Frame Relay Traffic Shaping Examples" section 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 interface's PVCs and SVCs. 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:

Command
Purpose

frame-relay traffic-shaping

Enables Frame Relay traffic shaping and per-VC queueing.



Note The default committed information rate (CIR) of 56K will apply in the following situations:
—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 class


To 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 "Traffic Shaping with ForeSight Example" section later in this chapter.

Frame Relay ForeSight Prerequisites

For Router ForeSight to work, the following conditions must exist on the Cisco router:

Frame Relay traffic shaping must be enabled on the interface.

The traffic shaping for a circuit is adapted to ForeSight.

The following additional condition must exist on the Cisco switch:

The UNI connecting to the router is Consolidated Link Layer Management (CLLM) enabled, with the proper time interval specified.

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.

Enabling Enhanced Local Management Interface

When used in conjunction with traffic shaping, the router can respond to changes in the network dynamically. Enhanced Local Management Interface (ELMI) allows the router to learn QoS parameters from the Cisco switch and use them for traffic shaping, configuration, or management purposes. ELMI also simplifies the process of configuring traffic shaping on the router. ELMI reduces chances of specifying inconsistent or incorrect values when configuring the router.

To configure ELMI, use the following commands beginning in interface configuration mode:

 
Command
Purpose

Step 1 

interface type number

Specifies the physical interface.

Step 2 

encapsulation frame-relay [cisco | ietf]

Enables Frame Relay encapsulation on the interface.

Step 3 

frame-relay QoS-autosense

Enables ELMI.


Note ELMI enables automated exchange of Frame Relay QoS parameter information between the Cisco router and the Cisco switch. 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. This enhancement works between Cisco routers and Cisco switches (BPX and IGX platforms).


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

For an example of configuring a Frame Relay interface with QoS autosense enabled, see the section "Enhanced Local Management Interface Example" later in this chapter.

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 in beginning interface configuration mode:

Command
Purpose

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 "Configuring Frame Relay Subinterfaces" section 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 "Frame Relay Traffic Shaping Examples" section 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:

 
Command
Purpose

Step 1 

map-class frame-relay map-class-name

Specifies a map class to define.

Step 2 

frame-relay traffic-rate average [peak]

Defines the traffic rate for the map class.

Step 3 

frame-relay custom-queue-list list-number

Specifies a custom queue list.

Step 4 

frame-relay priority-group list-number

Specifies a priority queue list.

Step 5 

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 "Backward Compatibility Example" section 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.

Customizing Frame Relay for Your Network

Perform the tasks in the following sections to customize Frame Relay:

Configuring Frame Relay End-to-End Keepalives

Configuring PPP over Frame Relay

Configuring Frame Relay Subinterfaces

Configuring Frame Relay Switching

Disabling or Reenabling Frame Relay Inverse ARP (multipoint communication only)

Creating a Broadcast Queue for an Interface

Configuring Payload Compression

Configuring Standard-Based FRF.9 Compression

Configuring TCP/IP Header Compression

Configuring Real-Time Header Compression with Frame Relay Encapsulation

Configuring Discard Eligibility

Configuring DLCI Priority Levels

Configuring Frame Relay End-to-End Keepalives

Frame Relay end-to-end keepalives enable monitoring of PVC status for network monitoring or backup applications and are configurable on a per-PVC basis with configurable timers. The Frame Relay switch within the local PVC segment deduces the status of the remote PVC segment through a Network-to-Network interface (NNI) and reports the status to the local router. If LMI support within the switch is not end-to-end, end-to-end keepalives are the only source of information about the remote router. End-to-end keepalives verify that data is getting through to a remote device via end-to-end communication.

Each PVC connecting two end devices needs two separate keepalive systems, because the upstream path may not be the same as the downstream path. One system sends out requests and handles responses to those requests—the send side—while the other system handles and replies to requests from the device at the other end of the PVC—the receive side. The send side on one device communicates with the receive side on the other device, and vice versa.

The send side sends out a keepalive request and waits for a reply to its request. If a reply is received before the timer expires, a send side, Frame Relay end-to-end keepalives is recorded. If no reply is received before the timer expires, an error event is recorded. A number of the most recently recorded events are examined. If enough error events are accumulated, the keepalive status of the VC is changed from up to down, or if enough consecutive successful replies are received, the keepalive status of the VC will be changed from down to up. The number of events that will be examined is called the event window.

The receive side is similar to the send side. The receive side waits for requests and sends out replies to those requests. If a request is received before the timer expires, a success event is recorded. If a request is not received, an error event is recorded. If enough error events occur in the event window, the PVC state will be changed from up to down. If enough consecutive success events occur, the state will be changed from down to up.

End-to-end keepalives can be configured in one of four modes: bidirectional, request, reply, or passive-reply.

In bidirectional mode, both the send side and receive side are enabled. The device's send side sends out and waits for replies to keepalive requests from the receive side of the other PVC device. The device's receive side waits for and replies to keepalive requests from the send side of the other PVC device.

In request mode, only the send side is enabled, and the device sends out and waits for replies to its keepalive requests.

In reply mode, only the receive side is enabled, and the device waits for and replies to keepalive requests.

In passive-reply mode, the device only responds to keepalive requests, but does not set any timers or keep track of any events.

Because end-to-end keepalives allow traffic flow in both directions, they can be used to carry control and configuration information from end-to-end. Consistency of information between end hosts is critical in applications such as those relating to prioritized traffic and Voice Over Frame Relay. While SVCs can convey such information within end-to-end signaling messages, PVCs will benefit from a bidirectional communication mechanism.

End-to-end keepalives are derived from the Frame Relay LMI protocol and work between peer Cisco communications devices. The key difference is that rather than run over the signaling channel, as is the case with LMI, end-to-end keepalives run over individual data channels.

Encapsulation of keepalive packets is proprietary; therefore, the feature is available only on Cisco devices running a software release that supports the Frame Relay End-to-End Keepalive feature.

You must configure both ends of a VC to send keepalives. If one end is configured as bidirectional, the other end must also be configured as bidirectional. If one end is configured as request, the other end must be configured as reply or passive-reply. If one end is configured as reply or passive-reply, the other end must be configured as request

To configure Frame Relay end-to-end keepalives, use the following commands beginning in global configuration mode:

 
Command
Purpose

Step 1 

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

Specifies a map class for the VC.

Step 2 

Router(config-map-class)# frame-relay end-to-end keepalive mode {bidirectional | request | reply | passive-reply}

Specifies Frame Relay end-to-end keepalive mode.

The four modes determine the type of keepalive traffic each device sends and responds to:

In bidirectional mode, the device will send keepalive requests to the other end of the VC and will respond to keepalive requests from the other end of the VC.

In request mode, the device will send keepalive requests to the other end of the VC.

In reply mode, the device will respond to keepalive requests from the other end of the VC.

In passive-reply mode, the device will respond to keepalive requests from the other end of the VC, but will not track errors or successes.

For an example of configuring bidirectional or request modes with default values, see the sections "End-to-End Keepalive Bidirectional Mode with Default Configuration Example" or "End-to-End Keepalive Request Mode with Default Configuration Example," and for an example of configuring request mode with modified values, see the section "End-to-End Keepalive Request Mode with Modified Configuration Example" later in this chapter.

You can modify the end-to-end keepalives default parameter values by using any of the following map-class configuration commands:

Command
Purpose

Router(config-map-class)# frame-relay end-to-end keepalive error-threshold {send | receive} count

Modifies the number of errors needed to change the keepalive state from up to down.

Router(config-map-class)# frame-relay end-to-end keepalive event-window {send | receive} count

Modifies the number of recent events to check for errors.

Router(config-map-class)# frame-relay end-to-end keepalive success-events {send | receive} count

Modifies the number of consecutive success events required to change the keepalive state from down to up.

Router(config-map-class)# frame-relay end-to-end keepalive timer {send | receive} interval

Modifies the timer interval.


Verifying Frame Relay End-to-End Keepalives

To monitor the status of Frame Relay end-to-end keepalives, use the following command in EXEC configuration mode:

Command
Purpose

Router# show frame-relay end-to-end keepalive interface

Shows the status of Frame Relay end-to-end keepalives.


Configuring PPP over Frame Relay

Point-to-point protocol (PPP) over Frame Relay allows a router to establish end-to-end PPP sessions over Frame Relay. This is done over a PVC, which is the only circuit currently supported. The PPP session does not occur unless the associated Frame Relay PVC is in an "active" state. The Frame Relay PVC can coexist with other circuits using different Frame Relay encapsulation methods, such as RFC 1490 and the Cisco proprietary method, over the same Frame Relay link. There can be multiple PPP over Frame Relay circuits on one Frame Relay link.

One PPP connection resides on one virtual access interface. This is internally created from a virtual template interface, which contains all necessary PPP and network protocol information and is shared by multiple virtual access interfaces. The virtual access interface is coexistent with the creation of the Frame Relay circuit when the corresponding DLCI is configured. Hardware compression and fancy queueing algorithms, such as weighted fair queueing, custom queueing, and priority queueing, are not applied to virtual access interfaces.

PPP over Frame Relay is only supported on IP. IP datagrams are transported over the PPP link using RFC 1973 compliant Frame Relay framing. The frame format is shown in Figure 14.

Figure 14 PPP over Frame Relay Frame Format

Table 6 lists the Frame Relay frame format components illustrated in Figure 14.

Table 6 PPP Frame Relay Frame Format Descriptions 

Field
Description

Flag

A single byte that indicates the beginning or end of a frame.

Address

A two-byte field that indicates the logical connection that maps to the physical channel; the DLCI.

Control

A single byte that calls for transmission of user data. PPP over Frame Relay uses a value of 0X03, which indicates the frame is an unnumbered information (UI) frame.

NLPID

Network layer protocol ID—a single byte that uniquely identifies a PPP packet to Frame Relay.

PPP protocol

Identifies the PPP packet type.


Figure 15 shows remote users running PPP to access their Frame Relay corporate networks.

Figure 15 PPP over Frame Relay Scenario