PRI Dropping on 61?

[hawks]

I have 2 PRI’s on a DUAL card in an Option 61 with RLS 25.30 software. It seems that every other night the 2nd span drops for a minute or so, most times it recovers but once in a while you have to manually enable it. The 1st span does not show any errors when this happens.
I get the following error from span 2 when it occurs:
DCH 7 IMSG SERVICE REF 00000000 CH 19 8 TOD 1:29:18
% STATUS: OUT OF SERVICE

It seems to happen after midnight routines run and only on nights it switches to CPU 1 at least that’s what I’ve seen the last week. Anyone have any ideas what I can look for on the CPU side maybe extenders or something or do you think it’s the PRI card itself? I do have a ticket open with the carrier to see if they see anything on their end but I'm not holding my breath.

 

[KCFLHRC]

If the spans are configured the same and in the same route I would rool the 2 circuits and see if the trouble follows the circuit. If it does then there's your answer. You said it seems to only happen on nights it switches to CPU 1, doesn't it switch every night? Stat your clocks and make sure they look OK. SSCK 0 and SSCK 1 in LD 60.

 

[hawks]

The spans are built as 2 seperate routes and dchannels. I did think about rebuilding them and switching them but I thought I would ask here first to see if anyone had any other ideas.
Yes it does switch cpu's everynight but the problem seems to happen on nights that it goes from 0 to 1. I'm going to watch it a couple of more times to make sure. The clocks look good everytime I look at them.

 

[KCFLHRC]

Seems I remember a similar issue once going from one side to the other but one direction was fine but the other switch caused XPEC errors. Is LD 30 in your midnight routine? That causes system clocks to switch as well as disabling unused TN's.

 

[telepath]

Try lcnt in LD60 to see if you have slips that would point to clock sync problems.

 

[StanleySteamer]

I think it's the carrier. Maybe their hardware is swapping CPUs (or some other redundant equipment).

DCH 7 IMSG SERVICE REF 00000000 CH 19 8 TOD 1:29:18
% STATUS: OUT OF SERVICE

That appears to be an incoming service message from the other end saying that channel 19 8 is out of service. You should only see that if you have D-channel monitoring turned on. Do you have D-channel monitoring on all the time? Seems like you would be seeing a lot more messages.

You might want to check whether you have Service messages turned on in LD 96
.STAT SERV
Are they enabled for DCH 7?

It seems to happen after midnight routines run and only on nights it switches to CPU 1

You could easily eliminate some of the doubt by taking 135 out of the DROL for a few days to see what happens if the CPU doesn't swap. Or change the TODR to another hour.

 

[hawks]

Sorry I haven’t answered I’ve been out the last couple of days.

KCFLHRC, 30 was running so I took it out for now

Telepath, if the loops come back by them selves the clock looks good but if they don’t recover then the clock shows slips.

Stanley, I went ahead and made sure D-Channel monitoring is off. I’m going to run it a couple of days to see if there are any changes, if not then I’ll take out 135 from OVLY and see what happens.
I'm also looking at the carrier, this is an Army base and the switch they're using at the far end is an SL-100.