CS1000E HA issues with PRI when CS goes down

[BellWest]

Have and issue with a CS1000E HA 5.0.

Here is the situation. Call Server 0 is in building A and Call Server 1 in building B.

The ISDN setup it two physical T1 as one PRI with a primary D and backup D.
The T1 for building A is in l s c = 4 0 3 Loop 78 DCH 14 Primary with its own primary clock controller
The T1 for building B is in l s c = 4 1 3 Loop 87 DCH 16 Backup with its own primary clock controller

We were doing fail over testing and when we pulled the active CS current calls stay active, can not make new calls. The B Channels look ok but eventually LCKO. I can resolve the issue by DIS DCH for the Primary.

Not matter what I do
-pull active CS
-shut down MG1000

I have to do a DIS DCH and ENL DCH to go back to normal operation.

My question is can this be resolved or do I need to have the PRI split in to two with is own D?

Thanks

 

[johnpoole]

split it.. when you enl d, enl dch x fdl.. it is in auto recovery.. BUT since the b's didn't drop, the d just goes stupid..

the calls stay up because the d is only used for setup and teardown.. no new calls and each hangup gives you another msby channel.. if the far end went red/yellow/green it would recover..

john poole
bellsouth business
columbia,sc

 

[BellWest]

Hey John, will we not have the same issue even if they are split? I mean the Call Server is down and when the other core comes up will the D channels still not act stupid?

 

[curtismo]

Hmmm, I pretty much have the same setup you have, but with CS1000E HA on 6.0, my difference is that I have Primary D-channels on both of my T1 PRI spans.

johnpoole may have an idea; if you have TMDI cards, have you done a FDL after you set up the PRI programming to set the configuration into the TMDI card and get the latest firmware downloaded to the card.

I do wonder why pulling the active CS causing the DCH not to allow new calls after the backup CS takes over. I would set up a PC to capture the TTY 0 output on the backup call server and see if the DCH recovers after the CS swap.

 

[BellWest]

I did do a FDL and still the same result.Before pulling the active CS I connected to the standby and the DCH does establish. ?????????

 

[curtismo]

Probably the next thing is turn on DCH monitoring and capture that during the changeover. Could be possible the system is getting confused about which B-channel is on which card.

 

[BellWest]

I know we did some audit testing before this system went in to production back in december 2008. I don't remember us having these issues back then. I will go back and check the results.

 

[Reusser]

5.0 been around a while - When was your MGC firmware updated last - might want to check.

There was some MGC formware for a cutover issue simular to what you have also probably new TMDI firmware.

 

[BellWest]

Thanks Reusser

The MGC firmwire is up to date.

Also to my last comment about the audit conducted, the testing did not mention anything about the PRIs having any issues, therefore I beleive that it worked before.

 

[dmunger]

I am nor sure to understand it all... The test scenario is key here. A partial disfunction such as pulling out the ELAN port or the HSP port is not the best thing here.

Shutting down the MG1000E which might contain the primary DCH might call for another response.

However, have you check if auto recovery is setup on the DCH (LD 96) ? DCH must be turned down to setit up to AUTO.

Since this is an HA system, All calls shall remain active and the secondary should take over within 1 second. Meanwhile both DCH primary and secondary should remain active.

In the history file, you might find messages indicating why the DCH goes into LCKO mode.

There might also be something wrong set on the telco side. Why not try a manual disblement of the primary DCH or disconnect the T1 cable on the TMDI (be sure to warn them first !)