Point to Point Down Every Morning

[killbox]

I have a customer that has to Magix release 2.0's networked over a point to point. They're set up as PRI. (Merlin PBX and Merlin Network)

Every morning the customer comes in and the network is down. Telco tests out good. They have to reset the Merlin PBX side every morning and then it works.

They were set up as TIE instead of PRI. After we set it as PRI, this started happening. Any ideas??

Thanks,

KILLBOX

 

[Pepperz]

Who knows what Telco does at night? Maintenance is possible, and a question worth asking. BUT, if the circuit were the problem, I'd think you'd see the same errors at each end. The fact that you don't says the systems are unequal. I'd try another card at the satellite office first, then at the Main. Also, since they aren't 200 mi apart, set one to 22 and the other to 21.

Pepperz@charter.net

 

[Pepperz]

Just thought of something.... always dangerous.... are you doing anything with either PBX on a nightly basis, maybe a backup?

Pepperz@charter.net

 

[killbox]

No maintenance at night except auto backup on Sunday at 2:00 am. I'm sure the cards are good, considering all was fine as the tie set up. I do have the systems at 21 and 22. I may have to call the carrier and see what they're doing.

Thanks,
killbox

 

[Ghostin]

don't assume the cards are good just because they worked with a different type of T-1. PRI's tend to be a bit more sensitive. I have seen a perfectly working t-1 card in DSS mode switched to PRI and fail all day long. That being said, the fact that it only goes down at night would make me believer the Telco is doing something and causing the circuit to go down.

 

[merlinman]

Are these T1 modules PLASTIC or MAGIX ???

That is, was this system upgraded to a Magix from a LEGEND?

IF it was, let's get the number off the 100-D card.

Ti will be 517_SOME LETTER_15.

THE LETTER is important.

 

[jinxs]

I had a problem where the CSU was set-up incorrectly. I had a cust set up for tie lines such as yourself. Then they wanted centralized VM. So we went and changed them to PRI, well, the idiot who set up the CSU's set up one as AMI. Then again, it isn't the same as your issue. This circuit worked for five minutes, crashed, then worked again for five minutes. Point is to check everything. I know you said this board was a DCD. Wasn't there a PCN on the DCD board with utilizing the DSU. Did you happen to try going to an external CSU/DSU...if at all possible...or, try disabling the DSU for one night....probably an even bigger improbability. Is there heavy Data traffic at night? Are the cleaning people turning off breakers? Is it on an UPS?

 

[killbox]

Ok, there is no activity at the site at all at night. I've checked all the programming over and over. Everything, is right. The systems are on UPS's. Everything is Magix boards.
I'm going to try and replace one of the boards with a new DCD board.

I just don't know what else to do?

KILLBOX

 

[jinxs]

Just out of curiousity, are your Automatic system back-ups set to daily or weekly? Probably not the problem, but would be the only thing taking place at night on a daily basis.

 

[killbox]

I thought that too. I have them set weekly.

Killbox

 

[ken1713]

Trouble shooting tips from an engr. suggest because it was a t1 first, to remove all programming by system erasing and reprogram. I would try removing all pri programming turning off system removing 100 card from slot for a minute reinsert it turn on switch and do a board renumber. Then reprogram pri. It seems a bit drastic to do a system erase. Can't hurt to try it, seems like you tried everything else. Good luck.

 

[Psmith5]

Set system A time while speaking with user of system B,to ensure accuracy.

Print the error reports for both systems for 2 days to determine if the ckt drops at the same time every night.

I suspect some component in the PRI providers network is running some routine, maintenance synch with other CO,s
Call and insist they look inward for the reason.

I had a case where the same problem was caused by 1 switch in the providers network kept reloading the old version of it's database every night, by the time it corrected itself our circuit had been down too long for an automatic resynch comand. We had to prove (through our error reports) it had to be the network, since the timing for the point to point PRI is coming the network and the PRI is the only thing common to both switches.

Good luck,