sx2000 pri sync issue

I'm getting these errors many times a day...

2005-JUN-24 14:45:36 MAINTENANCE A/Active MC270AA PRI T1 at location 03 1 03 01 Type of diagnostics : Background Scope of report : Hybrid Reason(s) for report: - Synchronization : Present

2005-JUN-24 14:45:33 MAINTENANCE A/Active MC270AA PRI T1 at location 03 1 03 01 Type of diagnostics : Background Scope of report : Hybrid Reason(s) for report: - Synchronization : Absent

dtstat shows 100% duty and no errors for both pris.

We have 2 PRIs from 2 different clec's, one inbound one outbound. This doesnt happen as *often* on 03 1 03 02. I've tried changing the network sync from 2,1 to 1,2 and that doesnt seem to make a difference. Should I ask the CLEC to run intrusive pattern testing or am I missing something?

Thanks Dave

Reply to
Henry Cabot Henhouse III
Loading thread data ...

Since dtstats is clear I'm assuming you're not dropping any calls... Have you tried looking at long-term dtstats? i.e., the command would be, "DT READ 3 1 3 1 LAST 24" What does that show?

Are you dropping any calls?

Try removing one of the synch sources from the Network Synch form and leaving only 1 source programmed. There was an obscure known product issue (KPI) in LW29, LW30 and LW31 having to do with the machine going into freerun when multiple synch sources are available. This didn't get fixed until LW32 mostly because of difficulty duping the problem in the lab.

This might -not- be the problem, however. Since both PRIs are on the same card it is indeed possible to have a problem with the card. Swap it if you have a spare (if you don't have one, you should), else unplug it and reseat it. Also unlikely, but check your RJ45 connectors on the cables. Beware there are different connectors for solid vs stranded wire.

For grins look also at your PCM totals. The command is "PCM TOT" - also doubt this would be the problem, but worth a look all the same.

Reply to
wdg

If this is the machine I'm thinking of it's either the older ½-cabinet non-redundant Light or else an ML, but either way a single MC that's not doing periodic activity transfers. I'm also pretty sure he's doing programmed reboots to recover memory.

It actually could be a digital level problem. If the Line Buildout (LBO) is too low (too much attenuation) the MC might be struggling to recover sync. That should be strappable on the card and/or settable at the CSU.

I wonder too when he sees these synch losses occurring if the system synch source is switching or not.

Reply to
wdg

The dtstat and pcm tot read all 0's. Oddly, tho, there appear to be no system errors, but around the times the card loses sync, users complain of dropped calls. If I have one sync source for both PRIs and that circuit goes down, does the other lose sync and drop out? A shame the 2000 doesnt have an external sync source option... I could put in one of those wireless doodads that the lecs, clecs, wireless guys use to sync time :)

We had to swap the xmit and rcv pairs for the 2000 PRI card (unlike the T1's, we used a straight patch cord from the NIU and the PRIs on the SX200s that are also straight patch cords). The patch cords worked 100% for the previous T1's... I'll redo the xmit/rcv pairs on the patch bay and eliminate the crossovers (two rj45's back to back) we made.

By the way, I checked the maint log, and we didnt have any errors today.

Dave

Reply to
Henry Cabot Henhouse III

It's a Microlite lw29 q40. Non red. I have a dbms check every nite at 11 pm and a weekly prog reboot at 2 am Sunday.

It didnt happen today (Saturday), so I assume when it does happen, there's a normal weekday load on the system. And the log doesnt seem to show that trunk group going busy when it happens, but I do suspect there are dropped calls.

Dave

Reply to
Henry Cabot Henhouse III

Hi Dave

Is this a Light or Microlight ? Is the reboot or act switch set ?

sync is derived in part from the MC , Does the problem get worse when the systemis under load?

Ian

Reply to
Ian

Happened again today, 3 times, the last time caused a digital link failure and a minor alarm for a minute.

Tonight, I'm going to reseat the card and get rid of the back to back RJ45's.

If that doesnt clear it, I'll swap slots.

Argh. Should I try doing an lbo?

Reply to
Henry Cabot Henhouse III

Here's are a few error messages from the PRI maint channel... the calls going to 5638 are a result of the primary pri being OOS and calls being overflowed by the CLEC to the second PRI. Earlier, I reseated the PRI card and swapped the RJ45's. I'm going to call in a ticket to PaeTec and have them run pattern testing after 6 pm tonite. Argh!

*****************

| WARN GW | 05/06/23 13:31:01 | D-channel DOWN on AFC link 0 [dch.cpp @

1340]

| 1234 | warn AFC | 05/06/23 13:31:01 | D-channel is DOWN on link 0 | 6 | info AFC | 05/06/23 13:31:01 | Link 0 down due to PRI | 2

PRA2CP_decoder: no connid acard=0 alink=0 achan=-1 prim=0x6 connid=0xF95

| WARN GW | 05/06/23 13:31:20 | D-channel UP on AFC link 0 [dch.cpp @

1340] | 1234 | warn AFC | 05/06/23 13:31:20 | D-channel is up on link 0 | 6 doesnt happen as *often* on 03 1 03 02. I've tried changing the network
Reply to
Henry Cabot Henhouse III

Hi

when did it last do its reboot? or is it daily?

also i can remember the commands but you can get debug info from the pri half of the pri card. because dont forget its realy a dpnss to pri converter. personally i would reseat the pri and main controller. Ian

Reply to
Ian

You said in an earlier post that this is happening on both PRIs?

Is there some common denominator?

Do you happen to have a "Smart CSU" in the circuit (or one that you can put in the circuit)? It indeed could be a problem with the PRI card or the slot but it looks like you're dropping the D channel. A smart CSU would help isolate whether the problem is external to the PBX or not. (A Smart CSU, i.e., a stand-alone Kentrox T-Smart with a couple of DB-15 to RJ45 adapters, a T1 crossover cable and a 48v DC wall wart, makes an excellent "Poor Man's T-BERD")

Def>Here's are a few error messages from the PRI maint channel... the calls

Reply to
wdg

Boy, the comment about the smart card jogged my memory. Here is what happened to me, although it was on a standart T1, it might have some relavance. I have two SX2000 linked and from day one I would have intermittant loose of sync and the T1 would fail. When telco put the Tbird in they would see esf even though the circuit was designed as ami. The T1 was stable, but wierd, for 2 years. Then it really failed. Same thing. When the pbx's were operating, telco would see esf when they monitored it (I saw it on their Tbird). If you disconnected one of the sk2k's, all of a sudden the circuit would go ami. They would look at me and say, "see your machines are putting out esf" and i of course would say, 'that's impossible'. Loads of finger pointing and finally I got it escaladed to the point where I got 2 telco techs and they went head to head with the Tbirds.

So here we are, 2 pbx's up and running fine, 2 Tbirds at each end and both Tbirds showing esf and dtstat showing errors. Pulled the the T1 at the far pbx and both Tbirds show ami. I disconnect the near pbx and the circuit is ami. "see, your pbx's are esf', they say. OK, I say, put the far end Tbird to send a pattern and make it ami. "What the....?" says the near end tech. 'I see esf'.

Turned out to be a bad telco smart jack at the far end. The smart jack was converting the ami to esf and then back to ami before sending to the circuit. Of course it was not doing the last conversion and was sending esf. Changed the smart jack and its been perfect ever since.

Moral of the story. When telco says that a T1 is just a pipe and we don't do anything but pass the data, don't beleive it.

Reply to
Jonathan Williams

After an hour today of down up down up down up down up every 10 seconds, I busied the damn thing and had PaeTec run patterns. Spurts of noise to the Verizon NIU kind of pointed the finger at the LEC. And sure enuff, Verizon found a flaky card in the CO, replaced it, and now things appear to be running clean.

Now, if I could only get Paetec to put the PRI back in service on channels

2-23 I'd be a bit happier.

At least with all the great troubleshooting help here I could in good conscience call PaeTec with my woes.

Thanks much! Dave

Reply to
Henry Cabot Henhouse III

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.