Frame Relay Technology

Frame Relay is a Non-Broadcast Multi-Access (NBMA) technology. This means that you have to deal with address resolution issues, except for the situations in which you use Point-to-Point interfaces.

The local Layer 2 addresses in Frame Relay are called Data Link Connection Identifiers (DLCI) and this is only locally significant. For example, in a hub-and-spoke environment, the hub device should have a unique DLCI to communicate to each of its spokes.

When you inspect the Frame Relay PVC  status on a Cisco device, you will see a status code defined by LMI that can be any one of the following:

• Active (everything is okay)
• Inactive (no problems on the local node but possible problems on the remote node)
• Deleted (problem in the service provider network)

As an example, Cisco devices offer three flavours of LMI:

• Cisco
• ANSI
• Q.933a

Cisco routers are configured to automatically try all three of these LMI types (starting with the Cisco LMI) and use the one that matches whatever the service provider is using, so this should not be of much concern in the design phase.

One of the most important aspects that needs to be considered in the design phase is the address resolution methodology used. If you are utilising Multipoint interfaces in your design (i.e., interfaces that can terminate multiple Layer 2 circuits), you need to find a way to provide the Layer 3 to Layer 2 resolution. As discussed previously, you have two options that can help you achieve this:

• Dynamically, utilising Inverse ARP
• Statically, via the frame-relay map static configuration command on Cisco devices

On a Multipoint interface, Inverse ARP would happen automatically. This functionality is enabled right after adding an IP address on an interface configured for Frame Relay. At that moment, requests start being sent out all of the circuits assigned to that specific interface for any supported protocol the interface is running.

The request process can be disabled with the no frame-relay inverse-arp command, but you can never design a network that will stop responding to requests. By design, Inverse ARP replies cannot be disabled, so the Frame Relay speaker will always attempt to assist somebody that attempts to do a Layer 3 to Layer 2 resolution via the Frame Relay Inverse ARP.

The Inverse ARP behaviour in the Frame Relay design will automatically assist with Broadcasts through the replicated Unicast approach discussed before. When using Inverse ARP, Broadcast support exists by default.

If you connect two routers to the Frame Relay cloud using physical interfaces, this means that the specific interfaces are Multipoint from a Frame Relay perspective, because a physical Frame Relay interface by default is a Multipoint structure. Even though the connection between the two routers may appear to be Point-to-Point, it is a Frame Relay Multipoint connection.

Figure 42.5 – Frame Relay Multipoint Example

Because they use Multipoint interfaces, by default the two devices will handle the Layer 3 to Layer 2 resolution dynamically by using Inverse ARP. If you would like to design a solution in which Inverse ARP would not be used, you can turn off the dynamic mapping behaviour on each device and then configure static Frame Relay mappings.

Point-to-point configurations are the ideal choice when it comes to Layer 3 to Layer 2 resolution because this process does not occur when using such interface types. When configuring Point-to-Point Frame Relay, you would use Point-to-Point subinterfaces and these subinterfaces would not get the DLCI assignments from LMI, like in the Multipoint situation.

Another option would be to create subinterfaces and declaring them as Multipoint. These types of interfaces behave exactly like the physical Multipoint interfaces, so you need to decide on the resolution method to be used, either Inverse ARP or static mappings. A combination of these methods can be used, for example, by implementing Inverse ARP on one end of the connection and defining static maps on the other end.

The interface type settings and the selected Layer 3 to Layer 2 resolution method is only locally significant. This means that you can have all kinds of variations in your Frame Relay design, such as those listed in Table 42.1 below:

Table 42.1 – Variations in the Frame Relay Design

Partial-mesh designs and configurations will be the most challenging. This implies that Layer 2 circuits will not be provisioned between all endpoints involved in the Frame Relay environment.

In a hub-and-spoke environment, the spokes are not directly connected to each other, so this means that they cannot resolve each other via Inverse ARP. In order to solve these issues, you can do any of the following:

• Provide additional static mappings
• Configure Point-to-Point subinterfaces
• Design the hub-and-spoke infrastructure so that the Layer 3 routing design can solve the resolution problems (e.g., by using the OSPF Point-to-Multipoint network type)

Frame Relay supports markings that can impact Quality of Service (QoS). For example, the Frame Relay header contains a DE (Discard Eligible) bit. With Frame Relay environments for QoS, packets can be marked with the DE bit and this informs the service provider that those specific packets are not very important and can be discarded in case of congestion. This behaviour will prioritise packets that do not have the DE bit set.

Other parameters that can be configured in the Frame Relay environment are Forward Explicit Congestion Notifications (FECNs) and Backwards Explicit Congestion Notifications (BECNs) which commonly crops up as an exam question. The Frame Relay equipment, if configured to do so, can notify devices of congestion and can cause the slowing down of the sending rates.