Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

CCBM Example?

Status
Not open for further replies.

gregarican

IS-IT--Management
Jan 31, 2002
469
US
Long story, somewhat short. My company has a private DS1 between two locations. I provisoned it through Merlin tandem networking. HQ has a Legend with an Adtran Atlas 550 and the remote site has a Magix with an INA board. Since I have this provisioned as a fractional PRI, I have the primary clock source set as the 100D board on the HQ's Legend.

Once or twice a year the DS1 goes down and I have to open a TT with telco to resolve the issue. It's frustrating, so to monitor things I pull logs from either end of my CPE to see how the circuit is performing.

Typically looking at the logs I see anywhere between 2 and 20 errored seconds a day. Most all of these are logged as path code violations, which I understand are CRC errors along the circuit. In one 15 minute logging period yesterday I saw 136 path code violations. The circuit stayed up, but I opened a TT with telco to determine what they saw in their PM logs.

The tech replied that the circuit "looks clean" and there weren't any errors logged. Does this make sense? Could my equipment be causing/reporting errors while the circuit is error-free from telco's end? I'd think that we'd be seeing the same thing.

Is this a Webster portrait of Came Clear By Magic? I just want to ensure that the circuit doesn't need to be repaired in advance of another bi-annual drop :-/
 
Dribble errors on DS1 service can be the most frustrating to find. You might want to throughly check ALL connections and hardware, including the NIU for anything that may be suspect. Even oxidation on a plug or connector contact where the contact loses its "springiness" for proper pressure could cause this type of problem. With Modular Plugs and Jacks this is very possible over time.

The errors you are seeing, are they on both sides of the DS1? That should give you a hint of the direction that the problem may be coming from. If the monitor facility is proper, you should not have any influence connecting or disconnecting test equipment from the circuit. Are you using the monitor jacks of the CSU or NIU? What design is the DS1 circuit - copper T1 or HDSL type? What test equipment are you using?

....JIM....


 
I believe the DS1 is HDSL. As for the monitoring, I am not plugging into the monitor jack on the NIU's. I am looking in the internal logging facilities provided by the Magix INA and the Adtran Atlas. I see errors on both sides of the circuit. That's why I find it so hard to believe telco sees a totally clean DS1 without any errors at all when they pull 24 hour PM logs.

Checking the connections and whatnot is something I will look at in more detail than I have before. What I can't get over is that I'm seeing errors on both ends of the DS1 and telco doesn't see anything. And telco won't classify this as a chronic issue unless the circuit bounces three times in a month and the fixes involved their performing physical hardware/cable repair. We drop 1-2 times a year and that's a PITA to me :)
 
What kind of NIUs are being used on this DS1? You might want to get the tech document for the NIUs in service, those units usually have a serial port on them for diagnostics and circuit statistics that may provide some insight as to what is going on. By chance do you know the age of these NIUs? Over the years the NIUs for HDSL have had lots of updates to their firmware, but the Telcos (PB) usually just replace the NIU. Another problem can be the local loop cable pairs. Most recent NIUs have various LEDs. There should be a set for the loop that change color depending on hits to the ckt.

Do you have access to a T-BERD testset?

....JIM....
 
The HQ's NIU appears to be a basic ADC smartjack. The only lights I see are the standard pair and alarm ones. Nothing that would seemingly indicate circuit errors. The NIU's at the HQ end is over 7 years old, and the one on the remote site's end was replaced maybe 6 years ago.

I unfortunately don't have access to a T-BERD test set, but am wondering why telco sees a totally clean circuit. Maybe it is something at the smartjack, although in the past they have looped the smartjack and still seen a clean circuit when performing intrusive testing...sigh...
 
It would not hurt to power cycle the NIUs. When Telco does their testing they usually only test from NIU to NIU, so anything after that is not tested. You might request the next time you report trouble that they test to the CSU or loop the CSU to test, if yours is optioned for that, or put a hard loop to the CSU to test thru. Back to the NIU, the standard pair LEDs indicate by color whether they have had any hits or impairments. I would also make sure the NIU mounting is properly GROUNDED. I have found many loose GROUNDs in my phone closet/terminal visits over the years.

By the way what is the model number of the ADC NIU? I may look to see if I have that practice in my reference library for curiosity's sake.

....JIM....
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top