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 10.8.100.2 255.255.255.252
 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
interfaces

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.