• Telephone company
  problem---Line is
  down or line is not
  connected to
  CSU/DSU

   

• Faulty or incorrect
  cabling

   

• Hardware failure
  (CSU/DSU)

   

Step 2 Verify that you are using the proper cable and interface (see your hard- ware installation documentation).

Step 3 Insert a breakout box and check all control leads.

Step 4 Contact your leased-line or other carrier service to see whether there is a problem.

Step 5 Swap faulty parts.

Step 6 If you suspect faulty router hardware, change the serial line to another port. If the connection comes up, the previously connected interface has a problem.

 

• Local or remote router
  is misconfigured

   

• Keepalives are not
  being sent by
  remote router

   

• Leased-line or
  other carrier
  service problem---noisy
  line, or misconfigured
  or failed switch

   

• Timing problem
  on cable (SCTE
  not set on CSU/DSU)

   

• Failed local or
  remote CSU/DSU

   

• Router hardware
  failure (local or
  remote)

   

If the line protocol comes up, a telephone company problem or a failed remote router is the likely problem.

Step 2 If the problem appears to be on the remote end, repeat Step 1 on the remote modem, CSU, or DSU.

Step 3 Verify all cabling. Make certain that the cable is attached to the correct interface, the correct CSU/DSU, and the correct telephone company network termination point. Use the show controllers exec command to determine which cable is attached to which interface.

Step 4 Enable the debug serial interface exec command.

Caution: Because debugging output is assigned high priority in the CPU process, it can render the system unusable. For this reason, use debug commands only to troubleshoot specific problems or during troubleshooting sessions with Cisco technical support staff. Moreover, it is best to use debug commands during periods of lower network traffic and fewer users. Debugging during these periods decreases the likelihood that increased debug command processing overhead will affect system use.

Step 6 If the line protocol comes up and the keepalive counter increments, the problem is not in the local router. 

Step 7 If you suspect faulty router hardware, change the serial line to an unused port. If the connection comes up, the previously connected interface has a problem.

 

• Missing clockrate
  interface configuration
  command

   

• DTE device does not
  support or is not
  set up for SCTE
  mode (terminal
  timing)

   

• Failed remote
  CSU or DSU

   

• Failed or incorrect
  cable

   

• Router hardware
  failure

   

Syntax:

clock rate bps

Syntax Description:

bps---Desired clock rate in bits per second: 1200, 2400, 4800, 9600, 19200, 38400, 56000, 64000, 72000, 125000, 148000, 250000, 500000, 800000, 1000000, 1300000, 2000000, 4000000, or 8000000.

Step 2 Set the DTE device to SCTE mode if possible. If your CSU/DSU does not support SCTE, you might have to disable SCTE on the Cisco router interface. 

Step 3 Verify that the correct cable is being used.

Step 4 If the line protocol is still down, there is a possible hardware failure or cabling problem. Insert a breakout box and observe leads.

Step 5 Replace faulty parts as necessary.

Step 2 If you find a loopback interface configuration command entry, use the no loopback interface configuration command to remove the loop.

Step 3 If you do not find the loopback interface configuration command, examine the CSU/DSU to determine whether they are configured in manual loopback mode. If they are, disable manual loopback.

Step 4 Reset the CSU or DSU and inspect the line status. If the line protocol comes up, no other action is needed.

Step 5 If the CSU or DSU is not configured in manual loopback mode, contact the leased-line or other carrier service for line troubleshooting assistance.

 

• High error rate due to telephone company service problem

   

• CSU or DSU hardware problem

   

• Bad router hardware (interface)

   

Step 2 Loop CSU/DSU (DTE loop). If the problem continues, it is likely that there is a hardware problem. If the problem does not continue, it is likely that there is a telephone company problem.

Step 3 Swap out bad hardware as required (CSU, DSU, switch, local or remote router).

 

• Router configuration includes the shutdown interface configuration command

   

• Duplicate IP address

   

Step 2 Use the no shutdown interface configuration command to remove the shutdown command.

Step 3 Verify that there are no identical IP addresses using the show running-config privileged exec command or the show interfaces exec command.

Step 4 If there are duplicate addresses, resolve the conflict by changing one of the IP addresses.

Step 2 Increase the output hold queue size in small increments (for instance, 25 percent), using the hold-queue out interface configuration command.

Step 3 On affected interfaces, turn off fast switching for heavily used protocols. For example, to turn off IP fast switching, enter the no ip route-cache interface configuration command. For the command syntax for other protocols, consult the Cisco IOS configuration guides and command references.

Step 4 Implement priority queuing on slower serial links by configuring priority lists. For information on config- uring priority lists, see the Cisco IOS configuration guides and command references.

Note: Output drops are acceptable under certain conditions. For instance, if a link is known to be overused (with no way to remedy the situation), it is often considered preferable to drop packets than to hold them. This is true for protocols that support flow control and can retransmit data (such as TCP/IP and Novell IPX). However, some protocols, such as DECnet and local-area transport are sensitive to dropped packets and accommodate retransmission poorly, if at all.

Step 1 Increase the output queue size on common destination interfaces for the interface that is dropping packets. Use the hold-queue out interface configuration command. Increase these queues by small increments (for instance, 25%) until you no longer see drops in the show interfaces output. The default output hold queue limit is 100 packets.

Step 2 Reduce the input queue size, using the hold-queue in interface configuration command, to force input drops to become output drops. Output drops have less impact on the performance of the router than do input drops. The default input hold queue is 75 packets.

 

• Faulty telephone company equipment

   

• Noisy serial line

   

• Incorrect clocking configuration (SCTE not set)

   

• Incorrect cable or cable too long

   

• Bad cable or connection

   

• Bad CSU or DSU

   

• Bad router hardware

   

• Data converter or other device being used between router and DSU

   

Step 1 Use a serial analyzer to isolate the source of the input errors. If you detect errors, it is likely that there is a hardware problem or a clock mismatch in a device that is external to the router.

Step 2 Use the loopback and ping tests to isolate the specific problem source. 

Step 3 Look for patterns. For example, if errors occur at a consistent interval, they could be related to a periodic function such as the sending of routing updates.

 

• Noisy serial line

   

• Serial cable is too long
  or cable from the
  CSU/DSU to the
  router is not shielded

   

• SCTE mode is not
  enabled on DSU

   

• CSU line clock is
  incorrectly configured

   

• Ones density problem
  on T1 link (incorrect
  framing or coding
  specification)

   

Step 2 Make sure the cable is within the recommended length (no more than 50 feet [15.24 meters], or 25 feet [7.62 meters] for T1 link).

Step 3 Ensure that all devices are properly configured for a common line clock. Set SCTE on the local and remote DSU. I

Step 4 Make certain that the local and remote CSU/DSU are configured for the same framing and coding scheme as that used by the leased-line or other carrier service (for example, ESF/B8ZS).

Step 5 Contact your leased-line or other carrier service and have it perform integrity tests on the line.

 

• Noisy serial line

   

• Improperly designed
  cable; serial cable is too
  long; the cable from
  the CSU or DSU to the
  router is not shielded

   

• SCTE mode is not enabled
  on the DSU; the CSU line
  clock is incorrectly
  configured; one of the
  clocks is configured for
  local clocking

   

• Ones density problem
  on T1 link (incorrect
  framing or coding
  specification)

   

Step 2 Make sure the cable is within the recommended length (no more than 50 feet [15.24 meters], or 25 feet [7.62 meters] for T1 link)

Step 3 Ensure that all devices are properly configured to use a common line clock. Set SCTE on the local and remote DSU. 

Step 4 Make certain that the local and remote CSU/DSU is configured for the same framing and coding scheme as that used by the leased-line or other carrier service (for example, ESF/B8ZS).

Step 5 Contact your leased-line or other carrier service and have it perform integrity tests on the line.

The following are possible reasons for this to occur:

 

• SCTE mode is not enabled on DSU

   

• CSU line clock is incorrectly configured

   

• Serial cable is too long or cable from the CSU or DSU to the router is not shielded

   

• Ones density problem on T1 link (incorrect framing or coding specification)

   

• Packet terminated in middle of transmission (typical cause is an interface reset or a framing error)

   

• Hardware problem---bad circuit, bad CSU/DSU, or bad sending interface on remote router

Step 2 Shield the cable if necessary. Make certain the cable is within the recommended length
(no more than 50 feet [15.24 meters], or 25 feet [7.62 meters] for T1 link). Ensure that all connections are good.

Step 3 Check the hardware at both ends of the link. Swap faulty equipment as necessary.

Step 4 Lower data rates and determine whether aborts decrease.

Step 5 Use local and remote loopback tests to determine where aborts are occurring.

Step 6 Contact your leased-line or other carrier service and have it perform integrity tests on the line.

 

• Congestion on link (typically associated with output drops)

   

• Bad line causing CD transitions

   

• Possible hardware problem at the CSU, DSU, or switch

Step 1 If there is a high number of output drops in the show interfaces serial output, see the section "Serial Lines: Increasing Output Drops on Serial Link" earlier in this chapter.

Step 2 Check the carrier transitions field in the show interfaces serial display. If carrier transitions are high while interface resets are being registered, the problem is likely to be a bad link or bad CSU or DSU. Contact your leased-line or carrier service and swap faulty equipment as necessary.

Step 3 Examine the input errors field in the show interfaces serial display. If input errors are high while interface resets are increasing, the problem is probably a bad link or bad CSU/DSU. Contact your leased-line or other carrier service and swap faulty equipment as necessary.

 

• Line interruptions due to an external source (such as physical separation of cabling, red or yellow T1 alarms, or lightning striking somewhere along the network)

   

   

• Faulty switch, DSU, or router hardware

   

Step 2 If an analyzer or breakout box is unable to identify any external problems, check the router hardware.

Step 3 Swap faulty equipment as necessary.

Step 2 If the CSUs do not agree, configure them so that they do (usually the line is the source).

Step 3 Check the LBO¹ setting on the CSU to ensure that the impedance matches that of the physical line. For information on configuring your CSU, consult your CSU hardware documentation.

Step 2 If SCTE is not enabled on both ends of the connection, enable it.

(For any interface that is connected to a line of 128 kbps or faster, SCTE must be enabled.

Step 3 Make sure that ones density is maintained. This requires that the DSU use the same framing and coding schemes (for example, ESF and B8ZS) used by the leased-line or other carrier service.

Check with your leased-line provider for information on its framing and coding schemes.

Step 4 If your carrier service uses AMI coding, either invert the transmit clock on both sides of the link or run the DSU in bit-stuff mode. For information on configuring your DSU, consult your DSU hardware documentation.

If the cable is unshielded, replace it with shielded cable.

input queue, drops

The five-minute input and output rates should be used only as an approximation of traffic per second during a given five-minute period. These rates are exponentially weighted averages with a time constant of five minutes. A period of four time constants must pass before the average will be within 2% of the instantaneous rate of a uniform stream of traffic over that period.