Prev: Config T1 with routed block
Next: When is RELOAD not the same as a power off/on?
From: John on 22 Sep 2009 13:05
John wrote:

> Ruairi Carroll wrote:
>
> > On Sep 18, 5:12�pm, "John" <johnthomps...(a)hotmail.com> wrote:
> > > 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.
> >
> > 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?
> >
> > >
> > > 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.
> >
> > 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...
> >
> > > 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?
> >
> > Could be, see above, looping the circuit at various points on the
> > line, usually helps narrow down what introduces your issue.
> >
> > >
> > > Thanks.
> > >
> > > --
>
> 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?

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


--

From: John on 22 Sep 2009 13:11
Andrey Tarasov wrote:

> John wrote:
>
> > 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?
>
> 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.

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.


--

From: Techno_Guy on 22 Sep 2009 22:41
On Sep 22, 1:11 pm, "John" <johnthomps...(a)hotmail.com> wrote:
> Andrey Tarasov wrote:
> > John wrote:
>
> > > 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?
>
> > 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.
>
> 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.
>
> --- Hide quoted text -
>
> - Show quoted text -

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.

From: Andrey Tarasov on 23 Sep 2009 00:20
John wrote:

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

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.
From: bod43 on 23 Sep 2009 01:41
On 22 Sep, 16:11, "John" <johnthomps...(a)hotmail.com> wrote:
> Ruairi Carroll wrote:
> > On Sep 18, 5:12 pm, "John" <johnthomps...(a)hotmail.com> wrote:
> > > 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.
>
> > 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?
>
> > > 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.
>
> > 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...
>
> > > 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?
>
> > Could be, see above, looping the circuit at various points on the
> > line, usually helps narrow down what introduces your issue.
>
> > > Thanks.
>
> > > --
>
> 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.

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 (<100)
but I have not seen a broken one yet.

loopback testing is the way to go but you need to remember
that you need a clock on the segment under test.

Some cards can be conrifured to loop internally or
externally too.

http://www.cisco.com/en/US/tech/tk713/tk628/technologies_tech_note09186a00800a754b.shtml
"Loopback Tests for T1/56K Lines"

Might give you some ideas.


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?