associated with the DLCI is not capable of communication end-to-end. Usually this indicates that the router on the far side of the PVC is not configured correctly. A Frame-Relay status of “deleted” indicates that the Frame-Relay switch is not reporting the DLCI configured on the serial interface. Suggested troubleshooting steps are:

Check that the physical layer is up.
Verify a working LMI with the show frame-relay lmi command.

If these steps indicate that the router is communicating successfully with the Frame-Relay switch, then the “deleted” status indicates that the Frame-Relay switch is not reporting the DLCI as being available. Therefore, the router interprets that the telco has “deleted” it. The most likely cause for this problem is a misconfigured DLCI on either the router or at the telco.

Content 4.5 Troubleshooting Frame Relay 4.5.4 Frame Relay encapsulation type If none of the previous steps have solved the Frame Relay issue, the problem may be related to Frame Relay encapsulation. Cisco routers default to cisco Frame Relay encapsulation, which is valid only between other Cisco routers that are using cisco Frame Relay encapsulation. If connecting to a third-party router, the Frame Relay encapsulation must be changed from cisco to ietf. To configure ietf Frame Relay encapsulation, replace the encapsulation frame-relay command with encapsulation frame-relay ietf.

Content 4.5 Troubleshooting Frame Relay 4.5.5 Troubleshooting Frame Relay using the line status Further information on the status of Frame-Relay can be determined from the show interface command. There are four common line status conditions:

Interface is down, line protocol is down
Interface is up, line protocol is down
Interface is up, line protocol is up
Interface is administratively down

The output ‘serial0/0 is down, line protocol is down’ indicates a problem with the CSU/DSU or the serial line. Troubleshoot the problem with a loopback test using the following steps:

Set the serial line encapsulation to HDLC and keepalive to 10 seconds. The commands to accomplish this are interface configuration commands encapsulation hdlc and keepalive 10.
Place the CSU/DSU or modem in local loop mode. Look for a "line protocol is up (looped)" message. If the line protocol comes, this would suggest that the problem is occurring beyond the local CSU/DSU. If the status line does not change states, look for a problem in the router, connecting cable, CSU/DSU or modem. In most cases, the problem is with the CSU/DSU or modem.
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 synchronization. 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 pings fail or if there are cyclic redundancy check (CRC) errors, a bit error rate tester (BERT) with an appropriate analyzer from the telco is needed.

When testing is complete, change the encapsulation back to Frame Relay. The output ‘serial0/0 is up, line protocol is down’ means that the router is getting a carrier signal from the CSU/DSU or modem but Layer 2 communication has failed. Troubleshoot the problem using the following steps:

Check to make sure the Frame Relay provider has activated their port. Verify that the router and telco LMI settings match. Generally, the Frame Relay switch ignores the data terminal equipment (DTE) unless it sees the correct 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.

Unless keepalives have been turned off, the output ‘serial0/0 is up, line protocol is up’ means that the router is talking with the provider’s Frame Relay switch. The router should indicate a successful exchange of two-way traffic on the serial interface, with no CRC errors. The output ‘serial0/0 is down, line protocol is up’ is not possible. Keepalives are necessary in Frame Relay because they are the mechanism that the router uses to "learn" which DLCIs the provider has provisioned. To watch the exchange, the debug frame-relay lmi command can be used in almost all situations. The debug frame-relay lmi command generates very few messages, but can provide answers to questions such as:

Is the Cisco Router talking to the local Frame Relay switch?
Is the router getting full LMI status messages for the subscribed permanent virtual circuits (PVCs) from the Frame Relay provider?
Are the DLCIs correct?

Refer to Figure for a sample debug frame-relay lmi output from a successful connection. Notice the status of DLCI 980 in the output. The possible values of the status field are explained in Figure .

Content 4.5 Troubleshooting Frame Relay 4.5.6 Ping the local IP address on a multipoint Frame Relay A ping performed on the local IP address on a multipoint Frame Relay interface does not work. This is because Frame Relay multipoint physical and subinterfaces are non-broadcast. Recall that Ethernet and point-to-point interfaces such as High-Level Data Link Control (HDLC) and Frame Relay point-to-point sub-interfaces are broadcast. Because multipoint interfaces can have multiple destinations, the router must have a mapping for every destination. The router does not have any Layer 3 to Layer 2 mapping for its own address and does not know how to encapsulate the packet. An encapsulation failure results.Furthermore, ping is unsuccessful from one spoke to another in a hub and spoke configuration. This is because there is no mapping for the local IP address, and none were learned by way of Inverse ARP. But if a static map is configured with the frame-relay map command for the local IP address or one for the remote spoke to use the local DLCI, ping will be successful. Before adding the static Frame-Relay map, the result of pinging a local interface will be as follows: Router#ping 3.1.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.1.3.3, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5) In order to permit the pinging of local Frame-Relay interfaces, the following static map command must be added: Router#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router(config)#interface serial 0/1
Router (config-if)#frame-relay map ip 3.1.3.3 160 This can be verified using the show frame-relay map command: Router#show frame-relay map
Serial0/1 (up): ip 3.1.3.1 dlci 180(0xA0,0x2800), dynamic, broadcast, status defined, active
Serial0/1 (up): ip 3.1.3.2 dlci 160(0xA0,0x2800), static, CISCO, status defined, active
Serial0/1 (up): ip 3.1.3.3 dlci 160(0xA0,0x2800), static, CISCO, status defined, active It will now be possible to ping the local interface: Router#ping 3.1.3.3 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 3.1.3.3, timeout is 2 seconds:
!!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 64/68/76 ms The running configuration file for Serial 0/1 is reproduced below: interface Serial0/1
ip address 3.1.3.3 255.255.255.0
no ip directed-broadcast
encapsulation frame-relay
frame-relay map ip 3.1.3.2 160
frame-relay map ip 3.1.3.3