Some apparent link layer problems can be traced to physical layer causes, but others are actually problems in the link layer. The tables in this section will lead you to a physical layer solution where appropriate, because the tables are constructed with symptoms. This section assumes that you have addressed all physical layer problems and that no alarms are present on either side of the link.
When the link layer fails to come up, a common problem is an incorrect clocking setting. One common scenario is that the line has physical connectivity, but no link layer protocol is able to initialize. This usually occurs because the clocking between the CSU/DSU and the router is not configured correctly. Incoming link layer negotiation requests are received by the CSU/DSU and passed out the serial interface to the router. At the router, the requests are processed correctly and responses are sent. If the transmit clocking on the data port is configured incorrectly, however, the response to the incoming configuration request is not received by the CSU/DSU and thus cannot be sent out the T1 network interface. At the remote end, the line appears to be quiet. No physical problems exist and no alarms are present, but no data comes in, either.
Not all routers can supply a transmit clock with the data. If the CSU/DSU is looking for an external transmit clock from the router, it will not read any incoming data, even if that data is supplied according to the transmit clock from the CSU/DSU. Some routers also have significant internal phase delays and must supply an external transmit clock to avoid frequent corrupted bits when the clock trigger falls on the edge of a voltage transition. To be safe, use external (router-supplied) clocking on the data port if it is supported.
Table 11-4 summarizes basic link layer troubleshooting, independent of any particular link layer.
Table 11-4. General link layer problems table
|
Symptom/indication |
Cause |
Corrective action |
|---|---|---|
|
Link layer negotiations fail, even though physical connectivity is established |
Mismatched link layer protocol |
Check that both ends are set to the same link layer protocol; some vendors may default to different link layers. |
|
Remote end not receiving data (verified with packet traces at remote end) |
Check that data is transmitted by the operating system on the DTE, then check clocking settings. If no link layer will initialize correctly even when both ends are switched, clocking is almost surely the culprit. Run a remote loopback test and see if the attempted link layer negotiation frames return to the local end. Not all DTEs support sending a transmit clock with the data. It is relatively common for external CSU/DSUs to take clock from the DTE on the data port, but not all DTEs can supply it. If external clocking is not possible, consider using an inverted internal clock signal. | |
|
Specific to a certain link layer |
See the following sections. |
Generally, the biggest problem with PPP is that not all WAN switches support all the PPP options. Older software revisions may also require the use of older styles of address negotiation within IPCP. Table 11-5 outlines some possible problems.
Table 11-5. PPP troubleshooting
|
Symptom/indication |
Cause |
Corrective action |
|---|---|---|
|
Debugging information shows lots of Configure Naks (null acknowledgments) |
An option in the transmitted PPP configuration request is being rejected |
Decode the negotiation to find out which option is being rejected. Not all vendors fully support magic-number negotiation and MTU/MRU negotiation. |
|
The DTE is receiving the same magic number as it is sending |
Magic numbers prevent looped-back lines from coming up. If magic number collisions are occurring, check the line for loopbacks. |
Frame relay depends on the Local Management Interface (LMI) to bring the link up. Unfortunately, three common LMI flavors exist. ANSI specifies one, the ITU specifies another, and the Frame Relay Forum, an industry consortium, specifies a third. Before standards bodies produced any standard, four vendors defined an LMI flavor in a semiformal setting, which became known as the Gang of Four LMI. Most frame relay problems are due to misconfiguration of the LMI type or the local DLCI; frame relay troubleshooting is distilled in Table 11-6.
Table 11-6. Frame relay troubleshooting
|
Symptom/indication |
Cause |
Corrective action |
|---|---|---|
|
Unanswered LMI configuration requests |
Mismatched LMI type. |
Check the LMI type with the frame relay carrier. Look at the DLCI on which the LMI messages are transmitted—standards-based LMIs are transmitted on DLCI 0, while the original Gang of Four specification was transmitted on DLCI 1023. |
|
Incorrect DLCI specified at local end. |
Check the local DLCI with the carrier. If you can capture and decode an LMI message from the frame switch, it is possible to determine which DLCI the frame cloud is expecting. | |
|
Local DTE does not support the frame relay feature being used. |
Frame relay is a complex set of specifications, and equipment vendors may not always support the feature you have tried to configure. Call the vendor and put in a feature request. | |
|
LMI does not detect PVC failure |
LMI is a local management interface. Even LMI Annex G may not check the full path. |
Use a routing protocol to ensure end-to-end checks on PVC integrity and take action to reroute traffic when appropriate. |
HDLC is by far the simplest of the link layer protocols commonly run on WAN circuits. It does not have any substantial negotiation procedures, which means that any problems observed on HDLC links are likely due to underlying physical problems with the circuit (or a misconfiguration of the link layer encapsulation on the circuit itself). Troubleshooting is described in Table 11-7.
Table 11-7. HDLC troubleshooting