Resiliency via MBG

[johnp]

One other thing, where is that found in version 9? I don't have access to one and was looking at the install blade but didn't see where it was. I also would assume that some translations may need to be added

[johnp]

Did some onsite testing and with the override everything behaved as expected(desired). I was able to fail over and back between MBG's, and the best thing was it didn't try a reconnect every 30 seconds, only when path was restored.

Thanks again for the help.

[johnp]

Dilkie,

I did some more testing and while my 5340 has been rock solid. I have issues with 5320e and 5330e. From the logs, they say ping before redirect is enabled, attempt the ping, then Ping request timer expired, carrying on with redirect-force

[dilkie]

are they running upgraded firmware? check the tug.log, the f/w boot and main version are printed there for each connected set.

[johnp]

I have used 6.3.0.11 be currently have them using 6.3.0.14. Saw some ping lockups at 6.3.0.11. I can revert or use the 6.3.0.12 loads from MBG 9. It have the versions from their MCD running now.

[dilkie]

not sure man, the fix should be in all the .11 versions, at least that I was told. I've asked again.

[johnp]

I'll revert back. From what I gather from my testing is that the ping request time expired log entry is due to the set not responding in a timely fashion as to whether it's ping was a success or failure;

I would further add that this set did run fairly well when connected at my office. I currently have it connected at my house

[dilkie]

that is correct... the set is asked to ping the other mbg's ip address with an 800ms timeout and if mbg doesn't get a response back in a reasonable time, we give the set 10 seconds to respond, then the set is "stuck"... like I said, it's a bug that was fixed.. enabling the other option "reboot_stuck_set" does clear the problem, at the cost of forcing the set through a reboot cycle.

note that mbg doesn't ask a set to ping/or redirect if it's "busy"... ie. the set has to not be in a call, or been in a call, had a digit, handset or tone (ringing) operation performed in the past 15 seconds.

[johnp]

Just an update, I have a static address on the 5320e instead of my home dhcp and it hasn't toggled. Ther may be somthing weird with the address it was given and my home equipment. I added a third 5330e to the mix to monitor.

It looks like it is operating noe closer to what I saw in the office. I do have the reboot option running. Strange thing is my 5340 is handled by dhcp and hasn't had any issue.

[johnp]

My 3 phones seem to be running fine. I'm going to use a different dhcp server and test further. Is there likely to be any adverse effect if I choose to use the firmware from the MCD? I have quite a few phones to pin and get there mac address in the MiCollab. I don't relly want to have to upgrade them and then downgrade if not necessary.

[dilkie]

whatever works...

[johnp]

Just want to say thanks again. Looks like this is going to work. I have the MiCollab border gateway set in the default zone, as most remotes will have this as first choice. Created 2 additional zones one for each back up location. Default is backed up but location 1, and location 1 is backed up by location 2. Location 2 is backed up by location 1.

I see all 3 as availble icp sources with loction 1 as my current, default as the second and location 2 as third. Being a teleworker, this is what I would expect. An internal set should be default, L1 then L2. haven't verified this though.