Magix PRI Point to Point keeps going down

[Delmar]

Have 2 Magix 2.2 systems networked, has been working, but now it keeps going down. Sometimes it will come back up by itself, sometimes it needs to be re-booted.

Have had ATT out today, they ran a stress test and found a problem, replaced one of the smart jacks, but the circuit still goes down.

I have replaced one of the ds1 cards, tomorrow I will replace the other one.

Here is the PRI config of switch 1

Slot 9 Switch: MERLIN-Ntwk

A System: By extension Base number:

A BchnlGrp #: Slot: TestTelNum: NtwkServ: Incoming Routing:
A 80 9 ElecTandNtwk Route Directly to UDP

A Channel ID: 1 2 3 4 5 6 7 8 9 10
A 11 12 13 14 15 16 17 18 19 20
A 21 22 23

A Line PhoneNumber NumberToSend
A 833
A 834
A 835
A 836
A 837
A 838
A 839
A 840
A 841
A 842
A 843
A 844
A 845
A 846
A 847
A 848
A 849
A 850
A 851
A 852
A 853
A 854
A 855

Here is switch 2


A Slot 3 Switch: MERLIN-PBX

A System: By extension Base number:

A BchnlGrp #: Slot: TestTelNum: NtwkServ: Incoming Routing:
A 80 3 ElecTandNtwk Route Directly to UDP

A Channel ID: 1 2 3 4 5 6 7 8 9 10
A 11 12 13 14 15 16 17 18 19 20
A 21 22 23

A Line PhoneNumber NumberToSend
A 605
A 606
A 607
A 608
A 609
A 610
A 611
A 612
A 613
A 614
A 615
A 616
A 617
A 618
A 619
A 620
A 621
A 622
A 623
A 624
A 625
A 626
A 627

Here are the alarms I get from switch 1.

DS1 LOSS OF SIGNAL ALARM 09/00 - - 09/26 06:55:23 6C01
A DS1 MISFRAME ALARM 09/00 - - 09/26 07:00:09 6C09
A DS1 LOSS OF SIGNAL ALARM 09/00 - - 09/26 07:04:26 6C01
A DS1 YELLOW ALARM 09/00 - - 09/26 07:04:45 6C04
A DS1 YELLOW ALARM 09/00 - - 09/26 07:05:29 6C04
A DS1 LOSS OF SIGNAL ALARM 09/00 - - 09/26 07:06:42 6C01
A DS1 YELLOW ALARM 09/00 - - 09/26 07:07:23 6C04
A DS1 LOSS OF SIGNAL ALARM 09/00 - - 09/26 07:14:17 6C01
A DS1 YELLOW ALARM 09/00


I am still thinking that it is a network problem but I cannot think of any way to prove it to them.
Board controller tests and internal loopback tests pass on both systems.
Is there anyway to isolate the probem to the network or the phone system?

Thanks

 

[glg01]

All the codes indicate a T-1 facility problem. Are you using CSU/DSU's on this circuit? If you are using the 100DCD's disable the internal CSU's and test without them. If you are using some other external CSU/DSU the bypass them as a test (run a cord from the 100D/100DCD straight to the smart jack). As often as it fails shouldn't take long to test. lg

 

[jonnybb1]

If it helps at all, I have two Magix (rev1 Ver6.0) networked over a PTP T!, that was having the same issue last year. It wasn't until I did the following that it was resolved:

1) Monitored the error reports
2) Had an actual Avaya rep look at the error reports
3) Replaced the T1 cards
4) Swapped out the CSU's
5) Ran new Cat5 from the NAU to the CSU's
6) Called the CLEC several times
7) Escalated the trouble tix to the CLEC several times
8) Threatened to go XO or MCI and cancel contract (several times)
Finally, after all was said and done, they re engineered a whole new circuit and did a Sunday night cut-over.

So far, so good after almost a year. However, this seemed to all start during the raining season and we are not there yet this year...

Good Luck!

 

[SYQUEST]

I would suggest you check and verify all DS1 wiring and connections between the 100D module and the MPOE or DEMARC. Wiring could cause all of those alarms.

....JIM....

 

[dagwoodsystems]

Everyone here is provided great advice. However, I'm with Jim on this one. It absolutly could be the carrier, but CPE is very often to blame.

What you call "switch 1" is receiving a Yellow Alarm...also known as an RAI. Remote Alarm Indication means that your far end equipment ("switch 2" I would guess) is reporting that it doesn't like what it sees from the upstream. If the fault is with the carrier, then you will likely see the AIS alarm in "switch 2".

If not, then you really need to revisit your wiring on the "switch 1" side. A loopback plug with coupler would be helpful. Place that combo at the end of your cable...just before it enters the DS1 card. Ask your carrier to run a quasi stress test toward switch 1, and see if the data corruption still occurs.

Tim Alberstein

http://www.dagwoodsystems.com

 

[glg01]

Are you set to time off of the loop on both ends? lg