atcomsystems.ca/forum Forums VOIP Phones & IP PBX Networking Looped T1 - errors incrementing

Sorry to chime in so late, but I do have to ask something of you Charlie. You mentioned that there is a patch panel for your circuit. Is it a standard CAT5/5e patch panel or is it one that is wired for RJ48 circuits? The reason that I ask is that I suspect it is just a standard one. That being the case, chances are that the wiring between it and the serving end isn't proper either. If both the transmit and receive pairs are not effectively isolated as much as possible (under separate cable jackets or separate binders in a multi-pair cable), you will likely have problems.

Are you in a co-location facility? I wonder if this is a case of multi-pair cable feeding the patch panel where appropriate isolation isn't maintained. As far as time-of-day occurrences, could it possibly have something to do with energy management in the building or worse-yet, proximity to other circuits that are bustling at these times causing interference? I'm just grasping at straws at this point.

Ed,
I'm not sure about the patch panel. I'll check tomorrow. You're right, your assumption may be correct in that the pp is RJ45.
I'll be on site tomorrow.
Thanks again for all the information!
Charlie

Guys you only see those types of serial designations if you are looking at a T1 with a V.35 cable. The document someone posted is for troubleshooting using a WIC-1T or a WIC-2T which are V.35 WICs. You will NEVER see this if you are looking at a T1 with an integrated CSU/DSU (RJ-48). Not to ruffle anyones feathers but this is a IEEE standard no one made anything up. I even went out and found a non-Cisco site if you care to verify this. https://telecom.tbi.net/v35.htm. Here is a guide for a WIC-1DSU-T1-V2.
https://www.cisco.com/en/US/products/hw/routers/ps214/products_data_sheet09186a0080091ff6.html
Notice in the middle of the page all of the diagnostics you can run on it.

That may well be, but I don't care how you shake it that is not T1 terminology. You tell a T1 tech your having a problem with your T1 because you have no DCD and they'll just give you a glazed look and walk away. Tell a T1 tech you can't ping and you might get pinged. These things used to drive me nuts when I worked in a test center. I have worked with people who have told me their T1 was down and I could see a good signal bothways so it might be looped right? You split the circuit to see if one end is looped and you're asked just what the heck did you do all are terminals just went down. Uh, you said your T1 was down. Well it is, my ABC can't ping my XYZ and I've checked all my stuff so it has to be the T1. :read:

To the point at hand. Trans and Rec in the same sheath can cause problems. I've never seen inter office ties cause it though.

I have not seen a new install with an external CSU/DSU in at least 5 years. If I gave you the indication that a V.35 cable is part of a T1 circuit it was my mistake, I do not believe this. I was merely attempting to clarify why serial terminology would be used in a circuit. As I am sure you know on a external CSU/DSU the T1 terminates on the CSU/DSU (RJ48 or DB-15). The CSU/DSU "converts" the signal to a standard V.35 cable and passes to either a molex DB60 or a 26 PIN "smart" serial interface on the router. The serial from the router can be V.35, X.21, RS-232, RS-449, or RS-530. So the same interface that I can interface to a standard modem can interface to the CSU/DSU and run a T1. This is where the serial terminology comes in. If you have the right cable you just plug the DB25 into the modem and plug the 60 pin into the router go to the port and execute the command "physical-layer async", configure the line and do a reverse telnet session. At that point you can issue AT commands to the modem and also receive calls into the router to do backup or to backdoor into it for administration.

I kind'a went off. Just a pet peeve of mine. If you have the tools isolate the trouble and report the right thing. The point I'm trying to make is if you report a T-1 trouble use the right terminology when you report it, it will save you a lot of grief in the long run.

There are still external CSU's, which of course you don't need if you have a built in CSU in your equipment.

I will give up now.

Guys, I'm back. We've been working this issue for months now. When I got all the interested parties on several conference calls, the techs from the providers saw errors and eventually "redesigned" the circuits. Two days after the redesigned circuits came online, we received a boatload of errors on my routers' interfaces. After more conference calls and numerous "exercising" of jacks, the errors subsided. The lines went clean for 13 days, then received several hundred errors. We went through more conference calls and providers on line. The circuits went clean for about 13 days again. Over this weekend, I had:
THERE ARE ERRORS ON THIS CIRCUIT
3 INPUT errors out of 381171 packets ( 1 out of 127057)
1 CRC errors out of 381171 packets ( 1 out of 381171 )
2 ABORT errors out of 381171 packets ( 1 out of 190586)
on one and:
THERE ARE ERRORS ON THIS CIRCUIT
31 INPUT errors out of 8211069 packets ( 1 out of 264874)
29 FRAME errors out of 8211069 packets ( 1 out of 283141 )
2 ABORT errors out of 8211069 packets ( 1 out of 4105535)

Now I'm hearing (from my provider) that:
"I am not certain that amount of errors is statistically significant. If we weren't putting these two T1's under a microscope, I am not sure these would have been noticed and generally speaking T1's get a few errors over time."

This is my first exposure to T1 circuits. However, in a previous position I had 10 Gig circuits passing more bits across the Atlantic and Pacific getting ZERO errors. I want to respond that the statement from my provider is wrong, but not dealing with T1s before, I don't want to miss-speak.

From a data standpoint, do T1's get errors on a periodic basis? Or should these lines be clean? I'm leaning towards the latter, but again...

Thanks for your help in the past and hopefully on this question.
Charlie

No, a good T-1 won't have errors. Back to the original question way back when. Are you testing JUST the T-1? T-1's don't put out packets. The only things I recognize as T-1 terminology is the CRC and the Frame errors, but again the way your using it is not in T-1 lingo. If the T1 and I stress the T1 has CRC errors that is usually a connection (copper, jack etc) problem.

Have you ever taken a T-Berd or similar piece of test equipment and tested this end to end?

Like Bill said, a good T-1 should be error free, but if you happen to be in an area with a lot of new construction, there are a lot of hands in the telco/provider's network. As your provider said, if the ckts were not under a microscope, you probably wouldn't have noticed. All it would take to cause those errors, if they are coming from the t1, is for someone to cross you with another ckt for just a second while wiring up another customer at a dsx location (not much room between pins) or they could be from a mux in the telco/provider's network, switching paths for some reason.

Are both t-1s taking errors or just one of them? Also, you might want to double check the settings for timing on your csu at each end. It's possible that your csu is reporting what is known in t-1 language as frame slips, as frame errors, which are caused by the timing getting off.

Hope that helps some.