1 edit | Flapping PTP T1 on Cisco 1721's This is driving me nuts! I have a PTP T1 between two Cisco 1721's, each with a WIC-DSU-T1 card (V1, not V2). Both sides have been configured with T1 defaults (ESF framing, b8zs linecoding, timeslots 1-24). One site is set to internal clock source, and one site is set to line, and both are configured for PPP encapsulation.
Now, I get calls from the contracted tech supporting these routers and he says the T1 goes down about once an hour for a period of about 15 seconds. When I remote in, I see lots of Input Errors, all in the form of CRC, Frame, Abort, Interface Reset and Carrier Transitions. Now, from experience and research, these are the steps I have taken to isolate the problem.
1) Performed numerous hardware loopback tests on each CSU/DSU using extended pings tests. All ping tests had 1500 byte sized packets, various datagram patterns (0xffff, 0x0000, 0x0101, etc), each test consisting of about 2500 pings. Both WIC's tested clean.
2) Had the contracted tech test each cable, both came back 100%. They are solid copper shielded twisted pair, about 10 feet a piece.
3) Had the telco do their tests. Don't know what they did but they claim they are clean on their side.
Cisco's serial line troubleshooting doc indicates that these errors are produced from mismatching is framing and clocking configurations, or bad cards, or bad cables, etc. I have eliminated all of these as a possible cause. I cannot seem to track down the cause. When I do test and stress the circuit, I cannot reproduce any errors.
Any ideas as to what I am missing? Do I need to specify the clock rate on the router that is set to internal clocking? |
|
| Are you seeing errors on both routers? |
|
 rolandeCertifiablePremium,Mod
join:2002-05-24
Columbus, OH | reply to durty_nacho
Why are you using internal clocking on one end? The telco should provide the line clocking. As long as both routers feed their clock from line they should not get out of synch. |
|
|
|
| reply to durty_nacho
Errors are on both routers. This is a PTP, so the telco does not supply any clocking. That is why I have one set to internal, and one to line. This is the correct configuration. |
|
| reply to durty_nacho
Are you logging to a syslog server to see if the router is dumping any messages?
I've had a similar problem in the last few weeks. Everything tested clean from the LEC and after they did some obtrusive testing it cleared up. I have had the same thing happen on more than one occasion. My guess is that there is something that happens at the end of the test, maybe a restart of the smart jack, that resets and clears the problem. I have in the past cleared this type of problem up by pulling the card out of the multimount and then waiting a few minutes and sticking it back in.
It may or may not be the same thing you are seeing but it's worth a try. |
|
rolandeCertifiablePremium,Mod
join:2002-05-24
Columbus, OH Host:
Linksys
AT&T Midwest
| reply to durty_nacho
Regardless of whether it is Point-to-Point or not, you are saying the telco is not providing any clocking? Telco used to provide clock on any type of circuit. I never had to force the clock local on any p2p circuits back in the mid to late 90's. The default line clock was always good enough. |
|
 sporkmedrop the crantini and move it, sisterPremium,MVM
join:2000-07-01
Morristown, NJ
 ·Optimum Online
| said by rolande:Regardless of whether it is Point-to-Point or not, you are saying the telco is not providing any clocking? Telco used to provide clock on any type of circuit. That's been my (rather dated) experience as well.
My rough understanding is that if there's framing on the line, the clock is recovered from that by the csu/dsu and that lets it know how to dump the bits into the circuit, like a train with cars passing by, you dump your bits in each car. If you set your own clock on such a circuit, you'll end up occasionally trying to stuff bits into the locomotive, which is not where they belong. I think that's the worst analogy I ever came up with, BTW.
An example of where you'd supply your own clock/framing would be something like a lab setup where you connect two csu/dsu units back to back with no electronics in between. One end would supply clock, the other would recover it from the framing. |
|
| reply to rolande
I've heard cLEC techs talk about Bell blocking clocking on P2P T1s but I don't think I have ever had run into that before.
Our T1s are delivered on DS3s and the CLEC we deal with provides clocking off of their DACS. It won't hurt anything change the clock source. Doing that would help to rule it out. |
|
nosx
join:2004-12-27
00000
kudos:5 | Usually frac Ts going into 1x0 DXCs get clocked by telco, but full T1s dont get clocking from the wideband DXCs. If we order a T1 from the LEC, they deliver it to us at the CFA usually riding a group of channels on an anything from an DS3 to an OC12. We xconnect that through between usually 1 to 3 different dxcs to our PE router. On our Ciscos we set the clock source internal on full T1s, customers just set it to line. The DXCs dont provide the clocking. In point to point private line world things might be a little different, but i can certainly cook up 200 different causes of intermittent errors on the line. If your in bellsouth terroritory make sure you dont have one of those stupid hyperedge smartjacks, there are some settings in those things that can cause weird errors. Are you seeing the errors on both sides of the ckt or just at one end? If you remotely loop the far end CSU can you run to it clean?
A-------B
loop A toward B, test patterns from B to loop at A.
loop B toward A, test patterns from A to loop at B.
If those test clean over an extended period of time, im not sure what to tell ya. The telco can dispatch somebody with a testset and run head to head if you really want to get intrusive. One possible suggestion in the mean time would be to remove LMI (keepalives) from the ckt. (im under the assumption your running frame-relay of course). No keeps will mean line protocol will never flap on you due to errors and at worst a couple packets get corrupted or dropped. If your running PPP you might be able to crank up the keepalive interval as well, altho i havent done that one personally. |
|
 jester121Premium
join:2003-08-09
Lake Zurich, IL | reply to rolande
In Chicago at least, our AT&T DS1 (point to point) circuits require "clock source internal" on one end and "clock source line" on the other. When we first set up the lines they would dump about once an hour until we got this figured out. |
|
| reply to durty_nacho
Thank you for the responses. I am running PPP, and I will try that increase in keep alives that you suggested blackmag.
On a PTP, at least in Dallas here, the telco delivers the circuit to each end but the routers on both ends have integrated CSU/DSUs on their WICs. One end acts as the CSU and provides clocking, and one acts as the DSU and listens on the line.
I had the telco run more tests, they found errors, and fixed them. I was seeing Input errors out the yang on both ends, and also a ton of interface resets and carrier transitions (as said above). Now the resets and transitions seem to have stopped all together. One end is clean of errors, but the other is not.
We have made progress, thanks for all your help. Now at least the errors are isolated and will be a bit easier to figure out. |
|
sporkmedrop the crantini and move it, sisterPremium,MVM
join:2000-07-01
Morristown, NJ Reviews:
·Optimum Online
| said by durty_nacho:One end acts as the CSU and provides clocking, and one acts as the DSU and listens on the line. You're actually using both CSU and DSU functions on both ends. The CSU faces the telco and deals with the actual DS1 inband signalling and stuff, loopback, testing stuff and the DSU presents the data on a (virtual) DTE (serial) interface.
Don't look on wikipedia for that info, I just found the suckiest definition of that stuff I've ever seen there. Newton's FTW. |
|
sporkmedrop the crantini and move it, sisterPremium,MVM
join:2000-07-01
Morristown, NJ Reviews:
·Optimum Online
| reply to jester121
said by jester121:In Chicago at least, our AT&T DS1 (point to point) circuits require "clock source internal" on one end and "clock source line" on the other. You know what's really frustrating about all this is that way back when I started having to support T1 lines (we were selling internet access over them), was that NYNEX/Bell Atlantic could never, ever give us a straight answer and/or explanation about clocking on the line. Some guys swore up and down that it should be line source on both end, others that it should recovered from the line on one end and generated on the other. I think I even had one guy tell me that both ends should supply clock - his explanation was that RX had one clock and TX had another...
Are telcos any better in that regard these days? |
|
 yaplejPremium
join:2001-02-10
White City, OR | reply to durty_nacho
I have dealt with a few ptp DS1 lines, and normally your telco will have a DS1 NIU as a demark point in your facility to hand you the connection.
Qwest is using Adtran NIU's like this one.
»www.adtran.com/adtranpx/Doc/0/VR···-22B.pdf
If this is your case then the NIU is providing the clock source, and you need to set both routers to line for their clock.
If your getting dry unloaded copper pair from point A to point B then, and their is not NIU involved then you will need one router to have clock set to internal. Normally the telco does not do dry copper anymore.
--
Open Source WAN Accelerator
»trafficsqueezer.sourceforge.net/ |
|
 jlramirezPremium
join:2004-10-01
Sugar Grove, IL | reply to sporkme
said by sporkme:said by rolande:Regardless of whether it is Point-to-Point or not, you are saying the telco is not providing any clocking? Telco used to provide clock on any type of circuit. That's been my (rather dated) experience as well. My rough understanding is that if there's framing on the line, the clock is recovered from that by the csu/dsu and that lets it know how to dump the bits into the circuit, like a train with cars passing by, you dump your bits in each car. If you set your own clock on such a circuit, you'll end up occasionally trying to stuff bits into the locomotive, which is not where they belong. I think that's the worst analogy I ever came up with, BTW. An example of where you'd supply your own clock/framing would be something like a lab setup where you connect two csu/dsu units back to back with no electronics in between. One end would supply clock, the other would recover it from the framing. Like Jester, all of our AT&T p2p T1 circuits in the Chicago area require one end to provide clocking otherwise slips occur.
--
Fiber Optics is the future of high-speed internet access. Stop by the BBR Fiber Optic Forum. |
|
