Cisco 2811 WIC-1T problem

[cisabucho]

Hi guys,

A Cisco 2811 with WIC-1T is connected to a VSAT modem (Comtech). This connection carries voice signalling as well as bearer traffic coming from a GSM network for long distance calls. On the remote end of the connection is also a Cisco router (it is run by a service provider).There is a lot of error on the interface and we have to frequently reload the interface for the voice connection to go through. Below is the output of sh interface command.

voice-GW#sh int s0/0/0
Serial0/0/0 is up, line protocol is up
  Hardware is GT96K Serial
   MTU 1500 bytes, BW 2000000 Kbit, DLY 20000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation HDLC, loopback not set
  Keepalive set (10 sec)
  CRC checking enabled
  Last input 00:00:00, output 00:00:00, output hang never
  Last clearing of "show interface" counters 00:40:16
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 1365
  Queueing strategy: weighted fair
  Output queue: 0/1000/64/0 (size/max total/threshold/drops)
     Conversations  0/4/256 (active/max active/max total)
     Reserved Conversations 0/0 (allocated/max allocated)
     Available Bandwidth 1500000 kilobits/sec
  30 second input rate 651000 bits/sec, 399 packets/sec
  30 second output rate 667000 bits/sec, 392 packets/sec
     898311 packets input, 171861345 bytes, 0 no buffer
     Received 279 broadcasts, 0 runts, 0 giants, 0 throttles
     22463 input errors, 22461 CRC, 8346 frame, 3791 overrun, 0 ignored, 13722 abort
     923255 packets output, 177800618 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
     424 carrier transitions
     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

The config on the interface is as follows

interface Serial0/0/0
description   XXX
bandwidth 2000000
ip address x.x.x.x
no ip redirects
no ip proxy-arp
ip virtual-reassembly
load-interval 30
end

What can I do to stop this manual reload of the interface?

regards,

Abebe Amare (CCNP, CCVP)

[IAN WHITMORE]

 22463 input errors, 22461 CRC, 8346 frame, 3791 overrun, 0 ignored, 13722 abort
     923255 packets output, 177800618 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
     424 carrier transitions

I'm lazy so I just asked Cisco output interpreter to do the dirty work:

SHOW INTERFACE SERIAL NOTIFICATIONS (if any)

Interface Serial0/0/0 (up/up)
  WARNING: This interface has a high number of output drops.
  The input rate to this interface has exceeded the bandwidth available on the
  serial link.
  TRY THIS:
  1. Minimize periodic broadcast traffic like routing and Service Advertising
     Protocol (SAP) updates (if applicable) by using access lists or by other
     means.
  2. Turn off fast switching for heavily used protocols. For example, turn off
     IP fast switching by using the 'no ip route-cache' interface configuration
     command.
  3. Implement priority queuing on slower serial links.
  4. Submit the output from 'show buffers' to Output Interpreter to determine
     if buffers need to be tuned.
  REFERENCE: For more information see: Troubleshooting Output Drops
  
  WARNING: This interface has had 424 carrier transitions.
  TRY THIS: Use the 'clear counters Serial0/0/0' command to ensure current information
  is being displayed. Check interface resets as well. If they are high while carrier
  transitions are being registered, the problem is most likely a bad link or CSU/DSU.
  Contact your service provider and swap faulty equipment as necessary.
  REFERENCE: For more information see: HDLC Back to Back Connections
  
  WARNING: This interface has received a high number (2.43937% of input packets)
  of packets with incorrect CRCs (corrupted data).
  Problems that may cause this symptom include:
  a. Noisy serial line
  b. Serial cable is too long or cable from the CSU/DSU to the router is not
     shielded
  c. SCTE mode is not enabled on the DSU
  d. The CSU line clock is incorrectly configured
  e. A Ones density problem on the link (incorrect framing or coding
     specification), exists
  f. Verify the queuing strategies are the same on both ends of the link.
  TRY THIS:
  1. Ensure that the line is clean enough for transmission requirements. Shield
     the cable if necessary.
  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 the link).
  3. Ensure that all devices are properly configured for a common line clock.
     Set serial clock transmit external (SCTE) on the local and remote DSU. If
     you are attempting serial connections at speeds greater than 64 kbps with
     a CSU/DSU that does not support (SCTE), you might have to invert the
     transmit clock on the router. Inverting the transmit clock compensates
     for phase-shifts between the data and clock signals.
  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).
  5. Contact your leased-line or other carrier service and have them perform
     integrity tests on the line.
  
  WARNING: This interface has received a high number of packets (more than 1% total
  interface traffic) with abort errors.
  Aborts indicate an illegal sequence of one bits (more than 7 in a row).
  Problems that may cause this symptom include:
  a. SCTE (serial clock transmit external) mode is not enabled on DSU
  b. The CSU line clock is incorrectly configured
  c. The Serial cable is too long or the cable from the CSU or DSU to the
     router is not shielded
  d. There is a ones density problem on the link (incorrect framing or
     coding specification)
  e. The packet terminated in the middle of transmission (typical cause is an
     interface reset or a framing error)
  f. Hardware problem: bad circuit, bad CSU/DSU, or bad sending interface on
     remote router
  TRY THIS:
  1. Ensure that all devices are properly configured for a common line clock.
     Set serial clock transmit external (SCTE) on the local and remote DSU. If
     you are attempting serial connections at speeds greater than 64 kbps with
     a CSU/DSU that does not support (SCTE), you might have to invert the
     transmit clock on the router. Inverting the transmit clock compensates
     for phase-shifts between the data and clock signals.
  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 the link). Ensure all
     connections are good. Shield the cable of necessary.
  3. Check the hardware at both ends of the link. Swap faulty equipment as
     necessary.
  4. Lower data rates and determine if aborts decrease.
  5. Use local and remote loopback tests to determine where aborts are
     occurring.
  6. Contact your leased-line or other carrier service and have them perform
     integrity tests on the line.
  
  WARNING: 3791 overruns have been reported, which amounts to 0.42024% of the total
  input traffic. This is because, the input rate exceeds the ability of the receiver
  to handle data.
  TRY THIS: This problem can occur due to massive amounts of traffic, and/or because
  the router is not powerful enough. Analyze traffic patterns on this interface
  to determine the source of large amounts of traffic. However, this may not always
  be possible, because these counters could have been incremented at some point
  in the past. Paste the output of the 'show buffer' command output into the Output
  Interpreter to check whether the buffers can be tuned. Also, try to reduce the
  number of hosts in the segment.
  REFERENCE: For more information, see Performance Tuning Basics
  
  INFO: This interface has had 22463 'Input errors'. This error includes runts,
  giants, no buffer, CRC, frame, overrun, and ignored counts. Other input-related
  errors can also cause the input error count to increase. Some datagrams can have
  more than one error. Therefore, this sum may not be equal to the sum of enumerated
  input error counts.
  
REFERENCE: For more information on Serial Lines, see:
  Troubleshooting Serial Line Problems
  Configuring Serial Interfaces
  Troubleshooting Serial Lines
  Loopback Tests for T1/56K Lines

REFERENCE: Command Reference - 'show interface serial'

HTH,

Ian

[mavespig]

Hi Abebe,

As Ian reported, you have a high number of input errors on the serial interface.

Is the VSAT modem sending a clock signal on the line?

What is the current configuration of the serial controller? is it configured for clocking source line or clocking source internal?

Can you disconnect the VSAT modem, apply a physical hardware loop to the T1 and test if the interface works fine? You can use for reference the steps described here:

http://www.cisco.com/en/US/tech/tk713/tk628/technologies_tech_note09186a00800a754b.shtml

If the tests run clean, then it's a problem on the modem.

Hope this helps

Marco

** Do not forget to rate posts, if you find them useful **