Configuring Frame Relay

 Configuring Frame Relay


  • Configure and verify Frame Relay on Cisco routers

Configuring Frame Relay can be very simple or slightly complex, depending on your network requirements and design. I’d like to walk you through three configuration scenarios, explaining step-by-step how each piece is configured. By the time you’re finished here, you’ll be a Frame Relay expert. The three configuration scenarios are as follows:

  • Configuring Frame Relay for a single neighbor
  • Configuring Frame Relay that uses a multipoint interface
  • Configuring Frame Relay that uses a point-to-point interface

Configuring Frame Relay for a Single Neighbor

This configuration is the simplest one to set up for Frame Relay. Because the router does most of the work for you in this configuration, many people call this a Frame Relay auto-configuration. It is helpful to walk through this configuration step-by-step, first looking at Figure 23.8.

Frame Relay Overview23.8

FIGURE 23.8 Simple Frame Relay configuration.

There are two locations in this scenario: Alabama and Alaska. This configuration is really a point-to-point style connection, we’re just going through a Frame Relay cloud to accomplish it. Alabama uses DLCI 503 to reach Alaska, and Alaska uses DLCI 305 to reach Alabama. You’ve already configured the necessary IP addresses for the network requirements; all that’s left to do is configure the Frame Relay connection. Let’s have at it!

Step 1: Turn on Frame Relay Encapsulation
Start on the Alabama router to get familiar with your surroundings:

It looks as though the Fast Ethernet interface is up and running, and the Serial 0/0 interface has an IP address, but needs a little work beyond. First turn on the Frame Relay encapsulation:

Take a look at this. When you access the Serial interface and type encapsulation framerelay ?, you are given the option of either hitting the Enter key or adding the ietf keyword after the command. If you just press the Enter key, the router uses Cisco proprietary Frame Relay encapsulation. The Cisco proprietary version of encapsulation came out before the industry standard (ietf) Frame Relay encapsulation and uses a slightly different method for identifying the Layer 3 protocol (IP, IPX, and so on) that is being encapsulated.

This makes it incompatible with the industry standard Frame Relay encapsulation. What it boils down to is this: If you are connecting two Cisco routers over a Frame Relay network, use the command encapsulation frame-relay to configure each side. If you are connecting your Cisco router to a non-Cisco device, use the command encapsulation frame-relay ietf to use the industry standard Frame Relay encapsulation.

Be sure to know how to configure Frame Relay encapsulation between Cisco and non-Cisco routers.

The example wants to connect two Cisco routers, so you can use the Cisco proprietary encapsulation. Watch what happens when the Serial 0/0 interface on the Alabama router is brought up:

It looks like the interface has come up, so now it’s time get out to privileged mode and verify that everything is working as expected. The first command you can use to check the connection is show frame-relay lmi. Remember, LMI (the Local Management Interface) is the language of love between you and your service provider. The service provider uses this language to send status messages, DLCI information, and line statistics to your local router. This is the lowest level of Frame Relay communication. If it is not working, nothing will be working.

Focus on the key information here, which has been conveniently bolded for you. You can see that you have sent 36 status messages and received 35 messages. This is good. These numbers should be relatively equal and increasing on a steady basis. If the connection is failing, you will see the Num Status Timeouts field increment steadily.

You can think of these messages as keepalives for your Frame Relay connection. Your router is saying “Hello” to the service provider (Num Status Enq. Sent) and the service provider is saying “Hello back” (Num Status msgs Rcvd). Now let’s move up to the next level.

By using the show frame-relay pvc command, you can see all your virtual circuit connections over the Frame Relay cloud. Notice that none of this has been configured. The service provider actually sent the usable DLCI information to you with the LMI signaling! Your router (Alabama) received DLCI 503 from the service provider. Referring back to the network diagram in Figure 23.8, you can see that this is exactly the DLCI information you want to receive. But there seems to be a problem: The DLCI is marked as INACTIVE. This is where understanding the four PVC states can come in very handy:

  • Active—A PVC marked as ACTIVE is successfully connected through between the two endpoints (routers). This is the normal state if everything is working properly.
  • Inactive—A PVC marked as INACTIVE is working properly on your end of the connection (the local side); however, the other side of the connection is either not configured or offline.
  • Deleted—A PVC marked as DELETED is having problems at your side (local side) of the connection. Most likely, you are attempting to use a DLCI number that the service provider has not configured.
  • Static—A PVC marked as STATIC has been manually entered by you (the administrator) rather than dynamically discovered from the service provider.

Understanding the states of a PVC can be quite useful in both the real world and the testing environment.

Whew! Quite a bit of information there applies directly to what you are seeing right now. Because the PVC is marked as INACTIVE, it means that your side (Alabama) is working just fine; it’s the remote side (Alaska) that is having the problem. This is where you suddenly realize that you are not just the administrator in Alabama, but also the administrator for Alaska as well. You need to jump on a plane (or use a telnet connection) to reach the Alaska router and configure that side of the connection.

It looks as if Alaska is in the same state as Alabama was when you first got involved in the configuration. Turn on Frame Relay encapsulation and power on the interface:

Take a look at that—the Line Protocol (data link connectivity) on the Serial interface came up and the DLCI 305 went ACTIVE. Now do the same verification commands you did on Alabama to see what things look like:

Right on! The PVC status is now viewed as ACTIVE from the perspective of Alaska, which implicitly implies that Alabama is working as well (because ACTIVE indicates both sides of the connection are working as they should). So, hold your breath—now it’s time to do the final test: to ping from Alaska to Alabama, which acts as an end-to-end test of Network layer (Layer 3)

So let me summarize what it took to get a point-to-point Frame Relay connection running:

1. Turn on Frame Relay encapsulation. That’s it! Of course, there are some prerequisite steps, such as assigning IP addresses and turning on the interface. It may have seemed like a bigger process because of the verification commands that were performed.

However, if you have just a single connection over the Frame Relay cloud, the service provider sends both sides of the connection their DLCI information through LMI signaling. The router then uses Inverse ARP messages to discover the IP address on the remote end of the connection. After the remote IP address is discovered, the router makes the connection between the local DLCI and remote IP address. Look at one more show command:

Be sure to know the LMI types and be able to pick them out of a line-up. It is also key to remember that “ietf” is a Frame Relay encapsulation type. IETF is not an LMI type.

Configuring Frame Relay That Uses a Multipoint Interface

Now, the scenario has expanded with the addition of another office to the mix. This change is reflected in Figure 23.9.

Frame Relay Overview23.9

FIGURE 23.9 Frame Relay configuration with multiple locations.

The Arizona office has entered the picture and moved this story to a hub and spoke design. Alabama is the hub of the network, having PVC connections to both Alaska and Arizona. To save on cost, Alaska and Arizona are not directly connected and must use their PVC to Alabama anytime they would like to reach each other.

Notice the IP addressing in this figure as well: All routers are configured on the same subnet ( for their WAN connections. This IP addressing tells you that you are using a point-to-multipoint design. The routers think the WAN operates just like an ethernet network where all points connected to the network are able to reach all other points in the network.

If you were using a point-topoint design (a much better design, in my humble opinion), each PVC would be on its own subnet, just as if you had point-to-point WAN links through the Frame Relay cloud. The point-to-point design is discussed a little bit later; for now, it’s time to focus on making the point-to-multipoint design work successfully.

Configuring a multipoint interface can be done in two ways: You can either place the configuration under the physical interface itself or use a subinterface. Let me demonstrate. You’ve already done plenty of configuration on the physical interface, just by placing commands directly under the Serial interface. If you want to configure a subinterface, this is how the process looks:

In this case, the multipoint subinterface Serial 0.10 has been created. The subinterface number you choose is completely up to you. As you can see, you can use numbers from zero up to slightly more than 4 billion (Cisco is all about flexibility). In this case, I chose 10. If you were using this for your Frame Relay configuration, you could remove all commands from the physical interface (Serial 0) except for the encapsulation frame-relay command and place them under the subinterface.

At this point, there’s no real advantage to configuring Frame Relay with subinterfaces because you are using a multipoint configuration. After you get to point-topoint, you’ll see the many advantages of this configuration. For now, you can save a little complexity and just configure everything under the physical interface.

If you had a full mesh Frame Relay design where every location had a PVC to every other location, this setup would take care of itself just like the previous configuration you saw. Each location would send an Inverse ARP message out on its PVCs and figure out how to connect to everyone else. However, if you look at the figure, you can see that there is no full mesh of virtual circuits. Alabama will work just fine in this design because it has PVCs to each location.

Alaska and Arizona are going to have some problems if you just leave everything in its default configuration. The Inverse ARP message will be able to discover Alabama because it is directly at the end of the PVC; however, the Inverse ARP message does not “bounce through.” Alaska does not discover Arizona and vice versa.

This is where Frame Relay maps come in handy. You can manually configure each site by defining static maps dictating which DLCIs connect to each remote IP address. Even though it is not necessary to manually configure Alabama, it is a good practice not to mix dynamic and static configurations. If you want to use dynamic, it should be in use everywhere. Likewise, if you want to use static, use it everywhere. So the first thing to do is to configure the hub of the network, Alabama:

You’ve now statically mapped the DLCI numbers to the remote IP addresses. Remember, after you do this, you’ve overruled the Inverse ARP process; you are now taking the role of Inverse ARP under your belt. Look at the first static map: It tells the router, “If you would like to reach the remote IP address, use the local DLCI number 503.” Likewise, the second line says, “To reach the remote IP address, use the local DLCI number 504.” It’s also important to talk about the last option added to the syntax, broadcast. By default, your router treats the Frame Relay cloud just like the type of network it is: NBMA. Therefore, your routing protocols (which use multicast and broadcast traffic) will not work over a Frame Relay network. If you would like the router to forward broadcasts over the Frame Relay cloud, attach the broadcast keyword onto the end of the Frame Relay map.

You can also see from the context-sensitive help that you have many other options in addition to the broadcast keyword that you can add to the end of the Frame Relay map. Most of these options deal with the various flavors of compression that you can enable over the Frame Relay network if you wish. However, the other two highlighted options are of key importance.

The keywords cisco and ietf define whether the remote router is a Cisco router or some other brand that uses the IETF industry-standard Frame Relay encapsulation. You might have noticed that neither command was entered under the map statement. The Cisco router uses the Cisco Frame Relay encapsulation by default. If you are connecting to non-Cisco routers, be sure to add the ietf keyword to the each map. Now you can move on to the Alaska and Arizona routers:

Take a look at this: On the Arizona and Alaska routers, both remote IP addresses have been mapped to the same DLCI number. This is why you could not use Inverse ARP to solve this whole scenario: It would have detected only the directly connected neighbor—Alabama, in this case. Because I’m still sitting on the Arizona router, I perform the verification from there:

It looks like the LMI information is being received successfully. Now examine the PVC status and mappings:

Based on the output from the show frame-relay pvc and show frame-relay map commands, it looks like DLCI 405 is ACTIVE and statically mapped to both the remote IP addresses it is able to reach. Because it tests round-trip connectivity, the final ping test verifies that the rest of the locations are configured correctly as well:

Success rate is 100 percent (5/5), round-trip min/avg/max = 116/117/124 ms Take a look at that—successful pings everywhere! However, things are not as peachy as they may seem initially. Compare those round trip times for the two destinations. When the first ping was performed from Arizona to Alabama, the average round-trip response time was 58ms. The second ping went from Arizona to Alaska, and the round-trip response time effectively doubled, moving up to 117ms! Although the hub and spoke topologies are very cost effective, they can have devastating effects on delay-sensitive traffic, such as Citrix, Voice over IP, or Video over IP. Now that the Frame Relay network is working correctly, it may be tempting to walk away cheering and feeling quite fantastic about the general state of your life.

However, one more thing needs to be checked. Take a look again at Figure 23.8. Each location has a LAN connection, representing the offices in those locations. Although the Frame Relay network may be humming along, you still need to check the routing tables to ensure each one of these locations is able to reach the other. Behind the scenes, I’ve configured EIGRP for Autonomous System 100 on each router, sending and receiving advertisements on all interfaces. Look at the routing table on Alabama first:

Whew! Everything looks good. As you can see, the highlighted output shows the Alabama router has learned about the networks in Alaska and Arizona just fine. Just to be certain of things, jump over to Arizona and verify the routing table over there.

Uh-oh. That warm, fuzzy feeling is slipping away. It appears that Arizona has learned about only the Alabama network, and is not showing Alaska in the routing table. It’s a good idea to verify the Alaska routing table as well.

Sure enough, Alaska is not learning about the Arizona network either. You have just experienced the split-horizon routing rule taking effect. The Alabama router is acting as the hub of the network. As it receives incoming routing updates on its Serial 0 interface from the Alaska and Arizona routers, the split-horizon rule jumps in and restricts the Alabama router’s capability to send those updates back out of the interface on which it was received.

There are two ways to solve this problem. First, you could move from a multipoint configuration to a pointto-point configuration (the safer, more preferred method), or disable the split-horizon routing rule completely (opening yourself up to the potential of routing loops). Remember, these routing rules have been put in place for a reason. Disabling them is like skydiving without a backup parachute. Most of the time, you should be fine, but just wait until that unusual situation. There may be very little chance of a safe landing.

Because this is a multipoint configuration, you can go ahead and disable the split-horizon features for now. The point-to-point solution is explained in just a moment. You need to be careful to disable split-horizon only at the key points of a network. If you disable it everywhere, you will most certainly end up with routing loops. In this case, you need to disable it at the network hub: Alabama. If you turn it off on this router, the routing updates will be received on the Serial 0 interface and sent right back out the same interface, allowing Arizona and Alaska to hear about each other. Here’s how it’s done:

You can see that turning off split-horizon for the EIGRP routing system caused the neighbors to reset themselves because of the configuration change. Now that they’ve come back up, you can verify the Alaska and Arizona routing tables:

Excellent! The remote sites are now seeing each other’s LAN connections in the routing table. The multipoint Frame Relay configuration is complete.

Configuring Frame Relay That Uses Point-to-Point Interfaces

I’m so excited! All this configuration has led up to this point: my highly suggested and preferred Frame Relay configuration, point-to-point subinterfaces. As you just saw, configuring Frame Relay using multipoint connections can be confusing because you have multiple, non–directly connected sites tied together through a single physical interface. In addition, it can cause some technical problems, primarily with routing protocols. Now, enter point-topoint subinterfaces into the configuration and these problems slowly melt away.

The configuration of point-to-point subinterfaces does require a little more work than multipoint because it requires you to create a logical subinterface for each PVC coming out of your locations. To explain this, let me introduce the next scenario to be configured. It involves setting up a network very similar to the previous, multipoint configuration. This time, a router known as Salmon will be the hub. BlueGill and Trout will act as the spokes. Take a look at the logical diagram in Figure 23.10.

Frame Relay Overview23.10

FIGURE 23.10 Point-to-point Frame Relay configuration.

Can you see the difference between the point-to-point and multipoint configurations at the hub router? Instead of having a single IP address and interface connected to the Frame Relay cloud, you now have two logical subinterfaces connected to the Frame Relay cloud: Serial0/0.503 and Serial0/0.504. Each one of these subinterfaces is on its own subnet. Now, the split-horizon problems from before are automatically solved through the creation of these subinterfaces.

When the router receives a routing update on Serial0/0.503, it has no problem sending it out Serial0/0.504, and vice versa. Now you may argue that it is still sending it out the same physical interface, which is true. However, the router doesn’t see it this way. After you create the two subinterfaces, the router sees them as two completely independent connections.

The only disadvantage of a point-to-point configuration is that you must configure a separate subnet for each PVC, whereas the multipoint allowed all routers to share a common subnet. With that foundation in place, let’s jump straight into the configuration and fill in the gaps as you go. I’m going to begin with the hub of the network: the great Salmon router. First, familiarize yourself with the surroundings:

We’ve just created the subinterface Serial0/0.503 in a point-to-point configuration, as shown in Figure 23.10. The fact that the subinterface number matches the local DLCI used for the connection holds no functional significance whatsoever. It is just a common practice to have your subinterface number match the DLCI number for administrative identification purposes. Now that you are in the subinterface configuration mode, you can set up the logical parameters. This will take just two settings:

The two commands necessary assigned the IP address and the local DLCI number to the subinterface. No complex mappings. No broadcast keywords. Just an IP address and DLCI number. Simple is good. Now add the second subinterface to the configuration and verify how everything looks:

Have you ever had a fresh chocolate chip cookie, pulled right out of the oven, cooked to a golden crisp that literally melts in your mouth? That’s the only thing that might be better than a configuration like this. Look at that!!! You have two logical subinterfaces configured perfectly on their own subnets. The router also knows what DLCI number it is able to use to reach the other side of the connection. One quick note: Have you been noticing how the router moves you into a DLCI configuration mode after you enter the frame-relay interface-dlci command? When you get into the advanced Frame Relay configurations, you will be able to assign certain traffic shaping parameters to each one of those connections that tell the router how fast it should send to each site, among many other things. That’s for the CCNP certification. For now, go ahead and bring up the two spoke routers:

Did you see those DLCIs go ACTIVE? That’s a really good sign that things are working just fine. Behind the scenes, I also configured the EIGRP process on all three routers to include all attached interfaces. Because I’m currently connected to the Trout router, I’ll verify everything is working okay from here:

Sweet! The first ping tested connectivity from the Trout router to the Salmon router. The second ping tested connectivity from the Trout router to the BlueGill router. Finally, by examining the routing table, you can see that the Trout router has already learned about the LANs behind Trout and BlueGill, and has even learned about the PVC between Salmon and BlueGill (this is the last bolded entry in the routing table). This is a key feature of the point-to-point configuration. Because every PVC is seen as its own subnet, routing protocols enable your routers to learn about those connections without requiring the messy maps of multipoint configurations. Just like that, you have a point-to-point Frame Relay configuration.

About the author


Leave a Comment