Troubleshooting Frame Relay

Troubleshooting Frame Relay

This section contains portions of possible show interface command output you may encounter while troubleshooting. Explanations of the output are provided as well.

"Serial0 is down, line protocol is down"

This output means you have a problem with the cable, channel service unit/data service unit (CSU/DSU), or the serial line. You need to troubleshoot the problem with a loopback test. To do a loopback test, follow the steps below:

1. Set the serial line encapsulation to HDLC and keepalive to 10 seconds. To do so, issue the commands encapsulation hdlc and keepalive 10 under the serial interface.

2. Place the CSU/DSU or modem in local loop mode. If the line protocol comes up when the CSU, DSU or modem is in local loopback mode (indicated by a "line protocol is up (looped)" message), it suggests that the problem is occurring beyond the local CSU/DSU. If the status line does not change states, there is possibly a problem in the router, connecting cable, CSU/DSU or modem. In most cases, the problem is with the CSU/DSU or modem.

3. Ping your own IP address with the CSU/DSU or modem looped. There should not be any misses. An extended ping of 0x0000 is helpful in resolving line problems since a T1 or E1 derives clock from data and requires a transition every 8 bits. B8ZS ensures that. A heavy zero data pattern helps to determine if the transitions are appropriately forced on the trunk. A heavy ones pattern is used to appropriately simulate a high zero load in case there is a pair of data inverters in the path. The alternating pattern (0x5555) represents a "typical" data pattern. If your pings fail or if you get cyclic redundancy check (CRC) errors, a bit error rate tester (BERT) with an appropriate analyzer from the telco is needed.

4. When you are finished testing, make sure you return the encapsulation to Frame Relay.

"Serial0 is up, line protocol is down"

This line in the output means that the router is getting a carrier signal from the CSU/DSU or modem. Check to make sure the Frame Relay provider has activated their port and that your Local Management Interface (LMI) settings match. Generally, the Frame Relay switch ignores the data terminal equipment (DTE) unless it sees the correct LMI (use Cisco's default to "cisco" LMI). Check to make sure the Cisco router is transmitting data. You will most likely need to check the line integrity using loop tests at various locations beginning with the local CSU and working your way out until you get to the provider's Frame Relay switch. See the previous section for how to perform a loopback test.

"Serial0 is up, line protocol is up"

If you did not turn keepalives off, this line of output means that the router is talking with the Frame Relay provider's switch. You should be seeing a successful exchange of two-way traffic on the serial interface with no CRC errors. Keepalives are necessary in Frame Relay because they are the mechanism that the router uses to "learn" which data-link connection identifiers (DLCIs) the provider has provisioned. To watch the exchange, you can safely use debug frame-relay lmi in almost all situations. The debug frame-relay lmi command generates very few messages and can provide answers to questions such as:

1. Is the Cisco Router talking to the local Frame Relay switch?

2. Is the router getting full LMI status messages for the subscribed permanent virtual circuits (PVCs) from the Frame Relay provider?

3. Are the DLCIs correct?

Here's some sample debug frame-relay lmi output from a successful connection:

*Mar  1 01:17:58.763: Serial0(out): StEnq, myseq 92, yourseen 64, DTE up
*Mar  1 01:17:58.763:  datagramstart = 0x20007C, datagramsize = 14
*Mar  1 01:17:58.763:  FR encap = 0x0001030800 75 95 01 01 01 03 02 5C 40 
*Mar  1 01:17:58.767: 
*Mar  1 01:17:58.815: Serial0(in): Status, myseq 92
*Mar  1 01:17:58.815: RT IE 1, length 1, type 1
*Mar  1 01:17:58.815: KA IE 3, length 2, yourseq 65, myseq 92
*Mar  1 01:18:08.763: Serial0(out): StEnq, myseq 93, yourseen 65, DTE up
*Mar  1 01:18:08.763:  datagramstart = 0x20007C, datagramsize = 14
*Mar  1 01:18:08.763:  FR encap = 0x0001030800 75 95 01 01 01 03 02 5D 41 
*Mar  1 01:18:08.767: 
*Mar  1 01:18:08.815: Serial0(in): Status, myseq 93
*Mar  1 01:18:08.815: RT IE 1, length 1, type 1
*Mar  1 01:18:08.815: KA IE 3, length 2, yourseq 66, myseq 93
*Mar  1 01:18:18.763: Serial0(out): StEnq, myseq 94, yourseen 66, DTE up
*Mar  1 01:18:18.763:  datagramstart = 0x20007C, datagramsize = 14
*Mar  1 01:18:18.763:  FR encap = 0x0001030800 75 95 01 01 00 03 02 5E 42 
*Mar  1 01:18:18.767: 
*Mar  1 01:18:18.815: Serial0(in): Status, myseq 94
*Mar  1 01:18:18.815: RT IE 1, length 1, type 0
*Mar  1 01:18:18.819: KA IE 3, length 2, yourseq 67, myseq 94
*Mar  1 01:18:18.819: PVC IE 0x7 , length 0x3 , dlci 980, status 0x2

Notice the status of "DLCI 980" in the output above. The possible values of the status field are explained below:

1. 0x0-Added/inactive means that the switch has this DLCI programmed but for some reason (such as the other end of this PVC is down), it is not usable.

2. 0x2-Added/active means the Frame Relay switch has the DLCI and everything is operational. You can start sending it traffic with this DLCI in the header.

3. 0x3-0x3 is a combination of an active status (0x2) and the RNR (or r-bit) that is set (0x1). This means that the switch - or a particular queue on the switch - for this PVC is backed up, and you stop transmitting in case frames are spilled.

4. 0x4-Deleted means that the Frame Relay switch doesn't have this DLCI programmed for the router. But it was programmed at some point in the past. This could also be caused by the DLCIs being reversed on the router, or by the PVC being deleted by the telco in the Frame Relay cloud. Configuring a DLCI (that the switch doesn't have) will show up as a 0x4.

5. 0x8-New/inactive

6. 0x0a-New/active