I am practically ashamed to ask this, but a lowly point-to-point DS0
circuit has me stumped. If it was a T1, T3, or even an OC-X circuit I
would be okay, but....
One of our customers ordered a 64Kbps point-to-point circuit between their
main site in TX and a remote site in FL. They are using WIC-1DSU-56K
cards on both ends. Their circuit provider (who shall remain nameless)
has not been very helpful in telling us how the circuit is configured,
much less recommending how to configure a Cisco serial port and CSU/DSU.
We have the line up and "running" but both ends keep reporing that the
port is "bouncing." Here is a snapshot of the logs:
Jan 16 05:00:10 CST: %LINK-3-UPDOWN: Interface Serial0/0, changed state to
down
Jan 16 05:00:11 CST: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Serial0/0, changed state to down
Jan 16 05:00:13 CST: %LINK-3-UPDOWN: Interface Serial0/0, changed state to
up
Jan 16 05:00:16 CST: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Serial0/0, changed state to up
Jan 16 05:00:53 CST: %LINK-3-UPDOWN: Interface Serial0/0, changed state to
down
Jan 16 05:00:54 CST: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Serial0/0, changed state to down
Jan 16 05:00:58 CST: %LINK-3-UPDOWN: Interface Serial0/0, changed state to
up
Jan 16 05:00:59 CST: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Serial0/0, changed state to up
Jan 16 05:01:09 CST: %LINK-3-UPDOWN: Interface Serial0/0, changed state to
down
Jan 16 05:01:10 CST: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Serial0/0, changed state to down
Jan 16 05:01:13 CST: %LINK-3-UPDOWN: Interface Serial0/0, changed state to
up
Jan 16 05:01:14 CST: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Serial0/0, changed state to up
This pattern repeats in bursts that sometimes last for an hour. Given the
bouncing port, the port counters show the expected variety of framing and
CRC errors. Both ends report a huge number of carrier transitions.
Serial0/0 is up, line protocol is up
Hardware is DSCC4 with 56k 4-wire CSU/DSU
Description: 64K ...
Internet address is 10.255.2.1/30
MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec,
reliability 255/255, txload 27/255, rxload 3/255
Encapsulation HDLC, loopback not set
Keepalive set (10 sec)
Last input 00:00:07, output 00:00:03, output hang never
Last clearing of "show interface" counters 15:02:29
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 45802
Queueing strategy: weighted fair
Output queue: 0/1000/64/45677 (size/max total/threshold/drops)
Conversations 0/12/16 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 0 kilobits/sec
30 second input rate 1000 bits/sec, 3 packets/sec
30 second output rate 7000 bits/sec, 2 packets/sec
413623 packets input, 28932184 bytes, 0 no buffer
Received 6468 broadcasts, 0 runts, 0 giants, 0 throttles
8975 input errors, 1753 CRC, 7222 frame, 0 overrun, 0 ignored, 0 abort
561076 packets output, 45271514 bytes, 0 underruns
0 output errors, 0 collisions, 21 interface resets
0 output buffer failures, 0 output buffers swapped out
6596 carrier transitions
DCD=up DSR=up DTR=up RTS=up CTS=up
Here is the port configuration for one end:
interface Serial0/0
description 64K to ...
bandwidth 64
ip address 10.255.2.1 255.255.255.252
load-interval 30
service-policy output voice_policy
service-module 56k clock source internal
service-module 56k clock rate 64
service-module 56k data-coding scrambled
The other end is identical except it uses "clock source line" (and a
different IP :-> ). I have also tried running both ends with line
clocking and it doesn't seem to make much difference (but seems a little
worse).
The long haul provider claims that they are NOT providing a clock on the
circuit. It sounds like it is a plain old telco circuit configured using
their DACS at the endpoints. They claim it is configured to be
"transparent."
The only way I can get the port to go "UP" is to configure the clock for
64K or "auto" (which detects 64K). However, when I configure the port to
that speed, the Cisco issues a warning:
% WARNING - 64k mode will not work in back-to-back DDS.
I haven't found any useful information on Cisco's site about the warning
and am frankly fairly ignorant of DS0 circuits. Is a point-to-point DS0
considered "back-to-back DDS" if the network provider claims they are
providing a transparent circuit? I assume not since there is still telco
equipment involved. Also, if they aren't providing a clock, why will the
CSU only sync at 64K?
I have tried running remote loopback tests using the built-in "loopback
remote" stress patterns and they always generate small numbers of bit
errors if I leave them running long enough (e.g. 15 minutes). Local DTE
loopback tests run clean, so the data side of the CSU/DSU modules appears
to be okay.
Issuing a 'show service-module' command sometimes shows errors, but other times doesn't. Here is a current snapshot from one end:
Module type is 4-wire Switched 56
Hardware revision is B, Software revision is 1.00,
Image checksum is 0x42364436, Protocol revision is 1.0
Receiver has no alarms.
CSU/DSU Status Flags 'Local DTE Loop Test'
Current line rate is 64 Kbits/sec
Last user loopback performed:
dte loopback
duration 00:07:50
Last module self-test (done at startup): Passed
Last clearing of alarm counters 14:58:45
oos/oof : 480, last occurred 00:04:55
loss of signal : 0,
loss of frame : 0,
rate adaptation attemp: 0,
The oos/oof errors would appear to be real since the last tests I ran were 15 hours ago and I cleared the counters after completing the tests. However, the other end doesn't indicate any oos/oof seconds for the same period.
The "CSU/DSU Status Flags 'Local DTE Loop Test'" line confuses me. It says this on both ends as soon as I boot the routers and never changes. What does this mean?
I srongly suspect that there is a circuit problem, but the long haul provider swears that they can run clean tests and I haven't been 100% sure of my CSU/DSU config so I didn't want to press the issue yet.
Am I doing something stupid? If not, any suggestions beyond opening another ticket with the provider and trying to get them to throw loops at various places to try isolating the problem? Could it be an issue with the local loop(s) not being provisioned correctly to match the long-haul circuit?
For completeness, one end is a 3620 32M/8F running 12.2(6a) and the other end is a 2621 24M/8F running 12.2(6).
Thanks for your help!
-dpm
-- David P. Maynard, Flametree Corporation Network Infrastructure and Monitoring Solutions EMail: dpm@flametree.com, Tel: +1 512 670 4090, Fax: +1 512 670 4091 --
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:13:29 EDT