T1 Serial Problems

I've installed two cisco 1841 routers with csu/dsu cards in them to support a closed circuit t1. The configuration for the serial port is as follows:

Router A: interface serial 0/0/0 ip address 192.168.1.1 255.255.255.0 ip access-group 101 in ip access-group 102 out encapsulation ppp service-module t1 clock source internal service-module t1 timeslots 1-24 crypto map myMap

Router B: interface serial 0/0/0 ip address 192.168.1.2 255.255.255.0 ip access-group 101 in ip access-group 102 out encapsulation ppp service-module t1 cablelength short 220ft service-module t1 timeslots 1-24 cypto map myMap

Everything seems to work fine, except the serial connection goes down for

30secs about every 30min. We had the ISP out there to test the line and they tried to sync up the oscillators with some magical machine, and that helped the timing a little bit, but we still see the problem.

Our guess at this point is that there is a hardware problem, and we are considering swapping out both routers. Does anybody have any other ideas at this point that I can try? Or even commands I can use to test the line and narrow down the problem? I tried following the Cisco troubleshooting guide for t1 lines, but maybe I missed something.

Also, Router B is connected from the terminal to the serial port with a cable that is roughly 140ft. Perhaps the cable is messing things up?

Thanks.

Reply to
John
Loading thread data ...

Hi John, what kind of card are you using ?

- What does 'sh controller t1 0/0/0' look like, taken 4 times every 10 mins (ie: across a failure), do your slip seconds increment?

A hard loop on both sides will tell you if this is a hardware problem (assuming this is already done). I've found it helps if you loop at the router, then loop at the CSU/DSU (ie: test the length of your cable). Then loop at the remote CSU/DSU (test the full circuit). This is quite invasive testing tbh...

Keep an eye on the counters from 'sh controller t1 0/0/0' to see what's incrementing. Also keep an eye on the serial interface counters also...

Could be, see above, looping the circuit at various points on the line, usually helps narrow down what introduces your issue.

Reply to
Ruairi Carroll

I'm leaning towards a clocking issue but I have no idea what a "closed circuit T1" is, never heard of that before. Do you mean that this is a point-to-point T1 between two locations? If it is, then clocking should be external (or recovered) on both ends. The carrier provides the clocking on a T1. You have one side as internal, and the other is external. The internal side is getting out of sync every 30 minutes and the line is going down.

Reply to
Thrill5

Hey guys.

Thanks for the input. The "closed circuit T1" that I have is a point-to-point connection. The ISP told us to set

1 side as internal and one side to line (just like a back- to-back configuration) because they have nothing on the line.

If I do a show controllers ..., the hardware is as follows: Hardware is GT96K with integrated T1 CSU/DSU. This is true on both routers.

If I do a show interfaces serial 0/0/0, the input errors, CRC, frame, and overrun erros are also increasing.

Sorry for the late reply, but I'm back in the office now. I can try more later. Thanks again for the reply. Any more ideas?

Reply to
John

I find "nothing on the line" claim highly suspicious. The only time you would run into such situation is when T1 are provisioned over plain copper runs directly to the same central office from both locations. In every other case there is something on the line and this something does provide clocking. Have you tried to set both ends to "line"?

Regards, Andrey.

Reply to
Andrey Tarasov

I should probably also mention that I initially had them both set to line (instead of 1 at internal) and I saw the same problem.

Thanks again,

-- John

Reply to
John

Thanks Andrey,

We all thought it was weird too when he set it up. In fact, everyone I talk to (and I'm sure everyone reading this) thought it sounded weird when they told us to do it.

However, I had them both set to line for several months and we saw the same problems. The ISP came out with some machine and was able to sync up the oscillators in the routers, and that seemed to help out, but we still saw the same problems. So we started blaming either the cisco hardware or the long cable on the other end.

Our next plan is to replace the cisco hardware with some

2600 routers, but we would take the CSU/DSU module out of our existing 1800 series routers and place it in the 2600 series.
Reply to
John

Except for the fact that I dont believe the CSU wics in the 1800 and the 2600 are compatible. I could be wrong. You should check Cisco's site or call your Cisco equipment provider to confirm.

Are you getting increasing counters in "loss of frame". This could be bad wics or bad cables if you are.

Reply to
Techno_Guy

Long cable run can indeed be the problem. Is it proper T1 type of cable or just Cat5 or something similar? Any fluorescent lights along it?

Troubleshooting is really straightforward but require some downtime. You will need hardware loopback - just normal RJ45 plug with pin 1 connected to 4 and 2 to 5 (if my memory is correct). Disconnect the cable and plug loopback in its place, run extended ping with 0x00, 0xFF, 0x4040 and

0x8080 patterns from remote router. Check for errors - if line is clean, repeat with cable in place and loopback on the router.

Regards, Andrey.

Reply to
Andrey Tarasov

The sh controllers also displays detailed error information not available otherwise.

Please post entire sh controllers se x/x. (sorry I don't have one here to check exact syntax) after the line has been up for some hours. Stats are collected every 15 minutes and kept for some hours - if I recall correctly.

I have dealt with only a few cisco serial cards (

Reply to
bod43

Thanks again guys,

My connection from where I am is currently down with my T1 connection, and I don't think it will be up until tomorrow. When it comes up tomorrow, I'll do all of the suggested commands (sh controllers se x/x, etc.), and let everyone know what's up.

In the meantime, I'm pretty sure the long cable on the other end is just cat5 (I think a straight through going from the smartjack to the csu/dsu card). Anyway, I tried searching online for some proper T1 cable (what exactly is proper t1 cable? from what I gather, it looks like cat3?). I really like that suggestion and would like replacing the cable with proper t1 cable. does anybody have a good site I can go to in order to buy such cable? I found a couple, but want to make sure I buy the right thing. It looks like I need RJ48 cable (does this cable have an RJ45 connector and the RJ48 is just the pin specs?).

I'll post more when the connection is back up. Thanks again.

Reply to
John

Proper T1 cable has two individually shielded pairs. Here is the link to one of the suppliers -

formatting link
Regards, Andrey.

Reply to
Andrey Tarasov

Thanks for the link Andrey. What's the difference between a proper t1 line and a regular cat5 cable? Is the T1 cable basically a cat3 cable with less twist along the line?

Reply to
John

The sh controllers also displays detailed error information not available otherwise.

Please post entire sh controllers se x/x. (sorry I don't have one here to check exact syntax) after the line has been up for some hours. Stats are collected every 15 minutes and kept for some hours - if I recall correctly.

I have dealt with only a few cisco serial cards (

Reply to
John

formatting link
the E1 version. T1 identical I think.

formatting link
Has a number of links to promising material.

Reply to
bod43

formatting link
shows the E1 version. T1 identical I think.

formatting link

Hey Bod,

I tried show controllers t1, but it didn't show anything. I did happen to try this though, and I'm thinking it's what you wanted to see:

Does this at least narrow down which Router is getting out of sync? Thanks.

RouterA#show service-module serial 0/0/0 Interface Serial0/0/0 Module type is T1/fractional Hardware revision is 1.2, Software revision is 20070620, Image checksum is 0x4144A7, Protocol revision is 0.1 Receiver has no alarms. Framing is ESF, Line Code is B8ZS, Current clock source is internal, Fraction has 24 timeslots (64 Kbits/sec each), Net bandwidth is 1536 Kbits/sec. Last module self-test (done at startup): Passed Last clearing of alarm counters 2w0d loss of signal : 1, last occurred 1w6d loss of frame : 1379, last occurred 00:13:57 AIS alarm : 1378, last occurred 00:13:57 Remote alarm : 3, last occurred 1w0d Module access errors : 0, Total Data (last 96 15 minute intervals): 0 Line Code Violations, 91 Path Code Violations 3 Slip Secs, 2509 Fr Loss Secs, 0 Line Err Secs, 55 Degraded Mins 98 Errored Secs, 22 Bursty Err Secs, 0 Severely Err Secs, 2509 Unavail Secs Data in current interval (399 seconds elapsed): 0 Line Code Violations, 0 Path Code Violations 0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins 0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs

---------------------------------------------------------------------------

RouterB#show service-module serial 0/0/0 Interface Serial0/0/0 Module type is T1/fractional Hardware revision is 1.2, Software revision is 20070620, Image checksum is 0x4144A7, Protocol revision is 0.1 Receiver has no alarms. Framing is ESF, Line Code is B8ZS, Current clock source is line, Fraction has 24 timeslots (64 Kbits/sec each), Net bandwidth is 1536 Kbits/sec. Last module self-test (done at startup): Passed Last clearing of alarm counters 3w0d loss of signal : 2031, last occurred 00:02:40 loss of frame : 2037, last occurred 00:02:40 AIS alarm : 6, last occurred 1w0d Remote alarm : 3, last occurred 1w0d Module access errors : 0, Total Data (last 96 15 minute intervals): 953406 Line Code Violations, 68 Path Code Violations 3 Slip Secs, 2635 Fr Loss Secs, 379 Line Err Secs, 8 Degraded Mins 22 Errored Secs, 1 Bursty Err Secs, 0 Severely Err Secs, 2635 Unavail Secs Data in current interval (66 seconds elapsed): 0 Line Code Violations, 0 Path Code Violations 0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins 0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs

Reply to
John

I've literally done many hundreds of T1s with cat3 or cat5 cabling. Just think of what the telco uses out in the field to run T1s. voice-grade cable all the way. Once its inhouse, they'll use whatever house wiring is there to run it to your CPE.

ABAM cable. Google that and you'll get thousands of hits. In the field, I've seen it literally twice, and have used it once. Compared to multi-hundreds of installs on cat5/cat3/voice-grade.

ABAM cabling is thicker guage (22AWG compared to 24AWG). Each pair inside the cable (ie. receive and transmit) is individually shielded.

Thats it. Copper is copper otherwise. FEXT and NEXT are inline with cat3/cat5.

I don't think running ABAM cabling vs. cat5 is going to give you any different (other than perhaps different copper). Its hard to source, nobody has it local, it usually has to be shipped in from the manufactorer.

The main rule of thumb in the field is with multiple T1 runs, you'll want to put all the receives on one binder, and all the transmits on another binder. If you have one or two, this rule isn't all that important either..

Reply to
Doug McIntyre

Not out of sync, but it shows you which one is the problem one.

Are these incrementing currently? LCVs are a cabling problem somewhere on this end, or a bad line card, or something telco/cabling related.

Get the telco out with their testset to run patterns to narrow this down.

They can jack in at the CO and run bert from there out for each leg.

Reply to
Doug McIntyre

Thanks Doug. The line code violations are increasing. Everything else is basically the same. So I have a couple of questions in trying to understand the problem, but before I do, this is basically what my setup looks like:

RouterB ----------- Telco------------- RouterA (B: Has long cable from smartjack to router) (A: Has line as internal) (B: Has line as clock source) (A: Working fine) (B: The problem child)

Based on everyone's help, it looks like RouterB (because of the increasing line code violations), has either a problem with the long cable [though this is unlikely], has a hardware failure, or their is a problem at the telco. So ...

- Since RouterB's clock source is set to line, this means he is getting the clock from the Telco. Based on that, then it shouldn't matter to RouterB what RouterA's clock source is set to. Correct?

- Is it possible that the telco guy wanted me to set RouterB's clock source to line and RouterA's clock source to internal so that RouterB would get his clock from RouterA?

- Currently, RouterA's clock source is set to internal (though it works with line too). Since this should probably be set to line (even though the guy from the telco told us to set it to internal), how is this even working?

- If we replace RouterB with a new router, but place the current CSU/DSU card in RouterB into NewRouterB, is it possible that this will help the situation?

- If we replace the long cable at RouterB with a new ABAM cable, will this likely help?

- If we just swap out RouterA and RouterB with NewRouterA and NewRouterB (both with new csu/dsu cards), will this have a high probability to fix the issue?

Thanks again.

-- John

Reply to
John

Pure and simple - if Telco supplies clock, both routers should be set to "line". If Telco doesn't supply clock - one end should be set to "internal". If "line"-"line" is working, Telco is supplying clock even if they say otherwise. Just ignore them.

Chances of running into competent telco technician are somewhat between winning the lottery and running into T Rex.

Clock difference is not big enough to cause the problem. But you will see slips now and then.

Highly unlikely.

You can find out. Disconnect long cable, plug loopback into smartjack, run extended ping from RouterA and see if errors are increasing. If line runs clean - you probably found the culprit.

Quite low probability.

Regards, Andrey.

Reply to
Andrey Tarasov

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.