Upgrading a resilient network. 1

[ondamother]

Hi all, I upgraded a resilient cluster recently and have some questions from that.

The site has 3 Mitel 3300's (MXe's and LX) We have upgraded them from ver 8.0.11.7_3 to Ver 4.0 sp2. The upgrade of Entman and OPSman went well as did the upgrade of the first two sites.

The issue started on the upgrade of the last controller, where on starting the upgrade the Phones tried to hone to there secondary controller which was expected. Unfortunately they sat on DHCP discovery and on the secondary controller I received errors stating the below.

ViPER
Description: ValidateProtocolVersions() -> Protocol version mismatch (required=1.2.9 actual=1.2.8)

Once the Primary Controller was upgraded. The IP phones did not hone back and still tried to get there load from there secondary controller. Which in turn caused issues, due to the amount of TFTP sessions happening at one time…

As a result it took hours for the IP phones to load.

I think this was our error where after each 3300 was upgraded we entered the {Load all IP devices} command once all the IP phones had honed back to there Primary Controllers. This more than likely became a problem once everything had being upgraded, the last site had no where to Failover too but a Controller of a later version...

Should this command be entered after all 3300's in a cluster, that are resilient to each other, have been upgraded?

Any advice much appreciated.

 

[Supernova99]

Just a couple of questions
Does the LX controller have 512MB RAM?

Have you upgraded the bootroom after the upgrades?

When upgrading resilient systems you should upgrade one at a time and wait until the phones return to their primary controller before load ipdevice 1 to 700

The phones should then just reload and not failover to the secondary controller once they are back up proceed to upgrade the next controller.





Share what you know - Learn what you don't

 

[ondamother]

Hey there, yes the LX has 512 meg of ram. we also entered the upgrade bootrom all command after each upgrade, we entered this after the Load all IP device command. Two of the sites needed a reboot because the E2T didn't pick up the new load. One site didn't have a separate E2T and was fine.

We did upgrade each system one at a time. And waited for the IP phones to return to thier Primary controller. Then issued the load IP device command.

Question for you, we issued the command load ipdevice 1 to n where n=the highest IPDevice number. We took the highest device number to be the IP devices that were Primary to that controller listed in the Multiline IP set assignment not secondary devices, as we thought the secondary devices would load from there own controllers. May-be we should have checked in the Multiline set assignment for the highest Device ID, and run the load IP device command too this number regardless of weather they were Primary devices or not?

Thanks for your help.

 

[Supernova99]

Hi
You should enter the maximum number your controller supports as you have already realised it could also have resilient devices.

Looks like your problems were centered around reboots and device reloads

I think it would have been wise to make sure the controller was back up and stable after bootrom upgrade etc. and then issue the load ipdevice

lesson learned I suppose

Share what you know - Learn what you don't

 

[ondamother]

Yep your right, next upgrade is to 4.1 nxt week.

The notes say to issue the bootrom upgrade after the ipdevice all cmd. But after the upgrade I will do the bootrom all first this time, wait for phones to come back (posibly reboot controller if bootrom all needs it) then load ip devices.

Thanks for all your help.