outage is restored and multiple ISDN devices
simultaneously try to establish a connection. The timer can be
cleared by manually shutting down the BRI interface and
reactivating it. The delayed behavior can be changed using the
isdn twait-disable interface configuration command. The
debug isdn q921 command can also be used to
troubleshoot Layer 2 isdn issues. This command will show the
Layer 2 exchanges between the router and the telco’s ISDN
switch. However, the show isdn status command will
normally be of more use as it effectively decodes the Q921
messages and displays them in a more understandable format.
Content 4.4 Troubleshooting ISDN
4.4.4 Troubleshooting ISDN BRI dialer problems
Assuming that the show isdn status command indicates
that communications between the router and the telco’s switch
is performing correctly, the next step is to ensure that the
router is actually dialing the far end. The most effective way
of troubleshooting dialing is to use the debug dialer
command and then try to establish a call to the remote site. A
common symptom is that the debug dialer command reveals
no dialer activity. This almost always points to one of the
following: - Interesting traffic has not been defined or
is incorrect.
- No dialer map is present or the IP
address is incorrect.
- The router has no route to the
IP address being pinged.
If the debug
dialer events command reveals no dialer activity ,
use the show running-config command to verify
that the following commands are present and are configured with
the appropriate parameters: - Dialer list
- Dialer Map
- Appropriate routing protocol or static
route such that the next hop IP address matches the dialer
map
Assuming that the router is actually attempting
to dial, Figure lists a number of possible error messages and
their causes. In the event that dialing occurs and yet
connectivity fails, there are several possible causes
including: - Remote ISDN service line is busy.
- Incorrect or missing ISDN phone number.
- Incorrect
encapsulation.
- Incorrect authentication parameters.
The first two problems will prevent a call being
established, while the last two will establish the call only to
have it terminated due to Layer 2 errors. To help determine
which of these problems is being experienced, try to
ping the remote site. If the line protocol fails to change
to an up state, even briefly, then it is likely that the ISDN
call itself is failing. If the line comes up and then goes down
it is more likely that configuration incompatibilities are
terminating the call shortly after it is established. If the
line protocol goes up and down several times, once for every
echo request, an authentication failure would be a strong
suspect. For more information on troubleshooting PPP
authentication refer to the Troubleshooting PPP authentication
section. Authentication problems have this characteristic
because a failed authentication attempt will immediately
terminate the call. This occurs so quickly that next ping
packet is able to reinitiate a new call. By contrast,
misconfigured parameters such as encapsulation terminate the
call only after several keepalives have been missed.
Content 4.4 Troubleshooting ISDN 4.4.5
Debugging ISDN call setup failures If it appears that
the router is attempting to dial but calls are not getting
through, the problem can be investigated further using the
debug isdn q931 command. This command will provide
information on the ISDN call status as reported to the router
by the telco’s ISDN switch. A simple test is to execute
debug isdn q931 on both routers to determine whether the
far end router is actually receiving the call. Look for any
q931 debug output. Further explicit information about the call
failure will be provided in the debug messages. Although the
debug output reports the basic reasons for a disconnect, more
detailed information may be required. Aug 13 18:23:14.734: ISDN
BR0: RX <- RELEASE_COMP pd = 8 callref = 0x86 Aug 13
18:23:14.742: Cause i = 0x829C - Invalid number format
(incomplete number) The first most significant byte after 0x
indicates where in the circuit path the Disconnected Cause Code
was generated. In the example above, 82 indicates the call was
disconnected from the local telco switch. The list below
defines the Cause Code Origination Points to help interpret
where the call was disconnected: The next byte in the above
example that follows the Cause Code Origination Point byte, 9C,
is the Disconnect Cause Code and is significant in
troubleshooting. Use the Disconnect Cause Code file in Resource
below to associate a Disconnect Cause Code (in Hex) and the
Cause Description to determine the disconnect reason. For the
debug isdn q931 command output, drop the highest bit of
the cause value before using this table. For example, a cause
value of 0x90 becomes 0x10. Resources PDF: ISDN
Disconnect Casue Code
Content 4.5
Troubleshooting Frame Relay 4.5.1 Steps for
troubleshooting Frame Relay When Frame Relay is properly
provisioned by the service provider, the installation of a
Frame Relay network using Cisco routers is usually a
trouble-free task involving minimal configuration. However, if
problems arise in the Frame Relay network proven techniques can
be applied to isolate and solve them. Troubleshooting Frame
Relay network issues can be broken down into four easy steps:
- Verify the physical connection between the CSU/DSU and
the router.
- Verify that the router and Frame Relay
provider are properly exchanging LMI information.
- Verify that the PVC status is active.
- Verify that
the Frame Relay encapsulation matches on both routers.
There are numerous diagnostic tools available for these
tasks. However, most Frame Relay problems can be diagnosed by
using the following simple commands: - show
interfaces
- show frame-relay lmi
- show frame-relay pvc
- show frame-relay
map
- debug frame-relay lmi
- debug frame-relay events
- debug
frame-relay packet
Content 4.5
Troubleshooting Frame Relay 4.5.2 The show
frame-relay lmi command The show frame-relay lmi
command is invaluable for determining the status of the link
between the router and the Frame-Relay switch. Examine the
output from item A to determine the locally configured LMI
type. An incrementing “Num Status Enq. Sent” and “Received”
indicates that successful router to Frame-Relay switch
communications are occurring. If the router is sending status
messages but not receiving them, then check the physical layer
between the router and the Frame Relay switch. Ensure that the
LMI encapsulation used by the router and the Frame Relay switch
are the same. By default, the LMI type used by the IOS is set
to Cisco.
Content 4.5 Troubleshooting Frame
Relay 4.5.3 The show frame-relay pvc
command Use the show frame-relay pvc command to
verify the PVC status and end-to-end connectivity of the
routers. The three likely PVC status messages are:
Understanding the status of a PVC will quickly focus the
troubleshooting effort. A Frame-Relay PVC status of “active”
indicates Frame-Relay end-to-end connectivity at Layer 2 and is
associated with a working Frame-Relay circuit. If the status is
“active” and problems are occurring, attention should be given
to Layer 3 issues such as mapping IP addresses to DLCIs and
telco DLCI allocations. Note in Figure PVC 30 is “active”. This
indicates end-to-end connectivity. PVC 21 is still inactive,
which indicates a problem. A PVC status of “inactive” suggests
that the router recognizes the DLCI configured on its interface
as being present on the Frame Relay switch, but the PVC