NIOS DDI DHCP migration

[#1]

Hello,

I am currently working with an HA (High Availability) pair of two Infoblox NIOS DDI appliances that support DHCP services, which I need to migrate. The new appliances are also Infoblox NIOS DDI (two appliances in an HA pair). As I’m relatively new to Infoblox products, I have a few questions about the migration process and would appreciate your assistance:

1-Configuration Replication:

To replicate the configuration from the existing appliances to the new ones, is it sufficient to export the current configuration and import it into the new appliances without any modifications, even though there are differences in the NIOS versions between the two sets of appliances? If modifications are required, does Infoblox provide any tools or resources to assist with this task?

2-Lease Database Transfer:

Is there a lease transfer feature in Infoblox NIOS DDI products that I can use to migrate the lease database from the existing appliances to the new ones, ensuring a seamless transition for the DHCP clients? If such a feature is not available, what method does Infoblox recommend for replicating the lease database during a migration?

3-Interface State During Migration:

During the migration, the old appliances will be isolated from the network and replaced with the new ones, but they will not be powered off (only the network interfaces will be down). I would like to know if the state of the interfaces could impact the DHCP service and the lease database. Specifically, does the NIOS appliance retain the contents of the lease database even when the service interface is down? Additionally, does the DHCP daemon remain active even when the interface is down? This information is crucial as I am relying on it in case a rollback is necessary.

Thank you for your support.

[#2]

I am currenty facing the same issue... does anyone have any clarification regarding this topic ?

[#3]

Assuming this is a hardware upgrade and that you are going from an "X5" appliance to "X6" (the following won't work for X0 > X6). Are these boxes part of a larger Grid or is it just two appliances in a HA Pair?

This is basically a hardware swap just like you would if one hardware appliance failed and you had to RMA it. Details here: https://community.infoblox.com/t5/trending-kb-articles/support-central-kb-2896-nios-hardware-replace...

This way there is no service interruption, no migration and no issues with lease table sync.

1) Make sure you can access your support account on https://support.infoblox.com

2) Make sure you know who your Solutions Architect is at Infoblox as they shoudl be able to give you a high level run through of the steps for your specific Grid. Support can get you the contact details of your aligned Solutions Architect. Ideally have a quick call with the Solutions Architect and have them run a highlevel check of the Grid to see if anything stands out as obviously problematic (e.g. unhealthy failover association status)

3) Upgrade the existing kit to NIOS 9.0.3+CHF2 and make sure the new kit is running that as well.

4) Make sure the correct licences are installed on the new kit and that you have set their LAN1 IP addresses to match the LAN1 IP addresses of the devices they are replacing.

5) Note down the IP of the Grid Manager (possibly the VIP of the DHCP pair if this is just a HA pair only) as well as the Grid Name and Shared Secret (reset if required).

6) Move the network cables from the old passive node to its replacement.

7) Run "set membership" on the cli of the new box and it should join the Grid (and reboot) and become the passive node.

8) Reboot the (old) active node to make it passive and verify DHCP is working fine on the (new) active node.

9) Repete by moving the cables from the old "now passive" node to the other new box and run "set membership"

You have now upgraded both your appliances to new hardware without service interruption.

[#4]

Hello,

Thank you for your response.

The existing appliances are currently configured as a standalone HA pair (not part of any GRID). I’ve been considering the approach you described—relying on HA for configuration replication—as it seems to be the simplest and most transparent method for this migration. However, I have some compatibility concerns.

The current appliances are Trinzic 820, which have reached end-of-life, while the new appliances are TE-906-HW-2AC (Trinzic X6 906) running NIOS 9.0.1 (reference link).

Given the end-of-life status of the existing appliances, they are likely running an older version of NIOS, and upgrading them to NIOS 9.0.x may not be feasible. Conversely, downgrading the new appliances to match the older NIOS version is unlikely to be an option.

I am therefore facing two key challenges:

1. The existing appliances run an older NIOS that cannot be upgraded (even if technically possible, but still not applicable in my case), while the new ones run a newer NIOS that likely cannot be downgraded (not sure about this, i would appreciate you confirmation if possible).
2. There is a significant difference in model and generation between the existing and new appliances.

Considering these constraints, is it still possible to achieve a seamless migration by relying on HA, as originally planned?

Thank you in advance for your assistance.

Best regards,

[#5 · Accepted solution]

That is a challange. TE-820 won't install anything past NIOS 8.6 and TE-926 won't install anything earlier than NIOS 9.0.

One way is to beg/borrow/get your hands on two TE-825 appliances, upgrade TE-820 to NIOS 8.6, swap out to the TE-825 running NIOS 8.6, upgrade to NIOS 9.0.3, swap out to TE-926 running NIOS 9.0.3. However, I'm guessing you don't have that option.

Another way is to export data in CSV and import the data to the TE-926 and then make them live. Possible but not elegant.

Do you have any capability/capacity to run virtual machines? If so, the method I would probably use is the following (its high level and doesn't cover scenario)

1) Upgrade TE-820 to 8.6

2) Deploy a NIOS lab VM running the same version of 8.6. You can download from the support portal and activate 60 day trial licence from the CLI of the VM (this is available to all customers). The version of code must match the TE-820. It doesn't have to be 8.6 so if you are running code that isn't too old (e.g 8.4) you may get away with just deploying a VM and not upgrading the TE-820. The important thing is that the TE-820 and the VM must be running the same version of code because otherwise you can't restore data into the lab.

3) Backup the TE-820 and restore the backup to the VM lab.

4) Upgrade the VM lab to 9.0.3

5) Backup the VM lab

6) Restore the VM lab backup to the TE-926 appliance running 9.0.3

7) Join the second TE-926 to the main TE-926

8) Move the cables over from the old pair of TE-820 appliances to the new pair of TE-926 appliances

I can't remember offhand if the backup file includes all the active lease data. I think it doesn't but I'm not 100% sure. Easy to check in the lab VM though.

The advantage of this is that you don't have to remember any extra settings like SNMP, logging, user access, etc in addition to DHCP scope import/export.

If you don't have the capability/capacity to deploy VM's, I'd suggest reaching out to your partner/Infoblox to discuss PS as they can do it for you.

With regards to your earlier question "does the NIOS appliance retain the contents of the lease database even when the service interface is down?", Yes. NIOS retains lease data even if the appliance interface is down.

[#6]

Thank you for all the insights you've provided—I really appreciate it.

The primary reason I wanted to perform a seamless upgrade using HA is to replicate the lease database. This would avoid the need to manually force all DHCP clients to release their DHCP leases and request new ones from the new appliances (which could otherwise lead to issues like IP address conflicts). This manual process can be cumbersome and time-consuming, especially in larger networks. Since the lease database can be exported, I wonder why there isn't a feature to import it directly?

Regarding the configuration adaptation, I’ll follow your suggestion to deploy a NIOS VM, adapt the configuration, and then upload it to the new appliances.

One last thing—if I’m not mistaken, NIOS backup files are encoded in a proprietary Infoblox format, meaning they can't be read with a standard text editor. I attempted to back up the configuration and open it with a text editor, but all I saw was gibberish text (the backup proccess didn't include any step regarding encryption). Am I correct in my assumption?

Once again, thank you for your assistance.

[#7]

The ".bak" file is a tar.gz file. Just remember that editing the file and then restoring that edited file to the appliances is not supported. If you try and something goes wrong, the solution will not be supported.

With regards to DHCP leases, remember, when the clients are half way through their lease, they will request a lease extension from the DHCP server. If you loose all your lease table, the DHCP server will likely just get a load of very specific requests for IP addresses and most devices will keep their existin IP's. It isn't fool proof - especially on wifi networks, etc.

[#8]

As you mentioned, DHCP clients will continue requesting lease renewals, but since the new appliances are freshly deployed, the lease database will be empty. As a result, the renewal requests will be dropped by the new appliances.

Once the leases expire, clients will be forced to go through the DORA process (Discover, Offer, Request, Acknowledge). At this stage, the new appliances will respond with a DHCP offer. The risk lies in the possibility that the appliance might offer an IP address that is already in use on the network (allocated by the old appliance), leading to an address conflict.

This is why I believe the best approach is to force clients to release their IP leases and request new ones from the newly deployed appliances. The process would proceed as follows for a given subnet/VLAN:

1. Force clients to release all DHCP leases.
2. Force clients to request new leases from the newly deployed appliances.

By following these steps for each VLAN/subnet, all DHCP clients will receive new IP addresses, and address collisions will be avoided.