 |
|
| Computers Forum Index » Computer - DCOM - Cisco » T1 Serial Problems... |
|
Page 2 of 2 Goto page Previous 1, 2 |
|
| Author |
Message |
| Doug McIntyre... |
Posted: Thu Sep 24, 2009 5:16 am |
|
|
|
Guest
|
"John" <johnthompson1 at (no spam) hotmail.com> writes:
Quote: 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:
If the LCVs and PCVs are increasing, thats your biggest problem.
Quote: - 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?
In a straight-up point-to-point T1 circuit, the telco doesn't provide
clock. The clocking comes from RouterA's 'clock internal'
statement. In your setup you need one side to provide clocking, and
one side to sync to it. (ie. clock internal vs clock line).
Quote: - 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?
That shouldn't do anything different. Clocking issues will just get
you slips and if the slips get bad enough, and occasional line
protocol down.
If you are incrementing LCVs and PCVs, then you have something lower
than worry about the clocking. Clocking doesn't affect these at *all*.
Quote: - 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?
One of your routers needs to originate clock, one needs to sync to
that clock. If you do both set to line, they'll try to sync to
whatever the other is doing, but you will have slips eventually. Clock
slips mostly show up on voice circuits with odd digital noises and things.
In data circuits, if it continues on enough, you can take a line
protocol hit from time to time, but most times will work fine.
Quote: - 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?
In my experience, this sort of issue is going to be something bad in
the CO, a bad smartjack card, or bad wiring. At the small end of
probability is a bad CSU/DSU on your T1 interface. At zero probability
is the router. The CSU/DSU is much more likely a culpret
than the router, but this looks more like a cable or CO
issue. Replacing the router while retaining the CSU/DSU will most likely
do nothing for you.
Quote: - If we replace the long cable at RouterB with a new ABAM cable, will this
likely help?
I don't think so, other than replacing the cable may bypass bad wiring.
The ABAM cable won't be so much better, it'll just be different copper
pairs, which you could probably do by switching to different house pairs.
Quote: - 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?
Unlikely. More likely is a CO or cabling issue. |
|
|
| Back to top |
|
|
|
| Andrey Tarasov... |
Posted: Tue Sep 29, 2009 7:31 pm |
|
|
|
Guest
|
John wrote:
Quote: Weird, my newsgroup access has been down for a couple of days. Anyway,
we replaced some hardware and nothing changed.
Andrey, I'm going to take your advice and perform the loopback testing.
I probably won't be able to test the problem router for a couple of
days, but will post the results when I do. Right now, I need to read up
on how to do loopback testing. 8-)
What loopback tests should I perform? If I unplug RouterB and plugin
the loopback there, and run an extended ping from RouterA through the
loopback, and everything works fine, this verifies that my problem is
either my long cable or some type of hardware failure with my cisco
device (either router but more likely csu/dsu card) right?
Correct.
Quote: If that loopback test fails, this means the problem exist with the Telco
wiring right?
Wiring, configuration, repeaters, etc.
Quote: What are the extended ping commands that I should use for this test and
what am I looking for? Thanks again for all your help!
Ping with 0x0000, 0xFFFF, 0x4040 and 0x8000 patterns. Tell us if any of
them fail.
Very good source of information about T1 circuits is T1 A Survival Guide
by Matthew S. Gast.
Regards,
Andrey. |
|
|
| Back to top |
|
|
|
| John... |
Posted: Tue Sep 29, 2009 9:45 pm |
|
|
|
Guest
|
"Andrey Tarasov" <andyvt at (no spam) email.com> wrote in message
news:h9t99k$31jd$1 at (no spam) news.aha.ru...
Quote: John wrote:
Weird, my newsgroup access has been down for a couple of days. Anyway,
we replaced some hardware and nothing changed.
Andrey, I'm going to take your advice and perform the loopback testing.
I probably won't be able to test the problem router for a couple of days,
but will post the results when I do. Right now, I need to read up on how
to do loopback testing. 8-)
What loopback tests should I perform? If I unplug RouterB and plugin the
loopback there, and run an extended ping from RouterA through the
loopback, and everything works fine, this verifies that my problem is
either my long cable or some type of hardware failure with my cisco
device (either router but more likely csu/dsu card) right?
Correct.
If that loopback test fails, this means the problem exist with the Telco
wiring right?
Wiring, configuration, repeaters, etc.
What are the extended ping commands that I should use for this test and
what am I looking for? Thanks again for all your help!
Ping with 0x0000, 0xFFFF, 0x4040 and 0x8000 patterns. Tell us if any of
them fail.
Very good source of information about T1 circuits is T1 A Survival Guide
by Matthew S. Gast.
Regards,
Andrey.
Thanks. I'll post the results. I also just ordered the book you suggested.
I do have one last (I hope the last) question though:
If I plug in my loopback wire into the smartjack where routerB is located,
and perform the ping test from RouterA, and everything works fine, then the
problem isn't with my Telco.
From here, I would like to verify that the problem is with the long cat5
cable and not with RouterB. To test this, I was thinking I could plug in a
short cable from the smartjack to RouterB, configure RouterB to have a
software loopback, and then run the ping test again from RouterA. If all of
that works fine, I'll do the same software loopback test from RouterA, but
with the long cable from the RouterB smartjack to RouterB. If there are
errors, then it's definately the line.
Anyway, I have a question about configuring RouterB for the loopback. If I
go into my serial interface configuration:
RouterB(config-if)#
There is a loopback command:
RouterB(config-if)#loopback
From here, there are several options:
RouterB(config-if)#loopback dte
RouterB(config-if)#loopback line
RouterB(config-if)#loopback remote
I think the command that I want to just test the circuit from RouterA to
RouterB (without going through the CSU/DSU card [which will just test the
external line]) is:
RouterB(config-if)#loopback line payload
Is this correct? If it is, then can I just run the same test you suggested
earlier to test the line?
Thanks again. Huge help. |
|
|
| Back to top |
|
|
|
| John... |
Posted: Tue Oct 27, 2009 10:45 pm |
|
|
|
Guest
|
Hey guys,
Thanks for all of the help on this problem. We were finally able to
coordinate with the ISP correctly and they determined that the problem was
on their line back to the CO.
Thanks again.
John
"Andrey Tarasov" <andyvt at (no spam) email.com> wrote in message
news:h9udod$18cf$1 at (no spam) news.aha.ru...
Quote: John wrote:
"Andrey Tarasov" <andyvt at (no spam) email.com> wrote in message
news:h9t99k$31jd$1 at (no spam) news.aha.ru...
John wrote:
Weird, my newsgroup access has been down for a couple of days. Anyway,
we replaced some hardware and nothing changed.
Andrey, I'm going to take your advice and perform the loopback testing.
I probably won't be able to test the problem router for a couple of
days, but will post the results when I do. Right now, I need to read
up on how to do loopback testing. 8-)
What loopback tests should I perform? If I unplug RouterB and plugin
the loopback there, and run an extended ping from RouterA through the
loopback, and everything works fine, this verifies that my problem is
either my long cable or some type of hardware failure with my cisco
device (either router but more likely csu/dsu card) right?
Correct.
If that loopback test fails, this means the problem exist with the
Telco wiring right?
Wiring, configuration, repeaters, etc.
What are the extended ping commands that I should use for this test and
what am I looking for? Thanks again for all your help!
Ping with 0x0000, 0xFFFF, 0x4040 and 0x8000 patterns. Tell us if any of
them fail.
Very good source of information about T1 circuits is T1 A Survival Guide
by Matthew S. Gast.
Regards,
Andrey.
Thanks. I'll post the results. I also just ordered the book you
suggested. I do have one last (I hope the last) question though:
If I plug in my loopback wire into the smartjack where routerB is
located, and perform the ping test from RouterA, and everything works
fine, then the problem isn't with my Telco.
From here, I would like to verify that the problem is with the long cat5
cable and not with RouterB. To test this, I was thinking I could plug in
a short cable from the smartjack to RouterB, configure RouterB to have a
software loopback, and then run the ping test again from RouterA. If all
of that works fine, I'll do the same software loopback test from RouterA,
but with the long cable from the RouterB smartjack to RouterB. If there
are errors, then it's definately the line.
Anyway, I have a question about configuring RouterB for the loopback. If
I go into my serial interface configuration:
RouterB(config-if)#
There is a loopback command:
RouterB(config-if)#loopback
From here, there are several options:
RouterB(config-if)#loopback dte
RouterB(config-if)#loopback line
RouterB(config-if)#loopback remote
I think the command that I want to just test the circuit from RouterA to
RouterB (without going through the CSU/DSU card [which will just test the
external line]) is:
RouterB(config-if)#loopback line payload
Is this correct? If it is, then can I just run the same test you
suggested earlier to test the line?
Thanks again. Huge help.
Well, if you can drag RouterB close enough to smartjack to bypass your
Cat5 cable, you can just run those patterns between the routers. No need
for loopback.
Regards,
Andrey. |
|
|
| Back to top |
|
|
|
|
|
All times are GMT
The time now is Sun Dec 06, 2009 1:22 am
|
|