ping can determine whether a serial link can or cannot forward IP packets.
The best way to isolate which layer is the most likely cause of the problem is to examine the interface status code. Router interfaces have two status codes, line status and protocol status.
Interface Status Codes and Typical Meanings When a Ping Does Not Work:
|Line Status||Protocol Status||Likely Reason/Layer|
|Administratively down||Down||Interface is shut down|
The serial link verification and troubleshooting process should begin with a simple three-step process:
Step 1: From one router, ping the other router’s serial IP address.
Step 2: If the ping fails, examine the interface status on both routers, and investigate the problems related to the likely problem areas.
Step 3: If the ping works, also verify that any routing protocols are exchanging routes over the link.
The interface status codes can be found using the show interfaces, show ip interface brief and show interfaces description commands.
Troubleshooting Layer 1 Problems
The interface status codes, or interface state, play a key role in isolating the root cause of problems on serial links. In fact, the status on both ends of the link may differ, so it is important to examine the status on both ends of the link to help determine the problem.
One simple and easy-to-find Layer 1 problem occurs when either one of the two routers has administratively disabled its serial interface with the shutdown interface subcommand. If a router’s serial interface is an an administratively down line status, just issue a no shutdown on the interface. If one router’s interface has a line status of down, the other router may be shut down, so check both sides of the link.
The combination of a down line status on both ends of the serial link typically points to a Layer 1 problem. Most likely reasons:
* The leased line is down (telco problem).
* The line from the telco is not plugged in to either or both CSU/DSUs.
* A CSU/DSU has failed or is misconfigured.
* A serial cable from a router to its CSU/DSU is disconnected or faulty.
One other common physical layer problem can occur that results in both routers’ interfaces being in an up/down state. On a back-to-back serial link, if the required clock rate command is missing on the router with a DCE cable, both router’s serial interfaces will fail and end up with a line status of up but a line protocol status of down. The best ways to find this problem are to notice the absence of the clock rate command on the router with the DCE cable and to note the “no clock” phrase in the output of the show controllers serial command.
Troubleshooting Layer 2 Problems
When both routers’ serial line status is up, but at least one of the routers’ line protocol status is down or continually switches between up/down, the interface probably has one of two types of data link layer problems.
Likely Reasons for Data-Link Problems on Serial Links:
|Line Status||Protocol Status||Likely Reason|
|Up||Down (stable) on both ends or Down (stable) on one end, flapping between up and down on the other||Mismatched encapsulation commands|
|Up||Down on one end, up on another||Keepalive is disabled on the end in an up state|
|Up||Down (stable) on both ends||PAP/CHAP authentication failure|
show interfaces lists the encapsulation type in the seventh line of output, so using this command on both routers can quickly identify the first problem. A quick look at the configuration, plus remembering that HDLC is the default serial encapsulation, can confirm whether the encapsulations are mismatched. The solution is simple, reconfigure one of the two routers to match the other router’s encapsulation command.
The keepalive feature helps a router recognize when a link is no longer functioning so that the router can bring down the interface, hoping to then use an alternative IP route.
The keepalive function (by default) causes routers to send keepalive messages to each other every 10 seconds. This 10-second timer is the keepalive interval. If a router does not receive any keepalive messages from the other router for a number of keepalive intervals, three or five depending on the IOS version, the router brings down the interface, thinking that the interface is no longer working.
If keepalives is disabled on one end and not on the other, the one that it is enabled on would still expect to receive the messages, if not, it would shut itself down and then start to flap. The other interface, not caring about keepalives, would leave the interface in an “up and up” state the whole time.