Why Frame Relay?

Frame Relay is a topic that makes us wonder whether we are in the 21st century or not. The good news is: yes, we are. But then, why are we still talking about Frame Relay?

Some people may say, “because Cisco wants to,” but in fact, there are still companies that are using Frame Relay services to connect to WAN.

No matter whether your company still uses Frame Relay or you’re just preparing for an exam, you should still know the technology. This article contains a detailed explanation of the protocol and its configuration.

CCNA Training – Resources (Intense)

You may get Frame Relay questions or scenarios to solve during exams, not only because it is still used, but mostly because Frame Relay puts a lot of difficulties on the higher level protocols and solving these sometimes complex scenarios will demonstrate not only good understanding of Frame Relay but also of the technology or protocol that runs on top of it. Just an example: remember that most of the OSPF network types are best explained in conjunction with Frame Relay.

In the real world, Frame Relay was mostly replaced by MPLS but there could still be companies that use it, probably due to long-time contracts signed with their providers. Anyway, even in these cases, it’s almost certain that you will not find an end-to-end Frame Relay connection these days, but rather FR on the last mile and MPLS in the provider’s core.

What are the Challenges Introduced by Frame Relay?

Frame Relay is a packet switching technology originally designed for use over the ISDN infrastructure, being governed by several standards, such as ANSI (American National Standards Institute), ITU-T (International Telecommunication Union Telecommunication Standardization Sector) back in the ’80s, and FRF (Frame Relay Forum) and IETF (Internet Engineering Task Force) standards in the ’90s.

The first challenge with Frame Relay networks is to make sure that the communicating devices follow the same standards (as you will see later: same encapsulation type, same LMI type, etc.).

Actually, the lack of interoperability in the ’80s was one of the reasons why Cisco and other companies formed a consortium called “The Gang of Four” to focus on Frame Relay technology development.

Frame Relay is usually compared with X.25, an older packet-switched technology also governed by standards issued by ITU-T, but it easily won the contest and was seen as a replacement of X.25, because it was simpler (compared to complex X.25), faster (by eliminated the error checking procedures that made X.25 a very slow, but error-free protocol) and also because it was able to dynamically share and allocate the available bandwidth (as opposed to typical static bandwidth allocation with X.25).

Although it is not really considered a “challenge” due to low error rates in today’s links, you have to remember that Frame Relay uses a best-effort approach for packet delivery because it eliminated the error-checking fields that X.25 had and it relies on the upper layer protocols to do the error corrections. If Frame Relay detects that something is wrong with a frame such as corrupted bits using a simple cyclic redundancy check / CRC algorithm, it will just drop it.

Frame Relay is a Non-Broadcast Multi-Access (NBMA) medium. To understand non-broadcast, let’s define the opposite term broadcast, which is a transmission that is received by all devices on that network segment, typical to Ethernet technology, by using a destination layer 2 address that is mapped to all nodes – the MAC address of FFFF:FFFF:FFFF.

Frame Relay does not have a layer 2 address mapped to all devices so it cannot achieve a broadcasting communication using this method and this is the reason that it is considered a non-broadcast technology.

On the other hand, Frame Relay is a multi-access medium, meaning that there could be multiple devices on the same physical link that could talk to each other. This is achieved by using multiple logical end-to-end connections (referred to as virtual circuits) between devices on that medium.

We will see later in the article what solutions we have to use Frame Relay for broadcast transmissions.

Another challenge is represented by the difference between the layer 2 connectivity and layer 3 view (what layer 3 protocols “think” about layer 2), again due to the fact that in the absence of broadcast, it could be very difficult to discover all the devices connected at layer 2, which is mostly common in partial-mesh or hub-and-spoke topologies. For example, all devices connected to the same Ethernet broadcast domain are able to see each other (using broadcast or multicast) but in case of Frame Relay more devices could be connected to the same link but they don’t necessary have direct connectivity between each other (spoke-to-spoke communications).

Split horizon is another challenge that needs to be accounted for when using distance vector routing protocols over Frame Relay, because multiple neighbors may exist on the same interface but they are not able to directly talk to each other for the same reason mentioned above (see spoke-to-spoke).

Last but not least, in today’s networks, the fact that Frame Relay is commonly present only at the edge of the provider’s network while the core uses different technologies or protocols, introduces difficulties in maintaining an end-to-end status of the virtual circuits.

The following sections will describe Frame Relay in detail and will show solutions to the above so-called “challenges.”

Please expect a long reading, so grab a coffee or a sandwich, or bookmark the page for later reading and reference. 🙂

The Basics

A typical Frame Relay implementation is the inter-connection of a company’s remote offices:

There are two types of devices involved in Frame Relay networks: DTE (Data Terminal Equipment) and DCE (Data Circuit-terminating Equipment):

  • DTE devices are typically the routers in each remote office used to connect to the Frame Relay cloud.
  • DCE devices are the telecommunications providers’ equipment that performs the Frame Relay switching and, more importantly, provides clocking for the links.

In order to send the frames between the DTE devices, virtual paths are created through the Frame Relay cloud between each pair of devices. These logical paths are called virtual circuits and they could be of two different types:

  • Switched Virtual Circuits (SVC) is a temporary virtual circuit that is set up only when there is need to transmit data.

    The usage of SVC involves several phases such as: call setup, data transfer, idle period and call termination that follows periods of idleness when no data is transferred.

  • Permanent Virtual Circuits (PVC) is a permanent connection that does not require call setup or termination and DTE devices can begin transferring data whenever they need to.

Frame Relay typically uses PVCs.

Virtual circuits are identified by using a 10-bit identifier called Data Link Connection Identifier (DLCI). Out of a total of 1024 values (2 at a power of 10), only the values 16 to 991 are available for user data, while the rest are used for management or control purposes.

These DLCIs have only local significance. You can actually look at them as the link-local addresses used in IPv6 addressing. DLCI addresses are used by the Frame Relay switches to forward the data from the sending DTE device all the way to the receiving DTE, as displayed below:

Remember we said that Frame Relay is a multi-access medium? This is because on the same single physical link, you can multiplex more virtual circuits using separate DLCI for each of them. A typical Frame Relay diagram looks like below:

In the above diagram, router R1 has a single physical connection to the Frame Relay cloud but it has a separate virtual circuit for each neighbor device: DLCI 102 for the PVC to R2, DLCI 103 for the PVC to R3 and DLCI 104 for the PVC to R4.

The topology shown above is a partial-mesh because there are no separate virtual circuits between each pair of devices connected to the Frame Relay cloud.

Local Management Interface (LMI)

Cisco and 3 other companies created a consortium known as “The Gang of Four” which introduced a set of enhancements or extensions to the basic Frame Relay specifications in order to make Frame Relay more popular.

Local Management Interface (LMI) is such an extension that provides a signaling or diagnostic between the DTE router and the Frame Relay switch, using several types of messages:

  • Virtual circuit status messages: keepalives sent between the DTE – DCE devices to inform about the status of the virtual circuit.
  • Global addressing messages: makes the DLCI values globally significant – each DTE router is assigned a globally unique DLCI address.
  • Multicasting messages: add multicast capabilities to Frame Relay.

The DTE devices will learn all the DLCIs on a particular physical link from the LMI messages received from the Frame Relay switch.

Address Resolution via Dynamic Mapping: Inverse ARP

Each DTE router learns the DLCI via the LMI messages but it does not know what the IP address of the neighboring device or devices is. The process of discovering the IP address of the remote end is called Inverse ARP (InARP), thus creating mapping between local DLCI and the remote end’s protocol address.

The name “Inverse ARP” comes from the fact that “normal” ARP is used to discover the layer-2 MAC address having the layer-3 IP address, while in case of Frame Relay, the DLCI (layer-2 address) is already learnt via LMI but it does not know the layer-3 address (therefore, the “inverse” logic).

Once an IP address is configured on an interface connected to the Frame Relay cloud, InARP messages containing that IP address are sent on all DLCI on that interface. In the diagram, R1 sends InARP requests with its IP 192.168.1.1 on both DLCI 102 (towards R2) and DLCI 103 (towards R3) and, based on the received InARP replies, it will map IP 192.168.1.2 to DLCI 102 and IP 192.168.1.3 to DLCI 103.

There are several important notes that need to be remembered:

  1. Inverse ARP cannot work without LMI, because LMI is the mechanism used to learn about the DLCI associated with that interface. Without LMI, the router does not learn any DLCI, so it cannot send InARP messages.
  2. All DLCIs learned via LMI are automatically associated with the main interface (we will talk later about sub-interfaces), so the Inverse ARP requests are generated only by the main interface.
  3. By default, Inverse ARP supports broadcasts.
  4. Inverse ARP is automatically enabled by LMI, unless disabled by static mapping as we will see below.

Address Resolution via Static Mapping

Inverse ARP is a dynamic mechanism of mapping an IP address to a DLCI, but the same result can be achieved with static mapping via manual configuration.

A very important note here that’s easily overlooked during exams is that the static mapping disables the Inverse ARP for the pair (protocol, DLCI) – where the protocol is IP. Suppose that you create static mapping for IP 192.168.1.2 to DLCI 102 – then, this will automatically disable InARP for the pair (IP, DLCI 102). Actually, the static mapping does not disable InARP completely, only the InARP requests, but the router will still reply to the InARP messages!

Broadcast, Non-Broadcast, Pseudo-Broadcast

As mentioned above in the “challenges” introductory section, Frame Relay networks are Non-Broadcast Multi-Access (NBMA) because there is no Layer-2 address mapped to all nodes in the Frame Relay cloud, as is the case with Ethernet broadcast MAC address of FFFF:FFFF:FFFF.

Still, another technique called “pseudo broadcast” is used to achieve the same effect of a broadcast communication, by sending copies of the same packet over more DLCI of the same physical link.

Frame Relay Topologies

You can create one or more sub-interfaces on the physical link that connects to the Frame Relay cloud and you have the option of choosing one of the following types:

  • Point-to-point sub-interfaces: there are only 2 devices on them.
  • Multipoint sub-interfaces: there are more devices on them.

The physical / main interface is a multipoint interface and all the rules associated

with multipoint connections apply to it.

As a result, you may have several topologies, such as:

  • Point-to-point
  • Full mesh: there is a virtual circuit for each pair of devices connected to the Frame Relay.
  • Partial-mesh
  • Hub-and-spoke: a central router (hub = headquarter) connected to all spokes (remote offices). Spoke to spoke communication is possible only via the hub.

With all the terms defined and explained above, let’s move to the configuration of Frame Relay.

1. Frame Relay encapsulation

Configuring the encapsulation is the first step of configuring Frame Relay. Cisco routers support two types of Frame Relay encapsulation: cisco and ietf.

“Cisco” encapsulation is the default type and “ietf” is used when there are non-Cisco devices in the network.

(config)#int s0/0
(config-if)#encapsulation frame-relay [ietf]

The above snippet shows a common configuration of Frame Relay encapsulation on the main interface, which will apply to all virtual circuits.

It is possible to configure different encapsulations on a per virtual circuit (or per-DLCI) scheme:

  • For a point-to-point sub-interface:

(config)#int s0/1.1 point-to-point
(config-subif)#frame-relay interface-dlci <dlci-number> [cisco | ietf]

  • Via static mapping:

(config)#int s0/0
(config-if)#frame-relay map ip <ip-address> <dlci-number> [cisco | ietf]

2. Configuring the LMI type

By default, the LMI is autosensed and is automatically set based on the LMI type received from the Frame Relay switch, so most of the time you don’t have to do anything.

Unlike the encapsulation, the LMI type cannot be configured on a per-DLCI basis and it is set only as a per-interface command. This applies to all DLCI mapped to that interface / sub-interface:

(config)#int s0/0
(config-if)#frame-relay lmi-type [ cisco | ansi | q9333 ]

There are three standards for LMI type:

  • cisco” uses DLCI 1023 as specified by the “Gang of Four”
  • ansi” uses a DLCI of 0 (specified in ANSI’s T1.617 Annex D standard)
  • q9333” uses a DLCI of 0 (specified in ITU-T’s Q.933 Annex A standard)

As shown above, the Frame Relay encapsulation type needs to match on a per DLCI/end-to-end virtual circuit, while the LMI type needs to match per (DTE,DCE) pair, between the DTE router and the DCE Frame Relay switch.

You have the possibility to disable the LMI on an interface by specifying the “no keepalive” command:

(config)#int s0/0
(config-if)#no keepalive

One scenario when the keepalive/LMI is disabled is the “back-to-back” routers connectivity when same DLCI is used on both sides.

Also, you can change the default keepalive interval of 10 seconds though you may want to configure the same value on both DTE router and Frame Relay switch in order to avoid interface flapping.

3. Configuring the IP-to-DLCI Mappings

a. Dynamic Mapping on Multipoint or Physical

As explained above in the theoretical section, Inverse ARP is automatically enabled by LMI.

The dynamic mappings are easily recognized by the “dynamic” word that appears in the output of the “show frame-relay map” command:

R1#show frame-relay map
Serial0/0 (up): ip 192.168.1.2 dlci 102(0x66,0x1860), dynamic,
broadcast,
Serial0/0 (up): ip 192.168.1.3 dlci 103(0x67,0x1870), dynamic,
broadcast,

In order to manually clear the dynamic obsolete, use the “clear frame-relay inarp” command.

b. Static Mapping on Multipoint or Physical

Static mappings are configured with the “frame-relay map” command:

(config)#int s0/0
(config-if)#frame-relay map ip <ip-address> <dlci-number> [broadcast] [cisco | ietf]

Don’t forget to include the “broadcast” keyword in case you need broadcast communication to be sent on that virtual circuit.

In case of a hub-and-spoke topology, you need to perform the static mapping between the spokes using the hub DLCI in order to enable spoke-to-spoke connectivity (via the hub, of course).

Below is an example of such configuration. Notice that the FR encapsulation was changed to IETF:

(config)#int s0/0
(config-if)#frame-relay map ip 192.168.1.2 102 broadcast ietf
!
R1#show frame map
Serial0/0 (up): ip 192.168.1.2 dlci 102(0x66,0x1860), static,
broadcast
,

IETF
, status defined, active

c. Point-to-Point DLCIs

Point-to-point sub-interfaces could only have 2 devices on them so it does not need any mapping. Actually, such sub-interfaces do not allow the “frame-relay map” command. The only piece of information needed is the DLCI, which will be used to send all data onto that point-to-point sub-interface:

(config)#int s0/1.1 point-to-point
(config-subif)#frame-relay interface-dlci <dlci-number> [cisco | ietf]
!
sh frame map
Serial0/1.1 (up): point-to-point dlci, dlci 123(0x7B,0x1CB0), broadcast

status active

This option is the most recommended one, especially on the spokes in a hub-and-spoke design as it eliminates the need to create static mappings for each spoke-to-spoke communication that could become a real burden in case of big number of spokes.

d. Assigning Learnt DLCI to Multipoint Sub-interfaces

By default, all DLCI learned via LMI are automatically assigned to the physical/main interface. In case of multipoint interfaces, you need to “move” those DLCI from the main interface to the sub-interface using the same command as in the case of point-to-point sub-interfaces:

(config)#int s0/1.1 point-to-point
(config-subif)#frame-relay interface-dlci <dlci-number> [cisco | ietf]

e. Disabling Inverse ARP

As previously described, InARP is automatically enabled by the LMI and it sends InARP requests as soon as a protocol address (IP address) is configured on an interface.

You have the following options to disable it:

  • no frame-relay inverse-arp <protocol> <dlci>” – disables InARP for the specified (protocol,DLCI) pair.
  • using a static mapping: “frame-relay map ip <ip-address> <dlci-number>” – sdf static mapping disables sending InARP requests for the specified (protocol,DLCI) pair, but it will reply to received InARP messages.

As a summary, let’s look at an easy-to-remember or easy-to-reference table regarding mappings on various types of interfaces/sub-interfaces:

A very good reference containing configuration examples for various topologies (simple Frame Relay, full-mesh, partial-mesh, hub-and-spoke) can be found on the Cisco website: http://www.cisco.com/en/US/tech/tk713/tk237/technologies_tech_note09186a008014f8a7.shtml

In our next article, we’ll describe various methods of troubleshooting Frame Relay connectivity problems.