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

 

[merlinman]

Print the error loog and see what it says.

There very well may be a clue there.

 

[Pepperz]

Make sure one switch is set to "network" and the other to PBX. Make sure the D channel is not in the pool, and verify one is synching from the other - one set to local and one set to loop. The PRI should work better tean the tie setup, so it's probably something in the programming.

Pepperz@charter.net

 

[ken1713]

Does the pri work all day long without errors and only stop at night? Did you check the csu if external? How about the power going to the switch or the csu?

 

[killbox]

Thanks for tips.

Pepperz, everything is good up until the part where it says local and loop. Where is this? What's the path if you don't mind? Local is the PBX and loop is the Network?

Ken, yes it will work all day. It is the DS1 board with the built in CSU/DSU. Everything going to the system is fine. This was working for months just fine, up until we set it up as PRI.

KILLBOX

 

[merlinman]

And the error log says????

 

[Pepperz]

Under lines and trunks, set the synchronization accordingly. If you have another T-1 for LD, the LD T-1 should be set to synch off loop, and on that same system, the point to point card should be set to secondary source and local.

Pepperz@charter.net

 

[killbox]

Pepperz

There is only 1 T1 card. It's for the point to point. Should this be the primary or secondary? If the secondary, what should be the primary?

Even the merlin network side (Satelite office) should be set to local?

Killbox

 

[Pepperz]

If the point to point is the only T-1:
Sys A, say T-1 in slot 3==> Set Slot 3 to primary synch local
Sys B, say T-1 in slot 2 ==> Set Slot 2 to primary synch loop.
Set Sys A to be Merlin-Network
Set Sys B to be Merlin-PBX
Doesn't matter which end A or B is, just so they are different.

Pepperz@charter.net

 

[killbox]

Ok, I just checked this. This was set, but the pbx side was to local and the network to loop. I reversed it to see if it helped. The D-Channel isn't in a pool and is not part of lines under PRI->B-Channels->Lines. Unless it should be under there?
Anything else it could be?

Everything looks good. Does it make a difference if I also told you that the 1st 12 channels are being used for data?

The Error logs show MisFrame and loss of signal. Also B-Channel not released, as well as PRI SVC Audit TImeout, and D-Channel inoperative.

Thanks,

KILLBOX

 

[Pepperz]

Misframes could be a circuit problem with carrier. Getting them to admit it is another issue. If the circuit is good, however, that leaves equipment / programming. The D-channel should not be part of the pool or lines or b-channels. You may find somethng out by swapping the crds at the two locations. That way, if one of the cards are goofed, the errors will follow it.
When you set up a split T-1 the way you are doing, you need to get it up first for voice on all the channels, then strip off the data channels. I've never beed able to get it to go splitting it first.

Pepperz@charter.net

 

[killbox]

That's the way I set it up. So all is good then. I switched the clock sync aroung though, just to see. What about switch identifiers. I have the PBX side set to 1 and the network side set to 20. Or should the be set to 1 and 21?? The D-channel should not have a identifier set, correct??

KILLBOX

 

[Pepperz]

Neither.
Set one side to 21, the other to 22

Pepperz@charter.net

 

[killbox]

Even if they're over 200 miles??

 

[Pepperz]

If over 200, set them to 01 and 02 respectively doesn't matter which one is which.

Pepperz@charter.net

 

[killbox]

I DON'T UNDERSTAND?? Everything is right. It did it again this morning. The problem is, when it was set up as all tie, it didn't do this. I don't know what to do next?

Thanks,
KILLBOX

 

[TravelingTom]

Killbox,

I have been watching this problem. Did you ever check the error log as suggested by Merlinman? This will tell you what time of night the link is dying. If the link is up all day then I would think there is something external going on and not in the programming unless there is something programmed in the switch that coincides with the time the link is dying.

 

[killbox]

Tommy, yes I did check the error logs. I posted them above. The Error logs show MisFrame and loss of signal. Also B-Channel not released, as well as PRI SVC Audit TImeout, and D-Channel inoperative. The satelite primarily shows PRI SVC Audit TImeout in the error logs. I don't have anything in the system in relation to specific times. I'm now at the assumption it's telco. But why now. It was working as tie and now a problem as PRI?

I see the PRI SVC Audit TImeout the most in error logs. This always comes first.

Thanks,
KILLBOX

 

[Pepperz]

If not hardware, (which is still possible), could the point to point have been borderline, but when the signaling changed to PRI, have overstressed it somehow. (A reach, I know). Since it is quite a distance for a T-1, consider this: sometimes the folks don't talk well on the two ends of a point to point if they happen to be different Telco's. It is possible that it isn't B8ZS / ESF the entire way, or that the equipment in Telco land isn't as beefy as they would like to think. Since it is failing at night, when presumably the traffic is slower, it could be hardware, it could be Telco. If there are misses and slips, it's usually the circuit. Have you done a printout of each PRI circuit setup and compared them side by side? If it is intermittant failure, then it's going to be very hard. You may have to swao out hardware with known good equipment to prove Telco wrong. The PRI Service Timeouts are characteristic of a downed D-channel. One last thought, how about the CSU/DSU component, are they both internal?

Pepperz@charter.net

 

[killbox]

The sight actually is a few miles away. I just was asking for my own knowledge about the over 200 miles. Sorry if I confused the situation. Both CSU's are internal, and everything was working fine before PRI. They are actually going out over the same co I believe. Now a D-Channel down, or time out would be the system right? The magix is providing the d-channel. The satelite office has the audit time out errors, and the pbx side has primarily misframe and loss of signal errors. Does telco do routine maintenance every night? Maybe that's what's happening?

Thanks,

Killbox