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: 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: 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: 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:
  1. Verify the physical connection between the CSU/DSU and the router.
  2. Verify that the router and Frame Relay provider are properly exchanging LMI information.
  3. Verify that the PVC status is active.
  4. 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:
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