Frame Relay was conceived as a protocol for use over serial interfaces and was designed for networks with large T1 installations. This chapter describes the tasks for configuring Frame Relay on the communication server. For a complete description of the commands mentioned in this chapter, refer to the "Frame Relay Commands" chapter in the Access and Communication Servers Command Reference publication. For historical background and a technical overview of Frame Relay, see the Internetworking Technology Overview publication.

Cisco's Implementation of Frame Relay

Cisco's Frame Relay implementation currently supports routing on IP and Novell IPX.

The Frame Relay software provides the following capabilities:

Support for the three generally implemented specifications of Frame Relay Local Management Interfaces (LMIs):

The Frame Relay Interface joint specification produced by Northern Telecom, Digital Equipment Corporation, StrataCom, and Cisco Systems
The ANSI-adopted Frame Relay signal specification, T1.617 Annex D
The International Telecommunication Union Telecommunication Standardization Sector (ITU-T)-adopted Frame Relay signal specification, Q.933 Annex A

Note The ITU-T carries out the functions of the former Consultative Committee for International Telegraph and Telephone (CCITT).

Conformity to ITU-T I-series (ISDN) recommendation as I122, "Framework for Additional Packet Mode Bearer Services."

The ANSI-adopted Frame Relay encapsulation specification, T1.618
The ITU-T-adopted Frame Relay encapsulation specification, Q.922 Annex A

Conformity to Internet Engineering Task Force (IETF) encapsulation in accordance with RFC 1294, except bridging.

Support for a keepalive mechanism, a multicast group, and a status message, as follows:

The keepalive mechanism provides an exchange of information between the network server and the switch to verify that data is flowing.

The multicast mechanism provides the network server with its local data link connection identifier (DLCI) and the multicast DLCI. This feature is specific to our implementation of the Frame Relay joint specification.

The status mechanism provides an ongoing status report on the DLCIs known by the switch.

Transmission of congestion information from Frame Relay to DECnet Phase IV and CLNS. This mechanism promotes F orward Explicit Congestion Notification (FECN) bits from the Frame Relay layer to upper-layer protocols after checking for the FECN bit on the incoming DLCI. Use this Frame Relay congestion information to adjust the sending rates of end hosts. FECN-bit promotion is enabled by default on any interface using Frame Relay encapsulation. No configuration is required.

Support for Frame Relay Inverse Address Resolution Protocol (Inverse ARP) as described in RFC 1293 for the IP and IPX protocols. It allows a communication server running Frame Relay to discover the protocol address of a device associated with the virtual circuit.

Support for Frame Relay switching, whereby packets are switched based on the DLCI (a Frame Relay equivalent of a MAC-level address). Communication servers are configured as a hybrid DTE switch or pure Frame Relay DCE access node in the Frame Relay network. Cisco's implementation of Frame Relay switching allows the following configurations:

Switching over an IP tunnel
Network-to-Network Interface (NNI) to other Frame Relay switches
Local serial-to-serial switching

Support for subinterfaces associated with a physical interface. The software groups one or more permanent virtual circuits under separate subinterfaces, which in turn are located under a single physical interface. See the "Configuring Interfaces" chapter in this publication for more information. See the sections "Associate a DLCI with a Subinterface" and "Frame Relay Configuration Examples" later in this chapter for more information about subinterfaces in Frame Relay configurations.
Support of the Frame Relay DTE MIB specified in RFC 1315. However, the error table is not implemented. To use the Frame-Relay MIB, refer to your MIB publications.

Frame Relay Hardware Requirements

One of the following hardware configurations is possible for Frame Relay connections:

Communication servers can connect directly to the Frame Relay switch.
Communication servers can connect directly to a Channel Service Unit/Digital Service Unit (CSU/DSU) first, and the CSU/DSU is connected to a remote Frame Relay switch.

Note A Frame Relay network is not required to support only communication servers that are connected directly or only communication servers connected via CSU/DSUs. Within a network, some communication servers can connect to a Frame Relay switch through a direct connection and others through connections via CSU/DSUs. However, a single communication server interface configured for Frame Relay can be only one or the other.

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

Figure 9-1: 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, such as a StrataCom FastPacket wide-area network.

Frame Relay Configuration Task List

There are required, basic steps you must follow to enable Frame Relay for your network. In addition, you can customize Frame Relay for your particular network needs, set local and multicast DLCIs in test environments, and monitor Frame Relay connections. To configure Frame Relay, perform the tasks in the following sections.

The following sections describe these tasks. See the section "Frame Relay Configuration Examples" at the end of this chapter for examples. Refer to the "Frame Relay Commands" chapter in the Access and Communication Servers Command Reference publication for information about the commands listed in the tasks.

Enable Frame Relay on an Interface

You must perform the tasks in the following sections to enable Frame Relay:

Set Frame Relay Encapsulation

To set Frame Relay encapsulation at the interface level, perform the following task in interface configuration mode:

Task	Command
Enable Frame Relay and specify the encapsulation method.	encapsulation frame-relay [ietf]

Frame Relay supports encapsulation of all supported protocols except bridging in conformance with RFC 1294, allowing interoperability between multiple vendors. Use the IETF form of Frame Relay encapsulation if your communication server is connected to another vendor's equipment across a Frame Relay network. IETF encapsulation is supported at either the interface level or on a per-DLCI (map entry) basis.

For an example of how to enable Frame Relay and set the encapsulation method, see the sections "IETF Encapsulation Example" and "Communication Servers in Static Mode Example" later in this chapter. Also, refer to the "Configuring Interfaces" chapter if you want to configure subinterfaces on serial interfaces running Frame Relay encapsulation.

Establish Mapping

The Frame Relay map tells the network server how to get from a specific protocol and address pair to the correct local data link connection identifier (DLCI). To establish mapping according to your network needs, perform one of the following tasks in interface configuration mode:

Task	Command
Define the mapping between a supported protocol address and the DLCI used to connect to the address.	frame-relay map protocol protocol-address dlci [broadcast] [ietf] [cisco]

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

IP—ip
Novell IPX—ipx

This command is not required if you are using Inverse ARP.

The configuration for the Open Shortest Path First (OSPF) protocol can be greatly simplified by adding the optional broadcast keyword when doing this task. See the frame-relay map description in the Access and Communication Servers Command Reference publication and the examples at the end of this chapter for more information about using the broadcast keyword.

For an example of how to establish mapping, see the sections "Communication Servers in Static Mode Example" and "IPX Packet Routing Example" later in this chapter.

Customize Your Frame Relay Network

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

Configure Frame Relay Switching

Frame Relay switching is a means of switching packets based upon the DLCI, which can be looked upon as the Frame Relay equivalent of a MAC address. The switching is performed by configuring your communication server as a Frame Relay network. There are two parts to a Frame Relay network: a Frame Relay DTE (the communication server) and a Frame Relay DCE switch.
Figure 9-2 illustrates this concept.

Figure 9-2: Frame Relay Switched Network

In Figure 9-2, the communication servers B and C are Frame Relay DTEs connected to each other via a Frame Relay network. Our implementation of Frame Relay switching allows the communication servers to be used as depicted in this Frame Relay network.

Perform these tasks, as necessary, to configure Frame Relay switching:

Enable Frame Relay switching.
Configure a Frame Relay DTE device, DCE switch, or NNI support.
Specify the static route.

These tasks are described in the following sections.

Enable Frame Relay Switching

You must enable packet switching before you can configure it on a Frame Relay DTE, DCE, or with Network-to-Network Interface (NNI) support. Do so by performing the following task in global configuration mode before configuring the switch type:

Task	Command
Enable Frame Relay switching.	frame-relay switching

For an example of how to enable Frame Relay switching, see the switching examples later in this chapter.

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

You can configure your communication server as a DTE device, DCE switch, or as a switch connected to a switch to support NNI connections. (DCE is the default.) To do so, perform the following task in interface configuration mode:

Task	Command
Configure a Frame Relay DTE device or DCE switch.	frame-relay intf-type [dce \| dte \| nni]

Use the dte keyword to configure a DTE device. DTE is the default. Use the dce keyword to configure a DCE switch. Use the nni keyword with this task to configure NNI support.

Specify the Static Route

You must specify a static route for PVC switching. To do so, perform the following task in interface configuration mode:

Task	Command
Specify the static route for PVC switching.	frame-relay route in-dlci out-interface out-dlci

For an example of how to specify a static route, see the section "Switching over an IP Tunnel Example" later in this chapter.

Configure the LMI

Our Frame Relay software supports the industry-accepted standards for addressing the Local Management Interface (LMI), including the Cisco specification. You can enable the following LMI features:

Set the LMI type.
Set the LMI keepalive interval.
Set the LMI polling and timer intervals.

Set the LMI Type

You can set one of three types of LMIs on our communication server: ANSI T1.617 Annex D, Cisco, and ITU-T Q.933 Annex A. To do so, perform the following task in interface configuration mode:

Task	Command
Set the LMI type.	frame-relay lmi-type {ansi \| cisco \| q933a}

Set the LMI Keepalive Interval

A keepalive interval must be set to enable 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, perform the following task in interface configuration mode:

Task	Command
Set the keepalive interval.	frame-relay keepalive seconds
Turn off keepalives on networks without an LMI.	no frame-relay keepalive

This command has the same effect as the keepalive interface configuration command.

The keepalive interval cannot be enabled when the LMI is disabled; they go together. For an example of how to specify an LMI keepalive interval, see the section "Communication Servers in Static Mode Example" later in this chapter.

Set the LMI Polling and Timer Intervals

You can set various counters, intervals, and thresholds to fine-tune the operation of your LMI DTE and DCE devices. See the following table for the tasks that you can perform. See the "Frame Relay Commands" chapter in the Access and Communication Servers Command Reference publication for details about commands used to set the polling and timing intervals. Set these intervals by performing one or more of the following tasks in interface configuration mode:

Task	Command
Set the DCE and NNI error threshold.	frame-relay lmi-n392dce threshold (1-10)
Set the DCE and NNI monitored events count.	frame-relay lmi-n393dce events (1-10)
Set the polling verification timer on a DCE or NNI interface.	frame-relay lmi-t392dce timer (5-30 seconds)
Set a full status polling interval on a DTE or NNI interface.	frame-relay lmi-n391dte keep-exchanges (1-255)
Set the DTE or NNI error threshold.	frame-relay lmi-n392dte threshold (1-10)
Set the DTE and NNI monitored events count.	frame-relay lmi-n393dte events (1-10)

Select Frame Relay Inverse ARP

Frame Relay Inverse ARP is a method of building dynamic routes in Frame Relay networks running IP and Novell IPX. Inverse ARP allows the communication server to discover the protocol address of a device associated with the virtual circuit. Inverse ARP is used instead of the frame-relay map command, which allows you to define the mappings between a specific protocol and address and a specific DLCI (see the section "Establish Mapping" earlier in this chapter for more information).

Inverse ARP is enabled by default. Configure Inverse ARP if you want to configure an interface for multipoint communication that was previously configured for point-to-point. You would not need to select Inverse ARP if you have a point-to-point interface, because there is only a single destination and discovery is not required.

To select Inverse ARP, perform the following task in interface configuration mode:

Task	Command
Select Frame Relay Inverse ARP.	frame-relay inverse-arp protocol dlci

Define Subinterfaces

Subinterfaces solve many of the problems seen in protocols that have split horizon enabled and no capability to disable it. However, not all protocols support subinterfaces. Refer to the chapter "Configuring Interfaces" earlier in this publication for a list of protocols that support subinterfaces. For more information about split horizon, refer to the chapter "Configuring Frame Relay" later in this publication.

You can configure subinterfaces for multipoint or point-to-point communication. Multipoint is the default. To configure an interface for multipoint or point-to-point communication, you must first define an interface in global configuration mode. After defining an interface, you can define a subinterface for that interface by performing the following task in interface configuration mode:

Task	Command
Define a subinterface.	interface type number.subinterface-number [multipoint \| point-to-point]¹

¹This command is documented in the "Interface Configuration Commands" chapter in the Access and Communication Servers Command Reference publication.

Once you have defined the subinterface, you must perform one of the following tasks in interface configuration mode:

Establish mapping.
Select Frame Relay Inverse ARP.
Associate a DLCI with a subinterface.

If you define a subinterface for multipoint communication, you cannot use the frame-relay interface-dlci command. If you define a subinterface for point-to-point communication, you cannot use the frame-relay map command. The frame-relay inverse-arp command is designed for use with an interface configured for multipoint communication and should not be used for a subinterface configured for point-to-point communication.

Note If you define a subinterface for point-to-point communication, you cannot reassign the same subinterface number to be used for multipoint communication without first rebooting the communication server.

Associate a DLCI with a Subinterface

You must associate the Frame Relay DLCI with a subinterface to use subinterfaces in the Frame Relay network for point-to-point communication. If you associate a DLCI with a point-to-point subinterface, you cannot use the frame-relay map command.

To associate a DLCI with a subinterface, perform the following task in interface configuration mode:

Task	Command
Associate a DLCI with a subinterface.	frame-relay interface-dlci dlci [option]

Configure a Backup Interface for a Subinterface

Both point-to-point and multipoint Frame Relay subinterfaces can be configured with a backup interface. This allows individual PVCs to be backed up in case of failure rather than depending on the entire Frame Relay connection to fail before the backup takes over. You can configure a subinterface for backup on failure only, not for backup based on loading of the line.

If the serial interface has a backup interface, it will have precedence over the subinterface's backup interface in the case of complete loss of connectivity with the Frame Relay network. As a result, a subinterface backup is activated only if the serial interface is up, or if the serial interface is down and does not have a backup interface defined. If a subinterface has failed while its backup is in use, and then the serial interface goes down, the subinterface backup stays connected.

To configure a backup interface for a Frame Relay subinterface, perform the following tasks, beginning in global configuration mode:

Task	Command
Step 1. Specify the interface.	interface serial number
Step 2. Configure Frame Relay encapsulation.	encapsulation frame-relay
Step 3. Configure the subinterface.	interface serial number.subinterface-number point-to-point
Step 4. Specify a DLCI for the subinterface.	frame-relay interface-dlci dlci
Step 5. Specify a backup interface for the subinterface.	backup interface serial number^1.
Step 6. Specify backup enable and disable delay.	backup delay enable-delay disable-delay^1.

Create a Broadcast Queue for an Interface

Very large Frame Relay networks might have problems when very many DLCIs terminate in a single communication server and the communication server must replicate routing updates and service advertising updates on each DLCI. The updates can consume access-link bandwidth and cause significant latency variations in user traffic; the updates can also consume interface buffers and lead to higher packet rate loss for both user data and routing updates.

To avoid such problems, you can create a special broadcast queue for an interface. The broadcast queue is managed independently of the normal interface queue, has its own buffers, and has a configurable size and service rate.

A broadcast queue is given a maximum transmission rate (throughput) limit measured in both bytes per second and packets per second. The queue is serviced to ensure that only this maximum is provided. The broadcast queue has priority when transmitting at a rate below the configured maximum, and hence has a guaranteed minimum bandwidth allocation. The two transmission rate limits are intended to avoid flooding the interface with broadcasts. The actual transmission rate limit in any second is the first of the two rate limits that is reached.

To create a broadcast queue, complete the following task in interface configuration mode:

Task	Command
Create a broadcast queue for an interface.	frame-relay broadcast-queue size byte-rate packet-rate

Configure TCP/IP Header Compression

TCP/IP header compression, as described by RFC 1144, is designed to improve the efficiency of bandwidth utilization over low-speed serial links . A typical TCP/IP packet includes a 40-byte datagram header. Once a connection is established, the header information is redundant and need not be repeated in every packet that is sent. By reconstructing a smaller header that identifies the connection and indicates the fields that changed and the amount of change, fewer bytes can be transmitted. The average compressed header is 10 bytes long.

You can configure TCP/IP header compression in either of two ways, as described in the following sections:

You can also turn off the header compression as described in "Turn Off TCP/IP Header Compression" later in this chapter.

Note If you configure an interface with Cisco encapsulation and TCP/IP header compression, Frame Relay IP maps inherit the compression characteristics of the interface. However, if you configure the interface with IETF encapsulation, the interface cannot be configured for compression. Frame Relay maps will have to be configured individually to support TCP/IP header compression.

Configure an Individual IP Map for TCP/IP Header Compression

TCP header compression requires Cisco encapsulation. If you need to have IETF encapsulation on an interface as a whole, you can still configure a specific IP map to use Cisco encapsulation and TCP header compression.

In addition, even if you configure the interface to perform TCP/IP header compression, you can still configure a specific IP map not to compress TCP/IP headers.

You can specify whether TCP/IP header compression is active or passive. Active compression subjects every outgoing packet to TC/IP header compression. Passive compression subjects an outgoing TCP/IP packet to header compression only if the packet had a compressed TCP/IP header when it was received.

To configure an IP map to use Cisco encapsulation and TCP/IP header compression, perform the following task in interface configuration mode:

Task	Command
Configure an IP map to use Cisco encapsulation and TCP/IP header compression.	frame-relay map ip ip-address dlci [broadcast] [cisco \| ietf] [nocompress] tcp header-compression {active \| passive}

The default encapsulation is cisco.

Note An interface that is configured to support TCP/IP header compression cannot also support priority queueing or custom queueing.

For an example of how to configure TCP header compression on an IP map, see the "Frame Relay Configuration Examples" section later in this chapter.

Configure an Interface for TCP/IP Header Compression

You can configure the interface with active or passive TCP/IP header compression. Active compression, the default, subjects all outgoing TCP/IP packets to header compression. Passive compression subjects an outgoing packet to header compression only if the packet had a compressed TCP/IP header when it was received on that interface.

To apply TCP/IP header compression to an interface, you must perform the following tasks in interface configuration mode:

Task	Command
Configure Cisco encapsulation on the interface.	encapsulation frame-relay cisco
Enable TCP/IP header compression on the interface.	frame-relay ip tcp header-compression [passive]

Note If an interface configured with Cisco encapsulation is later configured with IETF encapsulation, all TCP/IP header compression characteristics are lost. To apply TCP/IP header compression over an interface configured with IETF encapsulation, you must configure individual IP maps, as described in the section "Configure an Individual IP Map for TCP/IP Header Compression."

For an example of how to configure TCP header compression on an interface, see the "TCP Header Compression Examples" section later in this chapter.

Turn Off TCP/IP Header Compression

You can turn off TCP/IP header compression by using either of two commands that have different effects, depending on whether Frame Relay IP maps have been explicitly configured for TCP/IP header compression or have inherited their compression characteristics from the interface.

Frame Relay IP maps that have explicitly configured TCP/IP header compression must also have TCP/IP header compression explicitly turned off.

To turn off TCP/IP header compression, perform one of the following tasks in interface configuration mode:

Task	Command
Turn off TCP header compression on all Frame Relay IP maps that are not explicitly configured for TCP header compression. or Turn off TCP header compression on a specified Frame Relay IP map.	no frame-relay ip tcp header-compression frame-relay map ip ip-address dlci nocompress

Task

Command

Turn off TCP header compression on all Frame Relay IP maps that are not explicitly configured for TCP header compression.

Turn off TCP header compression on a specified Frame Relay IP map.

no frame-relay ip tcp header-compression

frame-relay map ip ip-address dlci nocompress

For an example of how to turn off TCP header compression, see the section "Turning Off TCP/IP Header Compression Examples."

Configure Discard Eligibility

You can specify the discard eligibility of Frame Relay packets; that is, which packets have low priority or low time sensitivity and will be the first to be dropped when a Frame Relay switch is congested. The mechanism that allows a Frame Relay switch to identify such packets is the discard eligibility (DE) bit.

This feature requires that the Frame Relay network be able to interpret the DE bit. Some networks take no action when the DE bit is set. Other networks use the DE bit to determine which packets to discard. The most desirable interpretation is to use the DE bit to determine which packets should be dropped first and also which packets have lower time sensitivity.

You can define DE lists that identify the characteristics of packets to be eligible for discarding, and you can also specify DE groups to identify the DLCI that is affected.

To define a DE list specifying the packets that can be dropped when the Frame Relay switch is congested, perform the following task in global configuration mode:

Task	Command
Define a DE list.	frame-relay de-list list-number protocol {protocol \| type number} characteristic

You can specify DE lists based on the protocol or the interface, and on characteristics such as fragmentation of the packet, a specific TCP or UDP port, an access list number, or packet size. See the frame-relay de-list command in the Access and Communication Servers Command Reference for arguments and other information.

To define a DE group specifying the DE list and DLCI affected, perform the following task in interface configuration mode:

Task	Command
Define a DE group.	frame-relay de-group group-number dlci

Configure Frame Relay in a Test Environment

Perform the following tasks only if you are configuring Frame Relay in a test environment:

Set the Local DLCI

You can set a local DLCI in a test environment. This feature is provided mainly to allow testing of the Frame Relay encapsulation in a setting where two communication servers are connected back to back. This command is not required in a live Frame Relay network. Its use allows the source local DLCI to be set for use when the LMI is not supported. To set the local DLCI, perform the following task in interface configuration mode:

Task	Command
Set a local DLCI.	frame-relay local-dlci number

If LMI is supported and the multicast information element is present, the network server sets its local DLCI based on information provided via the LMI.

Set the DLCI for Multicasts

You can specify a DLCI for multicasts in a test environment. This feature is provided mainly to allow testing of the Frame Relay encapsulation in a setting where two communication servers are connected back to back. This task is not required in a live Frame Relay network. Its use allows network transmissions (packets) sent to a multicast DLCI to be delivered to all network servers defined as members of the multicast group. To set the DLCI for multicasts, perform the following task in interface configuration mode:

Task	Command
Specify a DLCI for multicasts in a test environment.	frame-relay multicast-dlci number

Monitor and Maintain the Frame Relay Connections

To monitor and maintain Frame Relay connections, perform any of the following tasks in EXEC mode:

Task	Command
Clear dynamically created Frame Relay maps, which are created by the use of Inverse ARP.	clear frame-relay-inarp
Display information about the Frame Relay DLCI and the LMI.	show interfaces serial number
Display LMI statistics.	show frame-relay lmi [interface]
Display the current Frame Relay map entries.	show frame-relay map
Display PVC statistics.	show frame-relay pvc [interface [dlci]]
Display configured static routes.	show frame-relay route
Display Frame Relay traffic statistics.	show frame-relay traffic

Frame Relay Configuration Examples

This section provides examples of Frame Relay configurations. It includes the following examples:

IETF Encapsulation Example

The first example that follows sets IETF encapsulation at the interface level. The second example sets IETF encapsulation on a per-DLCI basis. In the first example, the keyword ietf sets the default encapsulation method for all maps to IETF.

encapsulation frame-relay IETF

frame-relay map ip 131.108.123.2 48 broadcast

frame-relay map ip 131.108.123.3 49 broadcast

In the following example, IETF encapsulation is configured on a per-DLCI basis. This configuration has the same result as the configuration in the first example.

encapsulation frame-relay 
frame-relay map ip 131.108.123.2 48 broadcast ietf
frame-relay map ip 131.108.123.3 49 broadcast ietf

Communication Servers in Static Mode Example

The following examples illustrate how to configure two communication servers for static mode.

Configuration for Communication Server 1

interface  serial 0
!
ip address  131.108.64.2 255.255.255.0
encapsulation  frame-relay
keepalive 10
frame-relay map ip  131.108.64.1 43

Configuration for Communication Server 2

interface serial 0
!
ip address 131.108.64.1 255.255.255.0
encapsulation  frame-relay
keepalive 10
frame-relay map ip  131.108.64.2 44

IPX Packet Routing Example

The following example illustrates how to send packets destined for IPX address 200.0000.0c00.7b21 out on DLCI 102:

interface ethernet 0
ipx network 2abc
!
interface serial 0
ipx network 200
encapsulation frame-relay
frame-relay map ipx 200.0000.0c00.7b21 102 broadcast

Backward Compatibility Example

The following configuration provides backward compatibility and interoperability. Creating this configuration is possible because of the flexibility provided by separately defining each map entry.

encapsulation frame-relay
frame-relay map ip 131.108.123.2 48 broadcast ietf
! interoperability is provided by IETF encapsulation
frame-relay map ip 131.108.123.3 49 broadcast ietf
frame-relay map ip 131.108.123.7 58 broadcast 
! this line allows the communication server to connect with a 

! device running an older version of software
frame-relay map DECNET 21.7 49 broadcast

Configure IETF based on map entries and protocol for more flexibility. Use this method of configuration for backward compatibility and interoperability.

Booting from a Network Server over Frame Relay Example

When booting from a network server (netbooting) over Frame Relay, you cannot netboot via a broadcast. You must netboot from a specific host. Also, a frame-relay map command must exist for the host providing the netboot.

For example, if file gs3-bfx is to be booted from a host with IP address 131.108.126.2, the following commands would need to be in the configuration:

boot system gs3-bfx 131.108.126.2
 
interface Serial 0
encapsulation frame-relay
frame-relay map IP 131.108.126.2 100 broadcast

The frame-relay map command is used to map an IP address into a DLCI address. In order to netboot over Frame Relay, the address of the machine providing the netboot must be given explicitly, and a frame-relay map entry must exist for that site. For example:

boot system gs3-bfx.83-2.0 131.108.13.111
!
interface Serial 1
ip address 131.108.126.200 255.255.255.0
encapsulation frame-relay
!
frame-relay map IP 131.108.126.111 100 broadcast

In this case, 100 is the DLCI of the remote communication server that can get to host 131.108.126.111.

The remote communication server must have the following frame-relay map entry:

frame-relay map IP 131.108.126.200 101 broadcast

This entry allows the remote communication server to return a boot image (from the netboot host) to the communication server netbooting over Frame Relay. Here, 101 is the DLCI of the communication server being netbooted.

Switching over an IP Tunnel Example

Switching over an IP tunnel is done by creating a point-to-point tunnel across the internetwork over which PVC switching can take place (see Figure 9-3).

Figure 9-3: Frame Relay Switch over IP Tunnel

The following configurations illustrate how to create the IP network depicted in Figure 9-3.

Configuration for Router A

frame-relay switching
!
interface Ethernet0
ip address 108.131.123.231 255.255.255.0
!
interface Serial0
no ip address
shutdown
ip address 131.108.222.231 255.255.255.0
encapsulation frame-relay
frame-relay map ip 131.108.222.4 400 broadcast
frame-relay route 100 interface Tunnel1 200
!
interface Tunnel1
tunnel source Ethernet0
tunnel destination 150.150.150.123

Configuration for the Communication Server

frame-relay switching
!
interface Async0
ip address 131.108.231.123 255.255.255.0
encapsulation ppp
!
interface Serial0
ip address 150.150.150.123 255.255.255.0
encapsulation ppp
!
interface Tunnel1
tunnel source Async0
tunnel destination 108.131.123.231
!
interface Serial1
ip address 131.108.7.123 255.255.255.0
encapsulation frame-relay
frame-relay intf-type dce
frame-relay route 300 interface Tunnel1 200

TCP Header Compression Examples

These examples show various combinations of TCP/IP header compression and encapsulation characteristics on the interface and the effect on the inheritance of those characteristics on a Frame Relay IP map.

IP Map with Inherited TCP/IP Header Compression Example

The following example shows an interface configured for TCP/IP header compression and an IP map that inherits the compression characteristics. Note that the Frame Relay IP map is not explicitly configured for header compression.

interface serial 1
encapsulation frame-relay
ip address 131.108.177.178 255.255.255.0
frame-relay map ip 131.108.177.177 177 broadcast
frame-relay ip tcp header-compression passive

Use of the show frame-relay map command will display the resulting compression and encapsulation characteristics; the IP map has inherited passive TCP/IP header compression:

cs> show frame-relay map
Serial 1   (administratively down): ip 131.108.177.177
           dlci 177 (0xB1,0x2C10), static,
           broadcast, 
           CISCO
           TCP/IP Header Compression (inherited), passive (inherited)

Using an IP Map Not to Support TCP/IP Compression Example

The following example shows the use of a Frame Relay IP map to override the compression set on the interface:

interface serial 1
encapsulation frame-relay
ip address 131.108.177.178 255.255.255.0
frame-relay map ip 131.108.177.177 177 broadcast nocompress
frame-relay ip tcp header-compression passive

Use of the show frame-relay map command will display the resulting compression and encapsulation characteristics; the IP map has not inherited TCP header compression:

Serial 1   (administratively down): ip 131.108.177.177
           dlci 177 (0xB1,0x2C10), static,
           broadcast, 
           CISCO

Turning Off TCP/IP Header Compression Examples

The following examples show the use of two different commands to turn off TCP/IP header compression.

Turning Off Inherited TCP/IP Header Compression Example

In the first example, the initial configuration is the following:

interface serial 1
encapsulation frame-relay
ip address 131.108.177.179 255.255.255.0
frame-relay ip tcp header-compression passive
frame-relay map ip 131.108.177.177 177 broadcast
frame-relay map ip 131.108.177.178 178 broadcast tcp header-compression

You enter the following commands interactively:

serial interface 1
no frame-relay ip tcp header-compression

As a result, header compression is turned off for the first map (with DLCI 177), which inherited its header compression characteristics from the interface, but not turned off for the second map (DLCI 178), which is explicitly configured for header compression.

Turning Off Explicit TCP/IP Header Compression Example

In the second example, the initial configuration is the same, but you enter the following commands interactively:

serial interface 1
no frame-relay ip tcp header-compression
frame-relay map ip 131.108.177.178 178 nocompress

The result of the interactive commands is to turn off header compression for the first map (with DLCI 177), which inherited its header compression characteristics from the interface, and also explicitly to turn off header compression for the second map (with DLCI 178), which had been explicitly configured for header compression.

Table of Contents

Configuration for Communication Server 1

Configuration for Communication Server 2

Configuration for Router A

Configuration for the Communication Server