Single Interface Frame Relay Implementation and Monitoring

Let’s get started by looking at a simple example. Say that we just want to connect two routers with a single PVC. Here’s how that configuration would look:

RouterA#config t
Enter configuration commands, one per line. End with CNTL/Z.
RouterA(config)#int s0/0
RouterA(config-if)#encapsulation frame-relay
RouterA(config-if)#ip address 172.16.20.1 255.255.255.0
RouterA(config-if)#frame-relay lmi-type ansi
RouterA(config-if)#frame-relay interface-dlci 101
RouterA(config-if)#^Z
RouterA#

The first step is to specify the encapsulation as Frame Relay. Notice that since I didn’t specify a particular encapsulation type—either Cisco or IETF—the Cisco default type was used. If the other router were non-Cisco, I would’ve specified IETF. Next, I assigned an IP address to the interface, then specified the LMI type of ANSI (the default being Cisco) based on information provided by the telecommunications provider. Finally, I added thevDLCI of 101, which indicates the PVC we want to use (again, given to me by my ISP) andvassumes there’s only one PVC on this physical interface.

That’s all there is to it—if both sides are configured correctly, the circuit will come up.

Virtual Circuits

Frame Relay operates using virtual circuits as opposed to the actual circuits that leased lines use. These virtual circuits are what link together the thousands of devices connected to the provider’s “cloud.” Frame Relay provides a virtual circuit between your two DTE devices, making them appear to be connected via a circuit when in reality, they’re dumping their frames into a large, shared infrastructure. You never see the complexity of what’s actually happening inside the cloud because you only have a virtual circuit.

And on top of all that, there are two types of virtual circuits—permanent and switched. Permanent virtual circuits (PVCs) are by far the most common type in use today. What “permanent” means here is that the telco creates the mappings inside their gear and as long as you pay the bill, they’ll remain in place.

Switched virtual circuits (SVCs) are more like a phone call. The virtual circuit is established when data needs to be transmitted, then it’s taken down when the data transfer is complete.

Troubleshooting Using Frame Relay Congestion Control

Now let’s say all your users are whining about the fact that their Frame Relay connection to the corporate site is super slow. Because you strongly suspect that the link is overloaded, you verify the Frame Relay congestion control information with the show frame-relay pvc command and get this:

RouterA#sh frame-relay pvc

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

What you want to look for is the in BECN pkts 192 output because this is what’s telling the local router that traffic sent to the corporate site is experiencing congestion. BECN means that the path that a frame took to “return” to you is congested.

Frame Relay Congestion Control

Remember back to our talk about CIR? From that, it should be obvious that the lower your CIR is set, the greater the risk is that your data will become toast. This can be easily avoided if you have just one key piece of information—when and when not to transmit that huge burst! This begs the question, Is there any way for us to find out when our telco’s shared infrastructure is free and clear and when it’s crammed and jammed? Also, if there is a way to spy this out, how do you do it? Well, that’s exactly what I’m going to talk about next—how the Frame Relay switch notifies the DTE of congestion problems—and address those very important questions.

Here are the three congestion bits and their meanings:

Discard Eligibility (DE) As you know, when you burst (transmit packets beyond the CIR of a PVC), any packets exceeding the CIR are eligible to be discarded if the provider’s network is congested at the time. Because of this, the excessive bits are marked with a Discard Eligibility (DE) bit in the Frame Relay header. And if the provider’s network happens to be congested, the Frame Relay switch will discard the packets with the first DE bit set. So if your bandwidth is configured with a CIR of zero, the DE will always be on.

Forward Explicit Congestion Notification (FECN) When the Frame Relay network recognizes congestion in the cloud, the switch will set the Forward Explicit Congestion Notification (FECN) bit to 1 in a Frame Relay packet header. This will indicate to the destination DTE that the path the frame just traversed is congested.

Backward Explicit Congestion Notification (BECN) When the switch detects congestion in the Frame Relay network, it’ll set the Backward Explicit Congestion Notification (BECN) bit in a Frame Relay frame that’s destined for the source router. This notifies the router that congestion is ahead. But Cisco routers won’t take action on this congestion information unless you tell them to.

Local Management Interface (LMI)

Local Management Interface (LMI) is a signaling standard used between your router and the first Frame Relay switch it’s connected to. It allows for passing information about the operation and status of the virtual circuit between the provider’s network and the DTE (your router).

It communicates information about the following:

Keepalives These verify that data is flowing.  

Multicasting This is an optional extension of the LMI specification that allows, for example, the efficient distribution of routing information and ARP requests over a Frame Relay network. Multicasting uses the reserved DLCIs from 1019 through 1022.

Global addressing This provides global significance to DLCIs, allowing the Frame Relay cloud to work exactly like a LAN.

Status of virtual circuits This provides DLCI status. The status inquiries and messages are used as keepalives when there is no regular LMI traffic to send.

But remember, LMI is not communication between your routers; it’s communication between your router and the nearest Frame Relay switch. So it’s entirely possible that the router on one end of a PVC is actively receiving LMI while the router on the other end of the PVC is not. And of course, PVCs won’t work with one end down. (I say this to clarify the local nature of LMI communications.)

There are three different types of LMI message formats: Cisco, ANSI, and Q.933A. The different kinds in use depend on both the type and configuration of the telco’s switching gear, so it’s imperative that you configure your router for the correct format, which should be provided by the telco.

Note: Beginning with IOS version 11.2, the LMI type is autosensed. This enables the interface to determine the LMI type supported by the switch. If you’re not going to use the autosense feature, you’ll need to check with your Frame Relay provider to find out which type to use instead.

On Cisco equipment, the default type is, surprise, Cisco, but you still might have to change to ANSI or Q.933A depending on what your service provider tells you.

The three different LMI types are shown in the following router output:

RouterA(config-if)#frame-relay lmi-type ?
cisco
ansi
q933a

As seen in the output, all three standard LMI signaling formats are supported. Here’s a description of each:

Cisco LMI defined by the Gang of Four (default). The Local Management Interface (LMI) was developed in 1990 by Cisco Systems, StrataCom, Northern Telecom, and Digital Equipment

Corporation and became known as the Gang-of-Four LMI, or Cisco LMI.

ANSI Annex D included with ANSI standard T1.617.

ITU-T (Q.933A) Annex A included in the ITU-T standard and defined by using the Q.933a command keyword.

Routers receive LMI information from the service provider’s Frame Relay switch on a frame encapsulated interface and update the virtual circuit status to one of three different states:

Active state Everything is up, and routers can exchange information.

Inactive state The router’s interface is up and working with a connection to the switching office, but the remote router isn’t up.

Deleted state No LMI information is being received on the interface from the switch, which could be due to a mapping problem or a line failure.

Data Link Connection Identifiers (DLCIs)

Frame Relay PVCs are identified to DTE end devices by Data Link Connection Identifiers (DLCIs). A Frame Relay service provider typically assigns DLCI values, which are used on Frame Relay interfaces to distinguish between different virtual circuits. Because many virtual circuits can be terminated on one multipoint Frame Relay interface, many DLCIs are often affiliated with it.

Let me explain—suppose you have a central HQ with three branch offices. If you were to connect each branch office to HQ using a T1, you would need three serial interfaces on your router at HQ, one for each T1. Simple, right? Well, suppose you use Frame Relay PVCs instead. You could have a T1 at each branch connected to a service provider and only a single T1 at HQ. There would be three PVCs on the single T1 at HQ, one going to each branch. And even though there’s only a single interface and a single CSU/DSU, the three PVCs function as three separate circuits. Remember what I said about saving money? How much for two additional T1 interfaces and a pair of CSU/DSUs? Answer: A lot! So, why not just go ahead and ask for a percentage of the savings in your bonus?

Okay, before we go on, I want to define Inverse ARP (IARP) and discuss how it’s used with DLCIs in a Frame Relay network. Yes, it is somewhat similar to ARP in the fact that it maps a DLCI to an IP address—kind of like ARP does with MAC addresses to IP addresses. And even though you can’t configure IARP, you can disable it. It runs on a Frame Relay router and maps the DLCI to an IP address for Frame Relay so it knows how to get to the Frame Relay switch. You can see IP-to-DLCI mappings with the show frame-relay map command.

But if you have a non-Cisco router living in your network and it doesn’t support IARP, then you’re stuck with having to statically provide IP-to-DLCI mappings with the frame-relay map command—something I’ll demonstrate in a bit.

Let’s talk about DLCIs a bit more. They’re locally significant—global significance requires the entire network to use the LMI extensions that offer global significance. This is why you’ll mostly find global DLCIs only in private networks.

But the DLCI doesn’t have to be globally significant for it to be functional in getting a frame across the network. Let me explain: When RouterA wants to send a frame to RouterB, it looks up the IARP or manual mapping of the DLCI to the IP address it’s trying to get to. Equipped with the DLCI, it then sends the frame out with the DLCI value it found in the DLCI field of the FR header.

The provider’s ingress switch gets this frame and does a lookup on the DLCI/physical-port combination it observes. Associated with that combination, it finds a new “locally significant” (meaning, between itself and the next-hop switch) DLCI to use in the header, and in the same entry in its table, it finds an outgoing physical port. This happens all the way to RouterB. So basically, you
actually could say that the DLCI RouterA identifies the entire virtual circuit to RouterB, even
though every DLCI between every pair of devices could be completely different. The big point here is that RouterA is unaware of these differences. That’s what makes the DLCI locally significant. So
make a mental note that DLCIs really are used by the telco to “find” the other end of your PVC.

To discover why DLCIs are considered locally significant, take a look at Figure 1. In the figure, DLCI 100 is considered locally significant to RouterA and identifies the circuit between RouterA and its ingress Frame Relay switch. DLCI 200 would identify the circuit between RouterB and its ingress Frame Relay switch.

Figure 1: DLCIs are local to your router

DLCI numbers that are used to identify a PVC are typically assigned by the provider and
start at 16.

You configure a DLCI number to be applied to an interface like this:

RouterA(config-if)#frame-relay interface-dlci ?
<16-1007> Define a DLCI as part of the current
subinterface
RouterA(config-if)#frame-relay interface-dlci 16

Frame Relay Encapsulation Types

When configuring Frame Relay on Cisco routers, you need to specify it as an encapsulation on serial interfaces. As I said earlier, you can’t use HDLC or PPP with Frame Relay. When you configure Frame Relay, you specify an encapsulation of Frame Relay (as shown in the following output).But unlike HDLC or PPP, with Frame Relay, there are two encapsulation types: Cisco and IETF (Internet Engineering Task Force). The following router output shows these two different encapsulation methods when Frame Relay is chosen on your Cisco router:

RouterA(config)#int s0
RouterA(config-if)#encapsulation frame-relay ?
ietf Use RFC1490 encapsulation
<cr>

The default encapsulation is Cisco unless you manually type in ietf, and Cisco is the type to use when connecting two Cisco devices. You’d opt for the IETF-type encapsulation if you needed to connect a Cisco device to a non-Cisco device with Frame Relay. Whichever you choose, make sure that the Frame Relay encapsulation is the same on both ends.

Committed Information Rate (CIR)

Frame Relay provides a packet-switched network to many different customers at the same time. This is a really good thing because it spreads the cost of the switches among many customers. But remember, Frame Relay is based on the assumption that all customers won’t ever need to transmit data constantly, and all at the same time.

Frame Relay works by providing a portion of dedicated bandwidth to each user, and it also allows the user to exceed their guaranteed bandwidth if resources on the telco network happen to be available. So basically, Frame Relay providers allow customers to buy a lower amount of bandwidth than what they really use. There are two separate bandwidth specifications with Frame Relay:

Access rate The maximum speed at which the Frame Relay interface can transmit. CIR The maximum bandwidth of data guaranteed to be delivered. In reality, it’s the average amount that the service provider will allow you to transmit.

If these two values are the same, the Frame Relay connection is pretty much just like a leased line. But they can also be set to different values. Here’s an example: Let’s say that you buy an access rate of T1 (1.544Mbps) and a CIR of 256Kbps. By doing this, the first 256Kbps of traffic you send is guaranteed to be delivered. Anything beyond that is called a “burst”— a transmission that exceeds your guaranteed 256Kbps rate, and can be any amount up to the T1 access rate (if that amount is in your contract). If your combined committed burst (the basis for your CIR) and excess burst sizes, known as the MBR or maximum burst rate when combined, exceed the access rate, you can pretty much say goodbye to your additional traffic. It will most likely be dropped, although this really depends on the subscription level of a particular service provider.

In a perfect world, this always works beautifully—but remember that little word guarantee? As in guaranteed rate—of 256Kbps, to be exact? This means that any burst of data you send that exceeds your guaranteed 256Kbps rate will be delivered on something called a “best effort” basis of delivery. Or maybe not—if your telco’s equipment doesn’t have the capacity to deliver it at the time you transmitted, then your frames will be discarded, and the DTE will be notified. Timing is everything--you can scream data out at six times your guaranteed rate of 256Kbps (T1) only if your telco has the capacity available on its equipment at that moment.

Introduction to Frame Relay Technology

As a CCNA, you’ll need to understand the basics of the Frame Relay technology and be able to configure it in simple scenarios. First, understand that Frame Relay is a packet-switched technology. From everything you’ve learned so far, just telling you this should make you immediately realize several things about it:

You won’t be using the encapsulation hdlc or encapsulation ppp command to configure it.

Frame Relay doesn’t work like a point-to-point leased line (although it can be made to look and act like one).

Frame Relay is usually less expensive than leased lines are, but there are some sacrifices to make to get that savings.

So, why would you even consider using Frame Relay? Take a look at Figure 1 to get an idea of what a network looked like before Frame Relay. Now check out Figure 2. You can see that there’s now only one connection between the Corporate router and the Frame Relay switch. That saves some major cash!

If, for example, you had to add seven remote sites to the corporate office and had only one free serial port on your router—it’s Frame Relay to the rescue! Of course, I should probably mention that you now also have one single point of failure, which is not so good. But Frame Relay is used to save money, not to make a network more resilient.

Figure 1: Before Frame Relay

Figure 2: After Frame Relay

Frame Relay creates a cost-effective mesh network.