Verifying Frame Relay

Verifying Frame Relay

Objective:

  • Configure and verify Frame Relay on Cisco routers

As you have gone through the three different configurations of Frame Relay, you have really seen the Frame Relay verification commands in action. However, it’s time for a formal introduction of the three major commands you use when ensuring all is well with your Frame Relay configuration.

show frame-relay lmi

This command enables you to verify your communication with the Frame Relay service provider.

Notice that the Num Status Enq. Sent and Num Status msgs Rcvd fields are relatively the same. This indicates that your communication with the service provider is excellent.

show frame-relay pvc

This command enables you to see, in detail, all the PVC connections your router has established through the cloud.

The main information you’ll grab from this output is the status of the circuit (shown here as ACTIVE) and the DLCI number (shown here as 405). It’s sometimes nice to see the packet statistics for the PVCs as well to ensure traffic is passing between your locations.

show frame-relay map

This command is my favorite command to verify my Frame Relay circuits.

This is the most concise way of finding out your DLCI number and the state of the circuit, without being overwhelmed with all the statistics for the line.

Troubleshooting Frame Relay

Objective:

  • Troubleshoot WAN implementation issues

Alas, when all is not well with your Frame Relay connections, the debug commands come to the rescue. Thankfully, for most troubleshooting scenarios, there is just one debug command that can expose the problem. Before you get into the debug, though, you’ll quickly see that the standard show commands from the verification section can give quite a bit of useful information. Take a look:

Just a simple show frame-relay map command can point you in the initial direction for troubleshooting the circuit. As you can see from the output, there are three different DLCI numbers in three different activity states. First up is DLCI 407, which is in a status of DELETED. This means that the router is attempting to communicate with the service provider through DLCI 407, but the service provider has no idea what the router is talking about. They have no DLCI 407 defined. In this case, the configuration problem is most likely on your own router. Typing the DLCI number incorrectly is one likely cause. Otherwise, the service provider dropped the ball and did not accurately set up the connections.

The second DLCI in the list is DLCI 405, which is in a status of ACTIVE. This is a good circuit, going through to the other end of the connection. The final DLCI in the list is DLCI 406, which is in a status of INACTIVE. This means that the end of the connection is configured, and the service provider recognizes the DLCI you are attempting to use. The other end of the connection is where the problem lies. They have either configured an incorrect DLCI or have not configured the interface at all. Just from this initial output, you can figure out a direction or a location to begin your troubleshooting efforts. Now comes the lower-level debug troubleshooting.

The most useful debug is typically the debug frame-relay lmi because this focuses on your direct communication with the service provider. At first, this output looks quite cryptic, but take a look at the highlighted information. You can see the sequence numbers increasing on your end (that’s the myseq field), but the service provider doesn’t see this. This most likely indicates that the Frame Relay LMI language is mismatched between you and the service provider. Here’s how to fix the problem:

Sure enough, you saw that the LMI type was hard-coded as ANSI. After it was changed over to Cisco, the debug showed the sequence numbers matching up between your router and the service provider. Right after the sequence number synchronization, the service provider’s router delivers the DLCI information to your router. This is where it pays to know the status codes. These are not covered on the CCNA exam, but are tested on when you get into the CCNP level exams:

In this case, you can see that both DLCI 503 and 504 are marked as INACTIVE. Most of the Frame Relay troubleshooting comes from a misconfiguration of the Frame Relay DLCI. It’s very easy to map the wrong DLCI to the wrong IP address because Frame Relay uses a very different addressing perspective than most other networking technologies. Understanding the Frame Relay circuit states can really help in isolating the problem quickly.

About the author

Prasanna

Leave a Comment