Troubleshoot problems with frame-relay circuits on your Cisco router

While frame relay offers several benefits, it also has its share of problems. How do you begin troubleshooting problems with frame-relay circuits? David Davis introduces a common scenario and walks you through the various steps of troubleshooting the problem.

Frame relay is a popular service provided by telecommunication carriers to help businesses of all sizes communicate through a private network. While frame relay is a more reliable and less complex choice than Internet VPN connections, it generally costs more.

However, with any frame-relay circuit, you'll likely run into trouble at some point in time. To help you prepare for such a time, let's look at a common scenario and discuss how to begin troubleshooting. I'll assume that you have a basic understanding of frame relay and its terminology.

Here's the situation

You're having trouble with an existing frame-relay circuit on one of your remote routers. Users have reported slow and intermittent connections across the circuit. (Of course, if your circuit is really down—not just experiencing intermittent trouble—the troubleshooting process can be much easier.)

You Telnet to the router, and find the configuration on the frame-relay circuit using the show running-configuration command. Here's an example:

interface Serial3/0
 bandwidth 56
 no ip address
 encapsulation frame-relay IETF
 no ip mroute-cache
 no fair-queue ! interface Serial3/0.1 point-to-point
 bandwidth 56
 ip address
 no ip mroute-cache
 no cdp enable
 frame-relay interface-dlci 30 IETF  

Now that we've got an idea of the scenario, let's discuss how you can begin troubleshooting to figure out what's going on.

Check the router's log

In our scenario, users are saying that they've been losing connectivity and experiencing slow responses. The key here is that while they have experienced these problems at one point, the issue isn't currently occurring.

So, since the problem happened in the past, it's a good idea to check the router's log to see if it can offer any clues. To do so, user the show logging command. Listing A shows an example of what the log file may look like.

In the log file, we can see that Interface Serial 3/0 went down and came back up a number of times. This caused the sub-interfaces—connected to certain frame-relay permanent virtual circuits (PVCs)—to bounce as well.

So, now we know that the circuit has been bouncing, and this is, almost certainly, the cause of the slow response and intermittent connection. So where do we go from here?

By design, frame relay usually involves a point-to-point sub-interface method. Frame-relay sub-interfaces correspond to a particular PVC and a data link connection identifier (DLCI) number on that PVC.

Because of this, an interesting aspect of frame relay is that the main interface (in our example, Serial 3/0) can remain up even while sub-interfaces bounce. In theory, if one PVC (sub-interface) bounces, then the other side should as well—but this isn't always the case. Sometimes one side of a PVC stays up when the other is down.

In our example, we can determine from the log file that both the main serial interface and the sub-interface went down and came back up at the same time. At this point, you know that you have a physical circuit issue, and you could open a ticket with your frame-relay carrier. But first, let's keep investigating this issue, and see what else we can find out.

Check for errors on your

So far, we've learned from the log file that the router didn't lose power during this time period and that the other interfaces remained up. Therefore, it doesn't appear to be a LAN switch issue, so let's keep looking.

To check for interface errors, enter the show interface command. Listing B offers a truncated example of the output from this command. (By the way, you can get information about specific interfaces by specifying the interface adapting the show interface serial 0/0 command.)

So what does this output tell us? First, we can see that the router is not overusing the circuit, which you can tell from the line below. Many times, overutilization can appear to be circuit-bouncing or other errors, but they are totally different issues.

txload 4/255, rxload 4/255

We can also tell from the output that the interface has been taking errors since the last clearing of the statistics or the last reboot. Specifically, it showed 133 input errors and 345 CRC errors. Of course, these errors have accumulated since the last reboot, so we don't know whether they're old or recent.

Finally, the output tells us that the circuit has bounced eight times since the last statistics clearing or reboot. We know this from the following line in the output:

8 carrier transitions

Check statistics for frame relay

Now that we've gathered information about interface errors, it's time to look at some frame-relay statistics. You can use the show frame-relay pvc command to view all of the currently configured PVCs on the router as well as frame-relay statistics.

Another helpful command you can use is the show frame-relay lmi command. Local management interface (LMI) is the management protocol for frame relay.

When checking LMI statistics, it's important to look for any statistic that starts with Invalid. This tells you that there's a frame-relay error in communications between the carrier's switch and your router. Listing C provides sample outputs from both commands.

From this output, we can see that the PVC has only been up for one day, which means that the frame-relay switch lost contact with the router. We can also see the 5-minute output rate and input rate, which shows whether the circuit is overutilized. Again, while this is not the case for our example, it can be a cause for why users are complaining about a circuit.

In this example, we have only one PVC. However, sometimes you have multiple PVCs, such as a primary and a backup. Sometimes the primary PVC could be down, and the site could be running on a backup PVC. Or all PVCs could be down, and the site could be running on a dial backup circuit and not know it.

Clear the statistics and gather them again

At this point, use the clear counters command to wipe out all of these statistics. Next, rerun the show commands again in 10 minutes to see whether any more errors have occurred.

Have this information ready to provide to the carrier when you open a ticket. As always when working with providers, it's a best practice to provide as much information as possible. Saying "we're experiencing CRC errors" (as compared to something like "the circuit has bounced a few times") provides more details, and it tells the carrier that you have some sort of physical error problem that probably isn't going to go away.

Miss a column?

Check out the Cisco Routers and Switches Archive, and catch up on David Davis' most recent columns.

Want to learn more about router and switch management? Automatically sign up for our free Cisco Routers and Switches newsletter, delivered each Friday!

David Davis has worked in the IT industry for 12 years and holds several certifications, including CCIE, MCSE+I, CISSP, CCNA, CCDA, and CCNP. He currently manages a group of systems/network administrators for a privately owned retail company and performs networking/systems consulting on a part-time basis.

Editor's Picks

Free Newsletters, In your Inbox