what does an "excessive Zeros"(EXZ) error mean?

[jpoulos]

We have a T1 that is giving a lot of Line Code Violations. The Telco says that they see the line testing completely clean. The Framing is set the same on both sides. I've done a lot of research, and I keep coming across this EXZ error tied to high line code violations. Does anyone know what this means, and what can we do about it? Thanks in advance.

Jpoulos

[svermill]

You need to check your line code at both ends. It should be set for either Alternate Mark Inversion (AMI) or Binary 8 Zero Substitution (B8ZS). Chances are that it should be B8ZS (especially if framing is ESF). With T-1s, timing is recovered from the transitions in the bit stream (notice that there is no seperate clock singal with T-1s - just tx and rx data). Without enough transitions to keep the clock circuitry locked, you end up with timing slips. So line codes ensure enough transitions are present. In the case of B8ZS, every eight zero is subtituted with a 1 and then corrected back to the true data pattern at the distant end.

[jpoulos]

I checked and both sides are set for B8ZS. Any other thoughts?

thanks,

JPoulos

[svermill]

Yes, as was suggested, go back to telco. If you have line code set correctly on both ends and are still having problems, it often turns out that a Digital Access Cross-connect System (DACS) is misconfigured. A DACS, unlike most telco equipment, actually terminates the circuit coming and going (e.i. it is not just a pass-through, such as mux). So a misconfigured port can interject framing/coding errors/violations even when you are all set up correctly at both customer premises.

[todd-m]

As posted by svrmill, this is referred to as 1's density. This is most likely a Telco issue. I recommend you escalate the ticket and demand the Telco to run an all 0's stress test on the line. they may be running a basic QRSS (quasi) test pattern that may not reveal the trouble.

[g.hillabrant]

The only problem I see with the Line code buildout error theory is mismatched muxs or dacs will throw massive CRC errors on the line. And he hasnt mentioned seeing CRC errors. Also when we test T1's we use quasi, zeros, and 3 in 24. The Dacs is the least likely spot of the trouble, more often than not the problem is in the HLU (CO office card) or the HRU (field card).

[svermill]

Greg,

Welcome to the mix. I always appreciate a different perspective because it is hard to be right about a troubleshooting problem that you can't see for yourself. But I am a little curious...how would a bad card not introduce CRC errors? I would think that if the frame is built and coded correctly by the end device, and something occurs to corrupt the bit stream such that the ones density has been violated in transit - regardless of where or by what - the integrity of the CRC check will be compromised. So while I think that it is never safe to be too presumptuous, in this case isn't it a safer bet that there might be CRC errors?

I fingered out the DACS (just as one of many possibilities) because it isn't just a transit device. I think that, depending on the DACS, it actually terminates the T1 coming in, moves the bytes across the fabric, and rebuilds the signal on the output. I don't know this to be true, and please comment if you know one way or the other, but I suspect that as the frame is rebuilt and re-coded on the DACS output port, the CRC is recalculated. If that were the case, the output port could be configured for the incorrect coding (or none at all?) and the CRC then determined. If that were the case, it is actually the only feasible scenario where the ones density could be neglected, and the CRC still match up.

Or is there something obvious that I am missing?

Thanks again,

Scott

[g.hillabrant]

Scott,

you're correct that line code mismatches even at the CO and field card will introduce CRC errors in the span. The reason I tend to lean away from the DACS as the most likely suspect is DACS mappings are very straight forward. What jpoulus didnt mention was if this is a new circuit or an existing circuit. Big difference in troubleshooting, as far as I'm concerned. Also I maintain roughly 15,000 T1's and I get line code problems every day, I would have to say that less than 1% of the troubles I work are DACS related. On top of that less then 10% of all my T1's even go through a DACS.

The reason I lean towards the cards is they are very sensative to electro static occurances (lightning, power surge, etc. etc.). They also have the most exposure to multiple peoples hands, and its very easy to config them wrong. He mentioned that the Telco ran the circuit clean, when they performed the test they most likely ran from the NOC to his CSU which uses all the mux's and dacs throughout the system. When I run this test and get the results jpoulus got Its almost always the customers equipement configed wrong.

What I would do to have a T-Bird on his circuit LOL. You do make some good points about the DACS though and I'll have to keep my eyes open for that in the future.

[svermill]

Greg,

Thanks much for the explanation. I would definately defer to your experience on this matter. I only work with the IXCs and LECs - you work for one of them.

I am surprised at how few of your circuits go through DACS. The LECs love those things. We, as customers, love them too. You probably are aware of something that most folks aren't - that DACS systems can provide timing for T1s because of that whole thing about actually rebuilding the output frame/signal. In the days before widespread GPS, we used to ask our LECs to run our circuit through a DACS and set the ports for internal timing. Since the DACS was tied to a stratum 1 BITS, we were better off that way. Now there are times when we don't want a DACS in the system, or we at least want pass-through timing so we can provide our own, and yet, suspiciously, there appears to be a clock somewhere in the cloud. One of the things that I do when a LEC tells me there is no DACS and, thus, no timing is I change the line code on one side (using a Fireber or similar). If the test set on the other end indicates the change in received line code, I know there isn't a DACS. If it doesn't change, I know that there is. And confronted with that evidence, the LEC usually "discovers" the phantom DACS and also finds one or all of the ports set to internal timing.

Have a great day!

Scott

[svermill]

Jpoulus,

I don't know if you have found your problem yet or not. I recently read that Cisco has the equivalent of a Line Build Out setting on these type of interfaces. The choices are 'cablelenght short' or 'cablelength long.' This is a controller command. If your run is long, you may want to change the setting to long. Don't know what the default is but I would guess it is short.

This is pretty much a long shot. But I wasn't aware of this option and thought of your problem when I read about it.