Frame Relay Tutorial

Note: Frame Relay is no longer a topic in CCNAv3 200-125 exam.

Let’s start this article with the question: Why do we need Frame Relay?

Let’s take a simple example. Suppose you are working in a big company and your company has
just expanded to two new locations. The main site is connected to two branch offices, named
Branch 1 & Branch 2 and your boss wants these two branches can communicate with the main site.
The most simple solution is to connect them directly (called a leased line) as shown below:

To connect to these two branches, the main site router, HeadQuarter, requires two serial interfaces
which a router can provide. But what happens when the company expands to 10 branches, 50
branches? For each point-to-point line, HeadQuarter needs a separate physical serial interface (and
maybe a separate CSU/DSU if it is not integrated into the WAN card). As you can imagine, it will
need many routers with many interfaces and lots of rack space for the routers and CSU/DSUs.
Maybe we should use another solution for this problem? Luckily, Frame Relay can do it!

By using Frame Relay we only need one serial interface at the HeadQuarter to connect to all
branches. This is also true when we expand to 10 or 50 branches. Moreover, the cost is much
lesser than using leased-lines.

Frame Relay is a high-performance WAN protocol that operates at the physical and data link layers
of the OSI reference model. It offers lower-cost data transfer when compared to typical point-to-
point applications, by using virtual connections within the frame relay network and by combining
those connections into a single physical connection at each location. Frame relay providers use a
frame relay switch to route the data on each virtual circuit to the appropriate destination.

Maybe these terminologies of Frame Relay are difficult to understand so we will explain them in
more detail in this article.

DCE & DTE

The first concept in Frame Relay you must grasp is about DTE & DCE:

+ Data terminal equipment (DTE), which is actually the user device and the logical Frame-relay
end-system
+ Data communication equipment (DCE, also called data circuit-terminating equipment), which
consists of modem and packet switch

In general, the routers are considered DTE, and the Frame Relay switches are DCE. The purpose of
DCE equipment is to provide clocking and switching services in a network. In our example,
HeadQuarter, Branch 1 & Branch 2 are DTEs while Frame Relay switches are DCEs.
Virtual Circuits

The logical connection through the Frame Relay network between two DTEs is called a virtual
circuit (VC). The term “virtual” here means that the two DTEs are not connected directly but
through a network. For example, the HeadQuarter & Branch 1 (or Branch 2) can communicate with
each other as if they were directly connected but in fact they are connected through a Frame Relay
network with many Frame Relay switches between them.

There are two types of VCs

+ switched virtual circuits (SVCs): are temporary connections that are only used when there is
sporadic data transfer between DTE devices across the Frame Relay network. SVC is set up
dynamically when needed. SVC connections require call setup and termination for each connection.
+ permanent virtual circuits (PVCs): A predefined VC. A PVC can be equated to a leased line in
concept.

Nowadays most service providers offer PVC service only to save additional costs for signaling and
billing procedures.

In this part we will continue to discuss about other important Frame Relay parameters

DLCI

Although the above picture shows two VCs from the HeadQuarter but do you remember that the
HeadQuarter only has only one serial interface? So how can it know which branch it should send
the frame to?

Frame-relay uses data-link connection identifiers (DLCIs) to build up logical circuits. The identifiers
have local meaning only, that means that their values are unique per router, but not necessarily in
the other routers. For example, there is only one DLCI of 23 representing for the connection from
HeadQuarter to Branch 1 and only one DLCI of 51 from HeadQuarter to Branch 2. Branch 1 can use
the same DLCI of 23 to represent the connection from it to HeadQuarter. Of course it can use other
DLCIs as well because DLCIs are just local significant.

By including a DLCI number in the Frame Relay header, HeadQuarter can communicate with both
Branch 1 and Branch 2 over the same physical circuit.

DLCI values typically are assigned by the Frame Relay service provider (for example, the telephone
company). In Frame Relay, DLCI is a 10-bit field.

Before DLCI can be used to route traffic, it must be associated with the IP address of its remote
router. For example, suppose that:
+ HeadQuarter’s IP address is [Link]
+ Branch 1’s IP address is [Link]
+ Branch 2’s IP address is [Link]

Then the HeadQuarter will need to map Branch 1 IP address to DLCI 23 & map Branch 2 IP address
to DLCI 51. After that it can encapsulate data inside a Frame Relay frame with an appropriate DLCI
number and send to the destination. The mapping of DLCIs to Layer 3 addresses can be handled
manually or dynamically.

* Manually (static): the administrators can statically assign a DLCI to the remote IP address by
the following statement:

Router(config-if)#frame-relay map protocol dlci [broadcast]

For example HeadQuarter can assign DLCIs of 23 & 51 to Branch 1 & Branch 2 with these
commands:

HeadQuarter(config-if)#frame-relay map ip [Link] 23 broadcast

HeadQuarter(config-if)#frame-relay map ip [Link] 51 broadcast

We should use the “broadcast” keyword here because by default split-horizon will prevent routing
updates from being sent back on the same interface it received. For example, if Branch 1 sends an
update to HeadQuarter then HeadQuarter can’t send that update to Branch 2 because they are
received and sent on the same interface. By using the “broadcast” keyword, we are telling the
HeadQuarter to send a copy of any broadcast or multicast packet received on that interface to the
virtual circuit specified by the DLCI value in the “frame-relay map” statement. In fact the copied
packet will be sent via unicast (not broadcast) so sometimes it is called “pseudo-broadcast”.

Note: “frame-relay interface-dlci” command can be used to statically assign (bind) a DLCI number
to a physical interface.

Note: In fact, we need to run a routing protocol (like OSPF, EIGRP or RIP…) to make different
networks see each other

* Dynamic: the router can send an Inverse ARP Request to the other end of the PVC for its
Layer 3 address. In short, Inverse ARP will attempt to learn its neighboring devices IP addresses
and automatically create a dynamic map table. By default, physical interfaces have Inverse ARP
enabled.

We will take an example of how Inverse ARP works with the topology above. At the beginning, all
routers are not configured with static mapping and HeadQuarter has not learned the IP addresses
of Branch 1 & 2 yet. It only has 2 DLCI values on s0/0 interface (23 & 51). Now it needs to find out
who are attached to these DLCIs so it sends an Inverse ARP Request on s0/0 interface. Notice that
the router will send Inverse ARP Request out on every DLCI associated with the interface.
In the Inverse ARP Request, HeadQuarter also includes its IP [Link]. When Branch 1 & 2 receive
this request, they send back an Inverse ARP Reply with their own IP addresses.

Now all the routers have a pair of DLCI & IP address of the router at the other end so data can be
forwarded to the right destination.

In this example you can see that each router has a DLCI first (Layer 2) and it needs to find out the
IP address (Layer 3). This process is opposite of the ARP process (ARP translates Layer 3 address to
Layer 2 address) so it is called Inverse ARP.

After the Inverse ARP process completes, we can use the “show frame-relay map” to check. The
word “dynamic” indicates the mapping was learned through Inverse ARP (the output below is not
related to the above topology):

By default, routers send Inverse ARP messages on all active DLCIs every 60 seconds.

Another thing you should notice is when you supply a static map (via “frame-relay map”
command), Inverse ARP is automatically disabled for the specified protocol on the specified DLCI.

In the last part we will mainly learn about LMI, which is the signaling protocol of Frame Relay

LMI

Local Management Interface (LMI) is a signaling standard protocol used between your router (DTE)
and the first Frame Relay switch. The LMI is responsible for managing the connection and
maintaining the status of your PVC.
LMI includes:
+ A keepalive mechanism, which verifies that data is flowing
+ A multicast mechanism, which provides the network server (router) with its local DLCI.
+ A status mechanism, which provides PVC statuses on the DLCIs known to the switch

In our example, when HeadQuarter is configured with Frame Relay, it sends an LMI Status Inquiry
message to the DCE. The response from the DCE might be a small Hello message or a full status
report about the PVCs in use containing details of all the VCs configured (DLCI 23 & 51). By default,
LMI messages are sent out every 10 seconds.

The four possible PVC states are as follows:

+ Active state: Indicates that the connection is active and that routers can exchange data.
+ Inactive state: Indicates that the local connection to the Frame Relay switch is working, but the
remote router connection to the Frame Relay switch is not working.
+ Deleted state: Indicates that no LMI is being received from the Frame Relay switch, or that
there is no service between the customer router and Frame Relay switch.
+ Static state: the Local Management Interface (LMI) mechanism on the interface is disabled (by
using the “no keepalive” command). This status is rarely seen so it is ignored in some books.

We can use the “show frame-relay lmi” to display LMI statistics of Frame Relay on enabled
interfaces of the router. The output shows the LMI type used by the Frame Relay interface and the
counters for the LMI status exchange sequence, including errors such as LMI timeouts.

Cisco routers support the following three LMI types:

* Cisco: LMI type de?ned jointly by Cisco, StrataCom, Northern Telecom (Nortel), and Digital
Equipment Corporation
* ANSI: ANSI T1.617 Annex D
* Q.933A: ITU-T Q.933 Annex A

Notice that three types of LMI are not compatible with each others so the LMI type must match
between the provider Frame Relay switch and the customer DTE device.

From Cisco IOS Release 11.2, the router attempts to automatically detect the type of LMI used by
the provider switch.

Note: LMI is required for Inverse ARP to function because it needs to know that the PVC is up before
sending out Inverse ARP Request.

Now you learn most of Frame Relay mentioned in CCNA, some other Frame Relay’s characteristics
you should know are mentioned below.

Other Frame Relay characteristics

+ Frame Relay provides no error recovery mechanism. It only provides CRC error detection.
+ Unlike with LANs, you cannot send a data link layer broadcast over Frame Relay. Therefore,
Frame Relay networks are called nonbroadcast multiaccess (NBMA) networks.
+ Depending on the bandwidth needed for each virtual connection, the customer can order a
circuit with a guaranteed amount of bandwidth. This amount is the Committed Information
Rate (CIR). CIR defines how much bandwidth the customer is “guaranteed” during normal network
operation. Any data transmitted above this purchased rate (CIR) is available for discard by the
network if the network doesn’t have available bandwidth.
+ If the Frame relay switch begins to experience congestion, it sends the upstream site (to the
source) a Backward explicit congestion notification (BECN) and the downstream site (to the
destination) a Forward explicit congestion notification (FECN).

+ There are two Frame Relay encapsulation types: the Cisco encapsulation and the IETF Frame
Relay encapsulation, which is in conformance with RFC 1490 and RFC 2427. The former is often
used to connect two Cisco routers while the latter is used to connect a Cisco router to a non-Cisco
router.

+ Frame Relay does not define the way the data is transmitted within the service provider’s
network once the traffic reaches the provider’s switch. So the providers can use Frame Relay, ATM
or PPP… inside their networks.

Layer 2 Encapsulation Protocols

Besides Frame Relay there are other Layer 2 Encapsulation Protocols that you can implement
instead:

High-Level Data Link Control (HDLC): The default encapsulation type for Cisco routers on
point-to-point dedicated links and circuit-switched connections. HDLC is a Cisco proprietary
protocol.
Point-to-Point Protocol (PPP): Provides connections between devices over several types of
physical interfaces, such as asynchronous serial, High-Speed Serial Interface (HSS1), ISDN, and
synchronous. PPP works with many network layer protocols, including IP and IPX. PPP can use
either Password Authentication Protocol (PAP) or Challenge Handshake Authentication Protocol
(CHAP) for authentication.
X.25/Link Access Procedure, Balanced (LAPB): Defines connections between DTE and DCE for
remote terminal access. LAPB is a data link layer protocol specified by X.25.
Asynchronous Transfer Mode (ATM): International standard for cell relay using fixed-length
(53-byte) cells for multiple service types. Fixed-length cells allow hardware processing, which
greatly reduces transit delays. ATM takes advantage of high-speed transmission media such as E3,
T3, and Synchronous Optical Network (SONET).

If you want to learn how to configure Frame Relay in GNS3, please read my Frame Relay Lab in
GNS3 tutorial.