sundance-communications.com/forum Forums Wiring - Telecom Carriers - Trunks & Services T1's, CSU's and DSU's Errors on T1line

Can someone tell me if this means trouble from the Network side or from the Carrier side? I though CRC errors meant physical lines problems, but I'm a rookie with T1s and would apprecciate your support. Though this is my first post, I've been visiting the forum for over a month now, just reading through old topics and I have learned alot.

I'd appreciate any help here, thanks.

Admin> show t1 his
flags: S=SyncLoss,F=OutOfFrm,Y=YellowAlm,B=BlueAlm,Z=ExcessZeros,L=Loop

Elapsed T1 Network DSX-1
Time BPV CRC ES ESB SES UAS flags BPV CRC ES ESB SES UAS flags
00:15 1706 9 18 1 5 195 SFY.Z. 0 0 0 0 0 0 ......
00:30 1954 16 20 3 3 326 SFY.Z. 0 0 0 0 0 0 ......
00:45 54 25 35 5 8 95 SF.BZL 0 0 0 0 0 0 ......
01:00 91 41 65 9 9 43 SFY.Z. 0 0 0 0 0 0 ......
01:15 40 29 41 5 6 0 SF..Z. 0 0 0 0 0 0 ......
01:30 104 40 78 8 18 0 S...Z. 0 0 0 0 0 0 ......
01:45 245 87 101 18 23 0 SF..Z. 0 0 0 0 0 0 ......
02:00 185 52 90 7 27 0 SF..Z. 0 0 0 0 0 0 ......
02:15 256 52 68 9 25 0 SF..Z. 0 0 0 0 0 0 ......
02:30 467 121 153 21 27 0 SF..Z. 0 0 0 0 0 0 ......
02:45 869 83 95 13 19 0 SF..Z. 0 0 0 0 0 0 ......
03:00 964 74 96 13 27 0 SF..Z. 0 0 0 0 0 0 ......
03:15 245 80 104 10 26 0 SF..Z. 0 0 0 0 0 0 ......
03:30 330 115 148 22 45 0 SF..Z. 0 0 0 0 0 0 ......
03:45 923 76 102 12 24 0 SF..Z. 0 0 0 0 0 0 ......
04:00 423 108 102 22 19 0 SF..Z. 0 0 0 0 0 0 ......
04:15 202 90 111 15 29 0 SF..Z. 0 0 0 0 0 0 ......
04:30 153 48 55 8 14 0 SF..Z. 0 0 0 0 0 0 ......
04:45 984 62 89 10 22 0 SF..Z. 0 0 0 0 0 0 ......
05:00 580 84 127 18 36 0 SF..Z. 0 0 0 0 0 0 ......
05:15 140 68 92 10 23 0 SF..Z. 0 0 0 0 0 0 ......

First have to know which way we're looking. Are the counters resetting to zero at the start of each 15 minute interval? Where are you seeing all this? Where are the registers you're reading? Really don't have enough information yet.

The errors do reset every 15 minutes, I'm seeing this on the CSU/DSU at the site. It is a Visual Networks device.

But you have two sets of registers. If the left reading are from the Teco than it looks like you have a line problem, but I don't see how you can be loosing sync and getting UAS and nothing at all showing up on the registers on the right. What's the CSU at the other end showing? It really looks to me like the registers on the right are turned off. So you still need to know which way your looking.

The second set are for the DSX port I believe. (If I am reading that right)

Regardless, for me it's an obvious issue of getting errors from the line or the remote side. Have a ticket opened with the telco to test the line.

Has your client complained of any noisy phone calls or dropped calls?

I see what you're talking about Majestic, don't know why I missed that. The other registers still shouldn't be clean with incoming UAS and loss of sync, so I still think they are turned off. The far end is totally loosing the signal or it wouldn't be putting out a yellow, that's why I asked what the far end looked like.

Majestic was reading that correctly, customer was not complaining about noisy phone calls but they did complain about latency.

Anyway ticket is opened with Telco now...not sure of the results a co-worker took over the case, it's really not my job to work with Telco on that it's his...but I'm interested in learning and I can see you guys are experts...so thanks guys...

IP Data is always far more sensitive to errors than voice traffic. Errors can take data down but still allow "dirty" voice calls to work. Many people will hear a great amount of static with lots of errors on the line but the calls still work. PRIs get clipping more than static from my experience because they are digital in nature.

Are you seeing "packet loss" with the latency? If so, definitely REALLY bad. If not, it could be the customer is over utilizing their bandwidth?

Please be sure to update us with status.

Yeah I found the ticket, we got a LEC dispatch to check this out...don't recall if there was packet loss...but I have seen a few of those around here... In this particular case I think LEC is repairing cable pairs...