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