Config Router

You are here: Home / CCNA / Verifying Frame Relay

Verifying Frame Relay

by

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.

Salmon#show frame-relay lmi
LMI Statistics for interface Serial0/0 (Frame Relay DTE) LMI TYPE = CISCO
Invalid Unnumbered info 0 Invalid Prot Disc 0
Invalid dummy Call Ref 0 Invalid Msg Type 0
Invalid Status Message 0 Invalid Lock Shift 0
Invalid Information ID 0 Invalid Report IE Len 0
Invalid Report Request 0 Invalid Keep IE Len 0
Num Status Enq. Sent 258 Num Status msgs Rcvd 259
Num Update Status Rcvd 0 Num Status Timeouts 0
Last Full Status Req 00:00:07 Last Full Status Rcvd 00:00:07

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.

 Trout#show frame-relay pvc
PVC Statistics for interface Serial0/0 (Frame Relay DTE)
Active Inactive Deleted Static
Local 1 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 405, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE =
ÂSerial0/0.405
input pkts 643 output pkts 638 in bytes 54196
out bytes 51074 dropped pkts 0 in pkts dropped 0
out pkts dropped 0 out bytes dropped 0
in FECN pkts 0 in BECN pkts 0 out FECN pkts 0
out BECN pkts 0 in DE pkts 0 out DE pkts 0
out bcast pkts 624 out bcast bytes 49746
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
pvc create time 00:45:12, last time pvc status changed 00:45:12

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.

Stitch#show frame-relay map
Serial0/0.405 (up): point-to-point dlci, dlci 405(0x195,0x6450), broadcast
status defined, active

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:

 Stitch#show frame-relay map
Serial0/0.407 (down): point-to-point dlci, dlci 407(0x197,0x6470), broadcast
status deleted
Serial0/0.405 (up): point-to-point dlci, dlci 405(0x195,0x6450), broadcast
status defined, active
Serial0/0.406 (down): point-to-point dlci, dlci 406(0x196,0x6460), broadcast
status defined, inactive

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.

Salmon#debug frame-relay lmi
Frame Relay LMI debugging is on
Displaying all Frame Relay LMI data
*Mar 1 00:05:07.215: Serial0/0(out): StEnq, myseq 1, yourseen 0, DTE down
*Mar 1 00:05:07.215: datagramstart = 0x1DA2F74, datagramsize = 14
*Mar 1 00:05:07.215: FR encap = 0x00010308
*Mar 1 00:05:07.215: 00 75 95 01 01 01 03 02 01 00
*Mar 1 00:05:17.215: Serial0/0(out): StEnq, myseq 2, yourseen 0, DTE down
*Mar 1 00:05:17.215: datagramstart = 0x1C01254, datagramsize = 14
*Mar 1 00:05:17.215: FR encap = 0x00010308
*Mar 1 00:05:17.215: 00 75 95 01 01 00 03 02 02 00
*Mar 1 00:05:27.215: Serial0/0(out): StEnq, myseq 3, yourseen 0, DTE down
*Mar 1 00:05:27.215: datagramstart = 0x1DA21B4, datagramsize = 14
*Mar 1 00:05:27.215: FR encap = 0x00010308
*Mar 1 00:05:27.215: 00 75 95 01 01 00 03 02 03 00
*Mar 1 00:05:37.215: Serial0/0(out): StEnq, myseq 4, yourseen 0, DTE down
*Mar 1 00:05:37.215: datagramstart = 0x1C00494, datagramsize = 14
*Mar 1 00:05:37.215: FR encap = 0x00010308
*Mar 1 00:05:37.215: 00 75 95 01 01 00 03 02 04 00

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:

Salmon#show frame-relay lmi
LMI Statistics for interface Serial0/0 (Frame Relay DTE) LMI TYPE = ANSI
Invalid Unnumbered info 0 Invalid Prot Disc 0
Invalid dummy Call Ref 0 Invalid Msg Type 0
Invalid Status Message 0 Invalid Lock Shift 0
Invalid Information ID 0 Invalid Report IE Len 0
Invalid Report Request 0 Invalid Keep IE Len 0
Num Status Enq. Sent 49 Num Status msgs Rcvd 14
Num Update Status Rcvd 0 Num Status Timeouts 34
Salmon#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Salmon(config)#interface serial 0/0
Salmon(config-if)#
*Mar 1 00:08:47.215: Serial0/0(out): StEnq, myseq 23, yourseen 0, DTE down
*Mar 1 00:08:47.215: datagramstart = 0x1C019D4, datagramsize = 14
*Mar 1 00:08:47.215: FR encap = 0x00010308
*Mar 1 00:08:47.215: 00 75 95 01 01 00 03 02 17 00
*Mar 1 00:08:47.215:
Salmon(config-if)#frame lmi-type cisco
*Mar 1 00:08:57.215: Serial0/0(out): StEnq, myseq 1, yourseen 0, DTE down
*Mar 1 00:08:57.215: datagramstart = 0x1DA2BB4, datagramsize = 13
*Mar 1 00:08:57.215: FR encap = 0xFCF10309
*Mar 1 00:08:57.215: 00 75 01 01 00 03 02 01 00
*Mar 1 00:08:57.227: Serial0/0(in): Status, myseq 1
*Mar 1 00:08:57.227: RT IE 1, length 1, type 0
*Mar 1 00:08:57.227: KA IE 3, length 2, yourseq 1 , myseq 1
*Mar 1 00:08:57.227: PVC IE 0x7 , length 0x6 , dlci 503, status 0x0 , bw 0
*Mar 1 00:08:57.227: PVC IE 0x7 , length 0x6 , dlci 504, status 0x0 , bw 0
*Mar 1 00:09:07.215: Serial0/0(out): StEnq, myseq 2, yourseen 1, DTE down
*Mar 1 00:09:07.215: datagramstart = 0x1DA22F4, datagramsize = 13
*Mar 1 00:09:07.215: FR encap = 0xFCF10309
*Mar 1 00:09:07.215: 00 75 01 01 01 03 02 02 01
*Mar 1 00:09:07.235: Serial0/0(in): Status, myseq 2
*Mar 1 00:09:07.235: RT IE 1, length 1, type 0
*Mar 1 00:09:07.235: KA IE 3, length 2, yourseq 2 , myseq 2
*Mar 1 00:09:07.235: PVC IE 0x7 , length 0x6 , dlci 503, status 0x0 , bw 0
*Mar 1 00:09:07.235: PVC IE 0x7 , length 0x6 , dlci 504, status 0x0 , bw 0

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:

Status 0x0 = INACTIVE
Status 0x2 = ACTIVE
Status 0x4 = DELETED

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.