sundance-communications.com/forum Forums Wiring - Telecom Carriers - Trunks & Services T1's, CSU's and DSU's T1 slow in one direction and fast in the other

This is a repost of a comment I posted in another thread. Bill asked that I create a new topic to reduce confusion.

Hello all,

I have an identical issue, on a point-to-point T1 we have running between our Portland and Boise offices. Very slow from Portland to Boise.

This is what our traffic for the past week looks like (Boise to Portland in Green, Portland to Boise in Blue):



The show interface output on the serial interfaces looks like this...

Portland show int s0:
Serial0 is up, line protocol is up
Hardware is PQUICC with Fractional T1 CSU/DSU
Description: PLDHGL572789ELG, Oliver Russell and Associates Portland, Chris Hillman, 208-XXX-XXXX
Internet address is 172.17.0.2/30
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
reliability 255/255, txload 46/255, rxload 51/255
Encapsulation HDLC, loopback not set
Keepalive set (10 sec)
Last input 00:00:01, output 00:00:00, output hang never
Last clearing of "show interface" counters never
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/11/256 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
5 minute input rate 312000 bits/sec, 44 packets/sec
5 minute output rate 283000 bits/sec, 31 packets/sec
18213621 packets input, 676783642 bytes, 0 no buffer
Received 188156 broadcasts, 4 runts, 0 giants, 0 throttles
70660 input errors, 41308 CRC, 29291 frame, 0 overrun, 0 ignored, 59 abort
11486369 packets output, 3019233377 bytes, 0 underruns
0 output errors, 0 collisions, 5 interface resets
0 output buffer failures, 0 output buffers swapped out
5 carrier transitions
DCD=up DSR=up DTR=up RTS=up CTS=up


Boise show int s0
Serial0 is up, line protocol is up
Hardware is PQUICC with Fractional T1 CSU/DSU
Description: PLDHGL572789ELG, Oliver Russell and Associates Boise, Chris Hillman, 208-XXX-XXXX
Internet address is 172.17.0.1/30
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
reliability 255/255, txload 48/255, rxload 46/255
Encapsulation HDLC, loopback not set
Keepalive set (10 sec)
Last input 00:00:05, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 1760
Queueing strategy: weighted fair
Output queue: 0/1000/64/1759 (size/max total/threshold/drops)
Conversations 0/10/256 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 1158 kilobits/sec
5 minute input rate 279000 bits/sec, 26 packets/sec
5 minute output rate 294000 bits/sec, 45 packets/sec
11482616 packets input, 3016171101 bytes, 0 no buffer
Received 188140 broadcasts, 0 runts, 1 giants, 0 throttles
11244 input errors, 438 CRC, 4932 frame, 0 overrun, 0 ignored, 5874 abort
18208562 packets output, 672502468 bytes, 0 underruns
0 output errors, 0 collisions, 5 interface resets
0 output buffer failures, 0 output buffers swapped out
5 carrier transitions
DCD=up DSR=up DTR=up RTS=up CTS=up

The bolded section is what I'm concerned about. Any thoughts on troubleshooting?.. could a bad cable in Boise or Portland cause errors on both routers?

Any help appreciated.

Thanks,
Chris

Welcome aboard Chris!


[Edited to revise:]

I discussed the levels of your CRCs with some fellow coworkers. Our opinion based on your data is:

1. Your B8ZS line coding (CRCs are only associated with B8ZS) is "hammering right along."

2. Confirm that clock source configuration is correct (internal/external based on from where timing is being provided.)

3. The trouble could exist at a poor cable connection/bad copper pair.

Like Bill is recommending, see if you are detecting errors at your CSUs. If so, what are they?

Maybe some of our other members more familiarized with Cisco products will be able to assist as well. Can you provide us with the series of routers?

Also, do your CSU's provide error detection? If so are they also registering errors? When you run packets of data you're not really testing the T-1.

Welcome Chris and thanks for opening a new topic.
Bill

These are the the stats for the CSU plugin cards on the Cisco routers. Probably a WIC1-DSU or similar.

I have always heard that ANY CRC/frame errors are not good. In my experience these are most often an issue on the provider side.

I have not read the previous thread, but have you talked to the provider? If so, what are they telling you? I have seen lots of CRC/Framing erros caused by a bad F2 pair (or at least that's what the LEC has told me).

Also, the errors on your Cisco routers are cumulative, so you will want to clear them and recheck. This line in your interface command, indicates that hasn't been done:

"Last clearing of "show interface" counters never"

Sorry if I may be asking questions/making comments that have been addressed in the previous thread.

Thanks for the input guys. I logged a call with the provider tonight and they are going to do some tests this evening. I'll let you know what I find out.

Thanks again.

As Steve had mentioned above, how long has the router been up because your counters have never been cleared. Many of those errors, if not incrementing, may be historical in nature and might not be currently affecting the circuit.

I'm obviously concerned that there are errors on both sides. Who is your carrier for this T1? It's interlata so there may be more than one incumbent lec involved? If so, what are the odds that the last mile T1s on both sides are both causing errors?

Can you give us a show ver also? If you would like me to look at your config for you, send a show running over to me in a private message.

Ask your provider to tell you exactly what pieces of equipment your circuit goes through. Is it all T1, or do they step it up to Fiber (through a Fujitsu), etc.

Your provider cannot test all 7 layers of the OSI model, their test sets will only test the first 3. Your Cisco router however does test all 7 layers, and the carrier must match Cisco, as Cisco is the standard.

Be advised, that packet shape differs between 100MBit and lower speed circuits-- as such, they may be taking your lower speed circuit and dropping it on a faster fiber circuit (STS1) just because it's economical for them to do so and their CO is set up that way.

In which case, low speed communication (typing, logging in, etc.) works-- but faster communications may fail CRC issues on both ends as data gets warped/lost between the endpoints.

If you can telnet into something across the entire length of the circuit-- all 7 OSI layers work, period. Then it's just a matter of speed/package-shape heuristics that need adjusted if you're stepping up or down across different-sized circuits/rings.

If a test-set on either end shows clean to either another test-set or a hardloop (so it's testing the length to itself in both directions) then it is probably *not* a circuit quality issue, and much more likely a configuration issue on the carrier's equipment, or yours-- in which case I'd find out what kind of equipment the circuit goes across and look at the packet/speed issues I've described above.