T1 crc & frame errors -- ideas?

[randal]

Hey guys,
I've got a ptp t-1 that is being weird. It's a Qwest loop, and from what their techs say, it is in good condition -- hard looped both ends and run a couple hours of tests, and it came back clean. Qwest assures me that they do not provide timing on the line. Layout is as follows:

Cisco 4500 -- Osicom RouterMate DSU/CSU -------------------Qwest Loop---------------------Adtran TSU100 -- Cisco 2500

The osicom is providing timing, and the adtran is set to network timing. I am using manufactured utp, and Cisco v.35 serial cables on both ends.

Problem is this ... the A end (4500) sends the packets on down to the Z end (2500), and the Z end shows lots of CRC & frame errors. In about 5 minutes after a counter clear, I have 44 crc and 16 frame input errors. The A end reports no errors at all, incoming or outgoing. I'm running B8ZS & ESF all over, and have verified that the Qwest people are running the same.

Anything I should look at or change to try and clear up these errors? Occasionally the line drops completely, and I have to unplug one end, wait a minute, then plug it back in -- it magically comes up after that, but then the errors resume.

Ideas?
Thanks,
randal

 

[L3Guy]

The first thing that comes to mind is that Qwest is also furnishing timing, and you are getting timing slips.
I know that Qwest isn't supposed to provide timing, but they are a Telco. ( All the bells revel in mediocrity )
I would turn off timing on your box and see if the circuit runs "without timing" (impossible, but ...)

The other thing to ask is a CSU loop back, rather than a smart jack loop back. This will test all the way to your router, including your premises wiring. The Telco does not do this unless specifically requested. They tend to test their stuff, and then wash their hands.
(The "Not my problem." syndrome)

HTH

Doug

 

[randal]

Took your suggestion today and set the A end (4500/osicom) to network/slave timing, and nothing changed. Which is bad. I continued to transfer files, vpn, terminal services, everything across this supposedly un-timed line. When I set the A end to use External timing, the A side does go down (due to no external timing attached) but the Z side seems peachy keen -- it gets lots of errors, but it doesn't go into red alarm mode. I set the A end back to network timing, and voila, the circuit comes back up ... even though I'm not putting timing on it.

So I call the Qworst guy, and he tells me that they do not provide timing. At all. No way. He was watching the CO for timing though, and I set the A end to DTE timing, and he saw no timing errors coming across the line ... set it back to network timing, and he reported no change in line condition. So obviously there is timing coming from somewhere, but that particular tech was unable to do anything about it, because his config says that they are not providing timing. He went and talked to the one of the DS0 guys, and they said yea, shouldn't be any timing.

So, there is timing on my line. The tech told me to call back the next time the line went down, and they'd go from there ... The next step for me is to call the local Qwest office and get an install tech to come check my line for timing with a Tbird. The problem is not that they are providing timing -- I could handle that, no sweat. It's the fact that their timing isn't 100% reliable -- even when running off of their timing (network/slave on both ends) I am still getting loads of crc & frame errors.

Any more ideas / suggestions?
Thanks,
randal

 

[ScottMac]

Maybe try dropping your LBO parameter (as in, make it a stronger signal ... less negative). The LBO (Load Build-Out, I think) is like a transmitting signal strength / equalization. Maybe if Quest can detect your clock (at the higher strength), they'll drop the one they are sending .... I dunno, I'm throwing a dart here.

I s'pose it's conceivable that the cable to the SmartJack is less-than-wonderful. The original "Premises Cable" used for T1 (CSU to SmartJack) was two pair that were individually shielded, covered by another full jacket shield. UTP / Cat5 usually works OK as a substitute, but on longer runs ...maybe it's a factor. Maybe try another (known good) cable.

Have you tried another CSU/DSU? Maybe the Ossicom has bit the big one and is unstable or leaky (or took one-too-many environmental power surges).

Basically, I agree with Doug / L3Guy, Qworst is your most likely target, I'm just trying to add some other possibilities. The T-bert is gonna tell the tale, and probably get you a professional shoulder shrug from the company ("Golly, who'd a thought it? ... I'm SURE we checked that line out, it was OK yesterday....."). You know, all them damn customers messing with the line settings back at the CO....sheesh.

Good Luck

Scott

 

[randal]

As is, my LBO is zero on both ends ... I'll try cranking it up a notch to see if that resolves anything -- maybe I can out power their LBO? I've heard that there are issues with increasing the LBO if there is a smartjack in the way, which I'm pretty sure there is as this T-1 was installed < 2 months ago. I'm also kind of afraid to turn it up because the Z-end to CO is less than 2 blocks, and from that CO to the A end is less than 8 blocks ... the T-1 is a hair under a 6 block run (total for the loop).

The T-1 enters the Z end building and is run about 8 feet down a wall and into the Adtran DSU/CSU -- I figured bad cabling, so I replaced that, first thing. (Spidey's Rule #1) It persisted. From the DSU/CSU to the cisco is about a 10' long cisco v.35 cable, which I have also replaced (on both ends, same cable). At the A end, it comes into the punch block in the bathroom, goes through a wall and goes about 10 feet to the A end dsu/csu (osicom), also with a new, manufactured cat5 utp cable. That's the only reason why I haven't increased the LBO -- it's such a short run, there is little room for dB loss ... can someone with more experience than me weigh in on this and the smartjack thing above?

The Osicom is in a rack with 5 other Osicom DSU/CSUs -- They share a common power backplane, but are completely individual units, running off a power conditioner, running off a battery array, running off of 2 city power grids. I have rotated among the 3 open slots, and the issue persists. Only other hardware thing is the old Adtran for the CPE. Don't know if they'll be too hot on buying a new dsu/csu, but I know I can e_gay one for < $150.

In speaking to the Qwest guy, I felt really disgusted. When I tell them that I am not providing timing in any which way, and that there is still somehow timing on my line and the tech just shrugs his shoulders, it makes me want to kill somebody. Manager, who is less than technical, is little help. Guess I'll have to dig up an installers phone number and get him to come by and do some bert testing and find out wth is really going on.

If any other ideas pop up, I'm very interested in hearing them --
Thanks,
randal

 

[spidey07]

In speaking to the Qwest guy, I felt really disgusted

Escalate until you get to the director or VP of cusotmer services. CRC and frame errors are usually caused by bad timing, but seems like you've taken care of that. Have them loop your CSU and run tests.

But 98 times out of 100 with WAN and PTP circuits it is the provider who has "mucked" with your circuit. Escalate until you receive satisfaction/resolution/year of free service.

 

[randal]

Just thought I'd drop a line and let everybody know that my T-1 error/crc issue is fixed.

Recap is that I was getting tons of crc & frame errors, and the line would go up and down sporadically all the time. I checked my equipment, got 2 sets of new equipment, and the issues persisted. Finally broke down and popped the deposit to get a Qwest technician out to my house. He whips out a TestPad 2000 tbert and declares the line clean and gets ready to leave. I ask him to check the extended demarc, he does, it comes back clean as well. Not letting my $150 slip away so easily, I got him to replace the NIU in the smartjack as well as the card at the CO.

So far, we've got ~30 hours on it with zero errors -- and the roommates are happy. Moral of the story? When you know your stuff is good, make your LEC start replacing things.

cheers!
randal

 

[ScottMac]

Did he run the full BERT ? According to some of the guys that work in my cubicle-neighborhood, alot of folks only run a partial test because the full test take a while. The problem is that all the really "good" tests don't run with the abbreviated version.

they've had a couple problems lately that showed up on extended / full tests that never came up on the short / abbreviated / interrupted tests.

FWIW

Scott