Frame Relay

Frame Relay is a standardized WAN technology that specifies the physical and logical link layers of digital telecommunication channels using packet switching methods. The designers of Frame Relay aimed at telecommunication service for cost-efficient data transmission for intermittent traffic between LANs and between end-points in a WAN.Frame Relay puts data in variable-size units called “frames” and leaves any necessary error-correction (such as re-transmission of data) up to the end-points. This method will speed up the overall data been transmitted. For most services, the network provides a permanent virtual circuit (PVC), which means that the customer sees a continuous, dedicated connection without having to pay for a full-time leased line, while the service-provider figures out the route each frame travels to its destination and can charge based on usage.

The nature of frame relay is that your connection is normally shared with other companies, which brings down the cost.Your frame relay service provider guarantees you a minimum amount of bandwidth. If the line is quiet, you may be able to use bandwidth belonging to other users, providing they are not using it.

There are two types of Frame Rely encapsulation;

  • Cisco-this is to be used when connecting to other Cisco devices, this is the default on Cisco devices.
  • IETF-this is to be used when connecting to non-Cisco devices.

To configure what encapsulation you want to have on your interface, use the following commands;

Router(config-if)#encapsulation frame-relay ?
ietf  Use RFC1490/RFC2427 encapsulation

Set the encapsulation for a single VC,

Router(config-if)#frame-relay map ip 102 ?
cisco                Use CISCO Encapsulation
ietf                 Use RFC1490/RFC2427 Encapsulation

Frame Relay Data Link Connection Identifiers

DLCIs are used in frame relay networks for addressing between the DTE and the DCE device belonging to the frame relay provider. Your router at one end of the connection could have a different DLCI from the router at the other end. They are only significant to your local connection to the frame relay switch belonging to the provider. The DLCI value for a frame may change as the frame passes through the network.


You have two choices for using a DLCI with an IP address, dynamically or statically. With dynamic mapping, frame relay uses ARP to get the remote interfaces IP address and then maps this to the DLCI used to connect to the local frame relay switch. Frame relay ARP is normally referred to as Inverse ARP. Static mapping means you have to configure the IP details yourself. Frame relay inverse ARP is a mechanism that allows the remote layer 3 addresses to be associated with the local layer 2 DLCI. When the frame relay circuit is initialized, the  interface sends an inverse ARP request out on each local DLCI defined. The remote router replies to the request with its IP address.

Local Management Interface

LMI is a standard used for signaling between the DTE and the frame relay switch. The connection is continually monitored in the same fashion that a keepalive is used on serial or Ethernet connections. A Frame Relay DTE can send an LMI Status Enquiry message to the switch; the switch then replies with an LMI Status message to inform the router about the DLCIs of the defined VCs, as well as the status of each VC. By default, the LMI messages flow every 10 seconds. Every sixth message carries a full Status message, which includes more complete status information about each VC.You can enable LMI on the interface and change the keep alive timers by applying the following commands;

Router(config-if)#keepalive ?
<0-32767>  Keepalive period (default 10 seconds)

There are three types of LMI connection type to choose from, Cisco, ANSI & ITU (Q.933). Various vendors and standards organizations worked independently to develop Frame Relay standards. The three differ in the following;

  • The allowed DLCI values
  • The DLCI used for sending LMI messages

When working on Cisco routers these issues are not seen all to often. A Cisco router will autosense the LMI type by default. It will do this by sending out a LMI frame containing a Cisco LMI, if it does not get a reply back it will try sending a ANSI LMI frame, once again if it does not get a reply frame back it moves onto the next LMI type which is Q933a. But if you need to configure the LMI to the interface apply the following command;

Router(config-if)#frame-relay lmi-type ?

Frame Relay LMI Types

LMI Type Source Doc Cisco IOS lmi-type
Allowed DLCI Range LMI DLCI
Cisco Proprietary cisco 16 – 1007 (992) 1023
ANSI T1.617 Annex D ansi 16 – 991 (976) 0
ITU Q.933 Annex A q933a 16 – 991 (976) 0

LMI exchange between the router and the frame relay switch can be monitored with the debug frame-rely lmi command.

Frame Relay Headers and Encapsulation

Routers create Frame Relay frames by using different consecutive headers. The first header is the ITU Link Access Procedure for Frame-Mode Bearer Services (LAPF) header. The LAPF  header includes all the fields used by Frame Relay switches to deliver frames across the FR cloud, including the DLCI, DE, BECN, and FECN fields. The Frame Relay encapsulation header follows the LAPF header, holding fields that are important only to the DTEs on the ends of a VC.

There are two encapsulation headers that exist;

  1. Cisco-proprietary header
  2. The IETF-defined RFC 2427 encapsulation header

When using just Cisco device at each end of the VC you would use the Cisco option. But when using mult-vendor device you will need to us IETF.

Each VC uses the Cisco encapsulation header unless configured explicitly to use the IETF
header. Three methods can be used to configure a VC to use the IETF-style header;

  • Subinterface command
    Router(config-if)#encapsulation frame-relay ietf
  • Subinterface command
    Router(config-if)#frame-relay interface-dlci 102 ietf
  • Interface command
    Router(config-if)#frame-relay map dlci 102 ietf

Frame Relay Congestion: DE, BECN, and FECN

Frame Relay networks can run into congestion issues caused by speed mismatches. Frame Relay provides two methods of reacting to the inevitable congestion, BECN and FECN.

To react to congestion that occurs somewhere inside the FR cloud, the router must receive some form of notice that the congestion is occurring. So, the FR LAPF header includes the Forward Explicit Congestion Notification (FECN) and Backward Explicit Congestion Notification (BECN) bits for signaling congestion on a particular VC.

When the DTE device sends frames onto the network, if the DCE end detects congestion on the network it sets the FECN bit value to 1. The receiving DTE device, upon receiving the frame, can then see that the packets received from the sending device experienced congestion on the path there. DCE devices will set the BECN bit to 1 for returning frames that have had their FECN bit set. This will inform the original sender that congestion was experienced on the path between the devices.

FECN can be set by the FR switches, but not by any of the routers, because the routers do not need to signal forward congestion. BECN can be set by switches and by a router. a switch  setting BECN on the next user frame. It can also send a Q.922 test frame, removing the need to wait on traffic sent over the VC, setting BECN in that frame. Finally, routers can be configured to watch for received frames with FECN set, reacting by returning a Q.922 test frame over that VC with the BECN bit set. This feature, sometimes called FECN reflection can be configured with the following interface commands;

Router(config-if)#traffic-shape fecn-adapt

The following command is a good command to see if you are seen any FECN or BECN;

Router#show frame-relay pvc

PVC Statistics for interface Serial0/0 (Frame Relay DTE)

Active     Inactive      Deleted       Static
Local          3            0            0            0
Switched       0            0            0            0
Unused         2            0            0            0


input pkts 13613         output pkts 13651        in bytes 491945
out bytes 448284         dropped pkts 0           in pkts dropped 0
out pkts dropped 0                out bytes dropped 0
in FECN pkts 0           in BECN pkts 0           out FECN pkts 0
out BECN pkts 0          in DE pkts 0             out DE pkts 0
out bcast pkts 1061      out bcast bytes 359669
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
pvc create time 17:45:09, last time pvc status changed 17:18:59

Discard Eligibility Bit

The DE bit is marked on frames that have a lower importance than other frames. The DE bit is part of the frame relay address header. If the DE bit is set to 1, the DCE device can discard those frames as opposed to frames without the DE bit set.

Both routers and switches can set the DE bit. Typically, a router makes the decision about setting the DE bit for certain frames, because the network engineer that controls the router is much more likely to know (and care) about which traffic is more important than other traffic. Marking DE can be performed with CB Marking, using the following MQC command;

Router(config-pmap-c)#set fr-de

Bit Meaning When Set Where Set
FECN Congestion in the same direction
as this frame, going forward
By FR switches in user frames
BECN Congestion in the direction from which
the frame has come from, going backwords
By FR switches or routers in user or
Q.922 test frames
DE This frame should be discarded, when
the DE bit is set to 1
By routers or switches in user frames


Frame Relay and Split horizon

To overcome the split-horizon issue where an interface cannot advertise a route out of the same interface it was received on, you can use sub-interfaces. Split horizon is on by default for RIP and EIGRP networks and will prevent any routing updates been passed through the multipoint interfaces. To turn off split horizon for networks using RIP and EIGRP run the following interface commands;

Router(config-if)#no ip split-horizon

Router(config-if)#no ip split-horizon eigrp 10 {10 be the AS number}

Frame Relay Configuration

Two of the most important details regarding Frame Relay configuration are the association of DLCIs with the correct interface or subinterface, and the mapping of L3 addresses to those DLCIs. These can be accomplished by applying the following interface commands;

Router(config-if)#frame-relay map ip ?
<16-1007>  DLCI

Router(config-if)#frame-relay interface-dlci ?
<16-1007>  Define a switched or locally terminated DLCI

A router can learn each DLCI on the access link via LMI Status messages, these messages do not imply with which subinterface each DLCI should be used. To configure Frame Relay using subinterfaces, the DLCIs must be associated with the subinterface. Any DLCIs learned with LMI that are not associated with a subinterface are assumed to be used by the physical interface.

Frame Relay Payload Compression

Three options for payload compression on Frame Relay VCs: packet by packet, data stream, and Frame Relay Forum Implementation Agreement 9 (FRF.9). The Cisco packet-by-packet payload compression scheme for Frame Relay is a proprietary compression algorithm that does not work too well in a multivendor environment. FRF.9 is the only standardized protocol of the three options. FRF.9 compression and data-stream compression function basically the same  way; the only real difference is that FRF.9 implies compatibility with non-Cisco devices.

FRF.9 also has higher compression ratios and allows more data to be compressed for faster transmission. FRF.9 compression provides the ability to maintain multiple compression and decompression histories on a per-DLCI basis by maintaining a dictionary per DLCI. The compressed payload is transported through the Frame Relay network and decompressed at its termination point. Hence, FRF.9 is configured end-to-end.

All three FR compression options use LZS as the compression algorithm, but one key difference relates to their use of compression dictionaries. LZS defines dynamic dictionary entries that list a binary string from the compressed data, and an associated smaller string that represents it during transmission. This will reduce the number of bits needed to send the data.

The packet-by-packet compression method also uses LZS, but the compression dictionary is built for each packet, then discarded.

Feature Packet by Packet FRF.9 Data Stream
Uses LZS algorithm Yes Yes Yes
Same dictionary for all packets No Yes Yes
Cisco proprietary Yes No Yes

FR payload compression configuration is configured per VC. The configuration varies depending on whether point-to-point subinterfaces are used.

Router(config-subif)#frame-relay payload-compression ?
FRF9              FRF9 encapsulation
data-stream       cisco proprietary encapsulation
packet-by-packet  cisco proprietary encapsulation

On the interface you will need to apply the following command;

Router(config-if)#frame-relay map ip 102 payload-compression ?
FRF9              FRF9 encapsulation
data-stream       cisco proprietary encapsulation
packet-by-packet  cisco proprietary encapsulation

To view the compression from your router, run the show compress command.

Frame Relay Fragmentation

Cisco has developed three different methods of performing fragmentation with Frame Relay: FRF.12 Fragmentation, Frame Relay Fragmentation using FRF.11 Annex C, and the Cisco Proprietary Fragmentation. Each fragmentation scheme uses a different data format or encapsulation. Frame Relay frames are fragmented based on one of the three formats, depending on how the Frame Relay PVC was set up. It is important to note that when Frame Relay End-to-End FRF.12 Fragmentation is configured, Weighted Fair Queuing (WFQ) or Low Latency Queuing (LLQ) is required.

FRF.12 interleaves packets using LFI, when configured using FRF.12 configuration. IOS will create a 2-queue software queuing system on the physical interface. Any packets leaving the FRTS LLQ go into the high Dual FIFO queue, with the packets and fragments from other queuing going into the Dual FIFO normal queue. On the interface, IOS treats the Dual FIFO queue as a priority queue, which causes interleaving.

When configuring fragmentation, it needs to be configured on both ends of the VC. This can be done by applying the following commands;

Router(config-if)#frame-relay fragment ?
<16-1600>  Define fragment size, Bytes

Router(config-if)#frame-relay fragment 100 ?
end-to-end  End-to-end fragmentation (FRF.12)