Prev: Config T1 with routed block
Next: When is RELOAD not the same as a power off/on?
From: Doug McIntyre on 23 Sep 2009 19:48
"John" <johnthompson1(a)hotmail.com> writes:
>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).

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.

>Anyway, I tried searching online for some proper T1 cable
>(what exactly is proper t1 cable?

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.

> 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?

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..




From: Doug McIntyre on 23 Sep 2009 19:51
"John" <johnthompson1(a)hotmail.com> writes:
>Does this at least narrow down which Router is getting out of sync? Thanks.

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

>RouterB#show service-module serial 0/0/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

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.
From: John on 23 Sep 2009 20:13

"Doug McIntyre" <merlyn(a)geeks.org> wrote in message
news:4abab46d$0$42846$8046368a(a)newsreader.iphouse.net...
> "John" <johnthompson1(a)hotmail.com> writes:
>>Does this at least narrow down which Router is getting out of sync?
>>Thanks.
>
> Not out of sync, but it shows you which one is the problem one.
>
>>RouterB#show service-module serial 0/0/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
>
> 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.

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

From: Andrey Tarasov on 23 Sep 2009 20:44
John wrote:
>
> "Doug McIntyre" <merlyn(a)geeks.org> wrote in message
> news:4abab46d$0$42846$8046368a(a)newsreader.iphouse.net...
>> "John" <johnthompson1(a)hotmail.com> writes:
>>> Does this at least narrow down which Router is getting out of sync?
>>> Thanks.
>>
>> Not out of sync, but it shows you which one is the problem one.
>>
>>> RouterB#show service-module serial 0/0/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
>>
>> 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.
>
> 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?

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.

> - 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?

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

> - 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?

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

> - 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?

Highly unlikely.

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

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.

> - 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?

Quite low probability.

Regards,
Andrey.
From: Andrey Tarasov on 23 Sep 2009 22:12
John wrote:

>
> Thanks again Andrey. I'll see if my guy can try the loopback test
> tomorrow and I'll post the results. However, I am a little concerned
> about the answers.
>
> If the line isn't the problem, and it's a low probability that it's a
> cisco hardware problem, then the problem probably lies with the telco.
> If that's the case, what could be causing the problem at the telco?
> Just curious. Thanks again for all the help.

From the highest to lowest probability -

1. Cable run between smartjack and RouterB
2. Telco
3. RouterB CSU/DSU
4. Something else

Check the cable first, worry about telco later :-)

Regards,
Andrey.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Config T1 with routed block
Next: When is RELOAD not the same as a power off/on?