ISDN-SGR & SYS-LINK Errors, T1's Bouncing?

[Toni269]

I have been receiving the following errors:
ISDN-SGR
SYS-LINK PRI
SYS-LINK RSCL

I have called Avaya several different times regarding this and they say that our T1's are bouncing, and it's all circuits. I have five T1's between two carriers. I find it hard to believe that every single T1 with two different providers can be having the same error at the same time. I have opened trouble tickets with both carriers on this and they both gave the same answer "nothing's wrong". Does anyone have any other ideas? Thank you.

 

[nknook]

You could check the time of occurence, if it is on or close after the time the system maintenance-cycle is executed (you can see when this happens with "disp sys maint&quot, it is most likely caused by Definity (though it doesn't necessarily have to be a Definity problem).
In the maintenance-cycle all kinds of tests are performed, and some include sending ISDN status messages, if the public switch doesn't respond in the correct way, Definity raises an error. There might be a protocol mismatch, either because the provider doesn't fully support the used ISDN protocol, or because the Definity was programmed with the wrong protocol. An example: the ISDN-line might use the ETSI standard, and the Definity country protocol 5, both are interoperable (just about everything will work), but there might be some oddies.

You should also check any other errors occuring on or about the time the ISDN errors occur, they might be related (maybe a faulty maintenance or tone-board etc).

Cheers,
Nico

 

[telcoguy]

There are two likely sources of ISDN-SGR errors; TDM bus and public network.
If you do a 'disp err' you should get a number of lines like this:
1 ISDN-SGR 3928 16157 07/10/18:09 07/19/14:20 14 0 0 n n.

The AUX data and the error type,
should explain you what the error exactly is, and from which side the errors come.
The explanation of the error codes are in the system manuals. (555-025-101)
My experience is that this works both ways.
1 lines start to produce errors, the TDM bus gets flooded with errors, and the other lines start to produce errors as well.
You can test if a specific board is faulty by 'test board <loc> long command.


Rob

 

[Toni269]

The errors are happening every minute or so, so I don't think it's the system maintenance. I just started getting this error after our R10 upgrade, where a Med-Pro board was added. Someone else had suggested moving the Med-Pro board to another cabinet to reduce traffic (coming from D-Channels in the same cabinet). If I test the boards is that service affecting? Meanwhile I will look up those error codes, thank you for providing the documentation numbers.

 

[netcon1]

One other item is to disp sync and see what the primary and secondary clocking sources are if any.

If there is a primary PRI circuit that you have you may want to clock off of that.

Also clocking gets a little funny when you have several T1 and PRI circuits from different carriers on your switch.

The sync is trying to clock off of one of the T1 or PRI circuits, however, it clock sysnc may not jive with the other carriers clocking.

Try clocking off one of the other T1 clock sources and see if the problem changes.

However, make sure there is a sync clock source.

Just a thought.

Netcon1