From: Doug McIntyre on 23 Sep 2009 23:45 "John" <johnthompson1(a)hotmail.com> writes: >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. >- 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). >- 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*. >- 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. >- 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. >- 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. >- 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.
From: John on 24 Sep 2009 10:19 Thanks. What is the difference between this cable and a standard cat5? Is this one basically a cat3 with less twists that a cat5?
From: Doug McIntyre on 24 Sep 2009 11:08 "John" <johnthompson1(a)hotmail.com> writes: >Thanks. What is the difference between this cable and a >standard cat5? Is this one basically a cat3 with less >twists that a cat5? The main difference with the ABAM cabling is that each pair is individually shielded, and it uses 22AWG copper inside (which can be a problem if you are punching this down into anything, 66-blocks will take the 22AWG, but patch panels, 110's or Krone/BIX won't take the 22AWG wire, it'll be too big, it was designed for screw terminals). A real of Beldon 7838A is around $460. I also don't know of any that have Plenum jackets, which could very well be an issue, 7838A is PVC, and the stuff I've seen in the field is as well. You may run into fire codes preventing its use.
From: Andrey Tarasov on 29 Sep 2009 11:31 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.
First
|
Prev
|
Pages: 1 2 3 4 5 Prev: Config T1 with routed block Next: When is RELOAD not the same as a power off/on? |