Point to Point down every morning still !

[killbox]

I posted this same problem a couple weeks back. I don't know what to do anymore!!

I have to Magix systems networked over a point to point with centralized VM. It's programmed as a PRI (MagixPBX and MagixNetwork). All the programming is right. I went over every end of it with multiple people. The alarms I'm seeing is PRI Audit Timeout mostly.

Everymorning the customer has to come in and reboot one of the locations to get it back up and running. We're doing voice and data over through the DCD board. Every morning you come in, the data is fine and the voice is down. We had this set up as tie at one point instead of PRI, and it didn't happen like then. I've also swapped all the hardware out as well.

Any ideas??

Thanks,
KILBOX

 

[merlinman]

Is this the one with 571M Cards?

Perhaps a Long MONITOR SESSION may be required?

Or - a T-Bird thing??

Also, what errors are in the system?

Is it loosing power overnight, and not doing a clean re-boot?

 

[killbox]

No, we have the 100 DCD boards. The system alarms are the PRI SRV Audit Timeout (Primarily this), D-Channel inoperative, and DS1 misframe. I've swapped all the hardware out.

Telco check it when it was down. They said when it was down they couldn't loop the CSU on one location. SO I swapped the card out. Then it still happened.

I just don't know what to do?

KILLBOX

 

[dromero]

I have seen one ptp with similar intermittent problems once. The solution was to separate tx and rx pairs onto separate cables, due to a long extended dmark run of over 400'

Multiple T1's on a long riser cable will eventually cause odd problems.

 

[franke]

I couldn't tell from your previous post(s), but are you running data over this T1 as well?

franke

 

[Dexman]

If telco is using a smartjack of some kind (such as a 3113 or something similar), they could try to loop the unit when the circuit goes down. Maybe something is happening to either the unit at the customer prem, or to the mate unit back in the C.O.
Some smartjacks log alarm events in a history buffer and the buffers, if they are provisioned properly, can be checked to see if an alarm condition was recorded from the CPE or the network.
If telco has fiber into the building, then smartjack probably would not be used.

 

[kenkds]

Had a similar problem with a point to point T1 which was a Telco problem and not a switch problem. Install a loop back plug in your 100 DCD cards and see if they loop back. Run tests under maintenance and see if you have errors. Check and replace your patch cables. Bypass all of your CSU's for a couple of days and hook your 100DCD directly to the smart jacks. This will eliminate any additional equipment in the middle that might be giving you a problem.
The problem with the point to point that I had come across wasn't the switch, but rather the connection from the Telco demark to where the smart jack. The Telco Company tightened down the screw lugs so hard on the smart jack that it cracked the wire and intermittently would make and break the connection even though the connection looked good. The T1 would usually stay up most of the day and would be down the following morning.

Hope this helps
Ken

 

[killbox]

Yes, there's data going across it.

The Dmarc is right next to the switch.

There's external CSU/DSU, it's a 100DCD board.

Already swapped out all the hardware and the cables.

Everything was working fine when it was set up as TIE instead of PRI. Telco hasn't done anything new. This has been an existing circuit for a year and has been fine. After it goes down and the customer comes into the office in the morning, the data is working fine. It's just the phone network that is down. So he reboots the system and it all comes back up. What else is there to do?? The power suggestion was good. We're looking into that now as well. Possibly some type of alarm tie in with the alarm at night affecting the power. We're looking into all this now as well.

KILLBOX

 

[Pepperz]

External CSU/DSU? 100 DCD? Get rid of the external CSU/DSU. The D channel is messing you up on the external CSU/DSU configuration.

Pepperz@newper.net

 

[killbox]

I'm sorry. I was writing back to someone. I was saying external csu/dsu?, it's DCD board. I'm using the built in csu/dsu. Any ideas pepperz?

 

[Psmith5]

What version magix are you running?
The internal csu/dsu only works on Magix 1.5 and later.

 

[ken1713]

AVAYA has a Quality Protection Plan Change Notice 1346B issued. Here is the description of Problem: The Merlin Magic 100DCD board has a variety of limintations in the built in Data Service Unit (DSU) which may interfere with the ability to run diagnostic test on the comminication path, stop customers data communication and in some cases effect the voice communication. They then say the problem can be fixed by using an external DSU an disabling the internal DSU. You might want to try an external DSU just to see if that fixes your problem. They probably have a new card out to fix the problem. The expiration date of the notice states it has been extended to December 31, 2004. Don't know if thats your problem but it sure can hurt to try, You did everything else. This kind of problem can test your sanity and make you think of trying another profession.

 

[killbox]

Ken, see that's the funny thing. It's only the voice that will be down. The data will be working in the morning fine. We'll have to reset the system and then the voice side comes up.

Thanks,
KILLBOX