[c-nsp] Possible T1 clocking problem.

Joseph Mays mays at win.net
Tue Apr 17 14:46:56 EDT 2012


We're setting up an HDSL4 t1 across two copper pairs. This is the first time I've ever turned up a T1 that was not telco provided. The smartjacks show the T1 as up (and extremely good quality, actually, strong signal and not a single bit error). On the CO side the T1 goes to a T3 multiplexer which is plugged into a channelized T3 card in an AS5400. On the remote end the T1 is plugged into T1 WIC in a 2600.

Both ends show the T1 interface up, line protocol is down. Encapsulation is PPP, but all I ever see are errors. I've confirmed the wiring and every other aspect of the physical layer.

Here is the show interface info from the AS5400 6 minutes after clearing counters on the interface.

AMSS1#show int serial1/0:24:0
Serial1/0:24:0 is up, line protocol is down
  Hardware is DSX1
  Internet address is 216.24.28.249/30
  MTU 1500 bytes, BW 1344 Kbit, DLY 20000 usec,
     reliability 244/255, txload 1/255, rxload 1/255
  Encapsulation PPP, LCP REQsent, loopback not set
  Last input 23:04:24, output never, output hang never
  Last clearing of "show interface" counters 00:06:00
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: weighted fair
  Output queue: 0/1000/64/0 (size/max total/threshold/drops)
     Conversations  0/1/256 (active/max active/max total)
     Reserved Conversations 0/0 (allocated/max allocated)
     Available Bandwidth 1008 kilobits/sec
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     0 packets input, 0 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 12 giants, 0 throttles
     14 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 2 abort
     75 packets output, 1050 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions
  Timeslot(s) Used:1-24, Transmitter delay is 0 flags
AMSS1#

The interface on the remote end (t1 WIC port in a 2600 shows a lot more errors, including a lot of frame errors, for the same time period.

On the AS5400, the clocking on the t3 interface is set to take clocking from the network. Show tdm clock shows the clocking on the t1 channel in question (channel 24) as good.

AMSS1#show tdm clock

Primary Clock:
--------------
System primary is slot 1 ds3_port 0 ds1_port 1 of priority 1
TDM Bus Master Clock Generator State = NORMAL

Backup clocks for primary:
Source  Slot  Port  DS3-Port  Priority      Status      State
-------------------------------------------------------------
Trunk   1     2       YES       2            Good        Configured
Trunk   1     3       YES       3            Good        Configured
Trunk   1     4       YES       4            Good        Configured
Trunk   1     5       YES       5            Good        Configured
Trunk   1     6       YES       6            Good        Configured
Trunk   1     28      YES       202          Good        Default

Trunk cards controllers clock health information
------------------------------------------------
      CT3         2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1
Slot  Port  Type  8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1
1     0      T3   G B B B G B B B B B B B B B B B B B B B B B G G G G G G

Worth noting is that the other t1's (1-6) that show up as good are all standard t1's through the telco. Channel 24 connects directly to the HDSL smartjack that goes to the remote end. I assume the AS5400 end is picking up clocking from the MUX for channel 24, but it's not clear to me what is deciding the clocking for the T1 to the remote from the mux (which is where all the frame errors are showing up) in this case.

I've tried setting the T1 on the remote side to both clock-source line and clock-source internal. No difference in either case.


More information about the cisco-nsp mailing list