Force option 43 dhcp change

[gbalbach]

Hi folks, wondering if any of you have run into this...

We have the MiVoice hosted solution. We also have an MPLS network with a private tunnel to the Mitel MiVoice data center.

We have our Mitel phones (mostly 5360's) setup to pull DHCP from our routers, works great for normal use.

We normally have the option 43 setting set to: id:ipphone.mitel.com;sw_tftp=172.16.20.2;call_srv=172.16.20.2;vlan=20;l2p=6v6s6;dscp46v46s26
and the phones boot up fine with that, BUT if the private tunnel at the 172.16.20.2 address is unavailable (outage for example) then we change the option 43 to be:

id:ipphone.mitel.com;sw_tftp=64.28.118.9;call_srv=64.28.118.9;vlan=20;l2p=6v6s6;dscp46v46s26

then reboot the phones - this then points them to the public Mitel phone system at 64.28.118.9 and all is great.

The problem is when we want to change back to the 172.16.20.2 settings - we change them in DHCP server and reboot the phones but the phones continue to use the 64.28.118.9 public settings. The only way we have found that we can flip them back to the 172.x server is to physically go around to each phone and go into the phone settings and default the IPV4 settings then let the phone reboot then it will pull the 172.x settings again.

Anyone else run into this? I'm looking for a way to flip them back without me having to physically go around and touch each phone...?

[gbalbach]

So I just discovered that once the phone boots up talking to the public IP (at 64.28.118.9) it sets some of the IP addresses in the PERSIST DATA values when I view network settings on the phone - anyone know of a way to change that via DHCP or some other protocol?

[gbalbach]

Well I found out why it is happening and will post that here in case anyone else needs to know but I am now looking for a way, remotely, to reset a 5360's ipv4 network settings back to factory default (not all phone settings, just ipv4 like how you can when you go through the settings on the physical phone and get into ipv4 and press 0 to default it, then it reboots).

The reason it is ignoring the dhcp option 43 server settings is because the public Mitel MBG is setting a Persistent Resiliency List. Here is the tech article that explains it:

When a MiNET 53xx device powers on or reboots, it will attempt to reach a TFTP server to obtain new firmware. Once connected to a TFTP server, the set downloads and installs new software if required. When the download attempt is complete, the set then attempts to connect to an MBG, searching for nodes as follows:   

Resiliency List—If the device has previously connected to MBG and received the Resiliency List (programmed using this procedure), it will search the list from top to bottom to obtain a connection. 
Teleworker IP—If the device has a Teleworker IP address (programmed by pressing 7 key on bootup on most phones), it will use it to obtain a connection.
DHCP—If all other connection methods fail, the device will attempt to obtain a connection from DHCP.

The Resiliency List of MiNET fallback addresses is optional. If you do not configure it, the devices will use the values they have been programmed with or obtain an address from DHCP.
The Resiliency List supports the following features:
Up to four node addresses can be configured.
Node addresses can be in IPv4 or IPv6 format.
Node addresses can be for any MBG, not just local MBGs. However, in a clustered environment, the addresses should be for nodes in the device's own cluster zone.

Devices search the list from top to bottom (first to fourth node) until a connection is made.   
This feature is useful if you need to configure failover addresses. For example, if your enterprise is switching service providers, program a Resiliency List that contains MBG's current IP address plus the one that you will be using with the new provider. Then reset the devices in order to have them download these values. When the switchover to the new service provider occurs, the devices will attempt to connect to the original address and fail, and then try to connect to the new address and succeed. After completing this process, you can remove the original address from the Resiliency List.

[johnp]

Not knowing how everything is setup at your location but it may possible to point the phones to the inside address of the MBG and have the ping before redirect setup.

I have a customer where all remote users are set up this way and their sets use the MBG list as failover to external ip address. In fact, mine is set to fail to 2 external MBG addresses. Dilkie provided some knowledge on this ping thing, but it's now a setting in the current MBG.

[ralph]

Not knowing how everything is setup at your location but it may possible to point the phones to the inside address of the MBG and have the ping before redirect setup.

I have a customer where all remote users are set up this way and their sets use the MBG list as failover to external ip address. In fact, mine is set to fail to 2 external MBG addresses. Dilkie provided some knowledge on this ping thing, but it's now a setting in the current MBG.

This sounds pretty interesting.
Any chance we can go more in depth on this?
I'm wondering if it's possible to point a phone over a MPLS Circ and then to an MBG on MPLS failure.

Ralph

[johnp]

Ralph,

This site is using MPLS as it's primary connectivity with backup vpn tunnels. They have a 2 MAS and 2 MBG's, a vMCD, MXe and CX. The primary location Has MAS, MBG, MXe  and vMCD. Users are on vMCD with failover to MXe. Dialtone come via PRI into MXe with failver to CX at secondary site. They secondary's MAS provides some failover AA behavior.

The primary MAS, and both MBG's are in a cluster with each being in it's own zone, i.e local MAS LAN, backup 1, backup2. backup 1 is set to fail to 2, and I think backup 2 is failing to 1. Remote users DHCP sends them it the inside address of the MAS which gives the sets the failover info. I think I set all these teleworkers as LAN with ping before redirect and each also is resilient to both MCD controllers. I know that having the MAS and both MBG's isn't officially supported but appears to work. On other thing I did that isn't supported was to make sure all had the same firmware tftp version. Nothing worse that having it fail and then have to update firmware.

Let me know if this makes sense.