DCH054 during DROL's 1

[phonz1]

I have a few PBX's, from 11's to 61's and every night right after midnights, we get a DCH054. no errors are seen in the counters. This exists in a RLS4.0, 4.5 and a 5.0 and I did ref MPLR21321, but that sounds kind of vague.... Any takers??

 

[SpelingChampeon]

Usually, what I would do on a span acting 'odd', but running, I check the counters, and reset. If the counters are good, I might shut the span down, and reseat the card, making sure I FDL either the TMDI or the PRI card. If this is a P2P, you may have to have someone on the other side (remotely?). Also verify your ADAN programming.

 

[phonz1]

that's all been done..... these are all over the country as well... thanks!

 

[SpelingChampeon]

Are you getting this on all of your spans, or ?

Where are you referencing your clock from?

Is LD 30 in your midnights on the 61?

 

[GHTROUT]

When you do a LD 60 STAT, does your ATLP = 0 ? If it's not showing zero, the DCH is released and reestablished any night all channels are idle during the MIDN. The following example shows ATLP is off - intrusive testing is off.

[tt]
PRI TRK LOOP 71 ATLP 0
SLFT OK
TRSH CNT:
BPV -000
SLFT OK
SLIPR -000
CRC -000
LOSFA -000
OS_BPV -000
OS_LOSFA-000
OS_YEL -000
[/tt]

Might be a worth a look to see if somehow that feature was turned on. Easy to set to off:

LD 60
.ATLP 0

[©] GHTROUT.com [⇔] A Variety of Free Resources for Nortel Meridian/CS1000 System Administrators

 

[phonz1]

Gene, thanks... I'll try that!

Speling, these are all LD circuits, clocking on the local pri's and 30 is in mids!

 

[phonz1]

Gene,

Auto test says disabled and the pri loop lcnt shows:

PRI LOOP 3
BPV
SLIPR
SLIPD
etc.....

Now, I only have this on the 4.0 and upwards releases

 

[SpelingChampeon]

Having the same errors from different switches, on different releases of software, with different patches sure does make it harder to figure out. I dont have access to the Nortel site to check product bulletins... so I'm pretty much at a loss at the moment....

 

[phonz1]

I do and I've been there already, nothing solid enough though! And with only on the 4.0 and up machines, I'd think it's a patch!

Thanks!

 

[StanleySteamer]

Are your PRIs all from the the same service provider? Maybe Bell Canada?
I get DCH054 once a week on my one (and only) Bell PRI. I put it down to some maintenance routine running on the DMS. Always happens in the wee hours so I don't consider it a problem.

 

[phonz1]

yes they are Stanley and we had them look at them, they came back with something about data spooling in the PBX, I know what you're thinking... They couldn't back that statement up though!

 

[StanleySteamer]

Really? Bell Canada?

When they talk about "data spooling in the PBX" they are likely be referring to the "MSG LOG INDICATION" messages that appear whenever any of the DCH messages (like SETUP, CONNECT, RELEASE, etc.) reach 65535 and then start back at zero - spooling. Those are unrelated to the DCH054 message.

 

[phonz1]

Stanley..... We don't have any dch messaging turned on, but good point. There (like I said) was a patch for 4.0 and 4.5, so I know there is an issue, and this just came up within the last 6 months on existing PRI's

 

[StanleySteamer]

I wasn't referring to DCH message monitoring. I meant the DCH messaging that the DCH just does. You will get periodic messages on your tty when the counters max out and then start back at 0. But that is irrelevent to the issue anyway. I was only suggesting that the Bell person you talked to may have been referring to that as an explanation to your question.

The patch MPLR21321 you mention is for a problem when using ISDN network time sychronization where the DCH is going up and down every few minutes. The DCH054 message in that case is simply a bi-product of the DCH re-establishing and that is why it appears in the patch description.

The problem (if it can be called that)is a DCH054 without any other symptoms or messages. I get it on the one Bell Canada PRI but not on any of the other 10 PRI's from various other providers.

So I don't think there is a "fix" unless you can get the right DMS person from Bell on the line that understands what you're talking about and wants to help. Even then, there may be some good reason for letting the DMS do whatever it's doing.

 

[phonz1]

Stanley, good answer and kind of what I was thinking.... I do have multiple circuits to each location and only the Verizon LD circuit ever has this issue, the others are all fine.... That's why I think it's on the telco side, but as usual, they can find nothing wrong!!