Infoblox ZTP workflow and Outbound Notification question

Olkama

Hi,

we currently have a self-built ZTP (Zero Touch Provisioning) solution based on Ansible, an ISC DHCP server running on Ubuntu, and another product as our source of truth and device inventory.

The ZTP process heavily depends on a Python script that was previously executed during the DHCP on commit phase directly on the DHCP server. This script uses the vendor-class-identifier to determine device type, pushes initial configurations, adds the device into inventory, and triggers further automation.

Due to reasons outside my control, we are now migrating to Infoblox, and I need to redesign this entire workflow on top of it.

Challenge

The biggest issue is the on commit logic. As far as I can tell, Infoblox does not support running local scripts in the same way as ISC DHCP, and I’m struggling to find a clean equivalent.

Current approach (Outbound Notification)

I’m currently trying to replicate the workflow using Outbound Notifications, with a flow like this:

1. Device connects to the network
2. Device requests a DHCP lease
3. Lease allocation triggers an Outbound Notification
4. Infoblox sends relevant lease data to an external ZTP service
   • vendor-class-identifier
   • leased IP address
   • MAC address
   • hostname
   • device UID
5. A Flask app on the ZTP server receives the data
6. Based on that, it triggers a Python script that runs Ansible playbooks

Problem with this approach

I’ve tried to configure the Outbound Notification action template, but I’m stuck with the parameters:

• What variables should I use to reference the DHCP lease data?
• Specifically, how do I access:
  • vendor-class-identifier
  • leased IP
  • hardware/MAC address
  • hostname
  • client UID

I haven’t found clear documentation or examples showing how to reference these fields in the template.

Current automation logic (context)

The Python script does roughly the following:

• Queries API of the current device inventory to check if the IP is already in use
• Creates the device in there with a temporary role provisioning
• At this point, we would normally manually change the device role (e.g., provision_role)
• Then trigger a provisioning playbook via AWX, which:
  • Reads the device role
  • Runs the correct playbook accordingly
• The provisioning playbook:
  • Adds the device to Infoblox (IPAM + DNS)
  • Updates device inventory (final state, correct networks, etc.)
  • Removes the DHCP lease

Questions

• Is this Outbound Notification–based approach the right way to replicate on commit functionality in Infoblox?
• How can I correctly reference DHCP lease attributes (vendor-class-identifier, IP, MAC, hostname, UID) in the action template?
• Are there more native or recommended approaches in Infoblox for implementing ZTP-style workflows?
• Has anyone migrated a similar ISC DHCP "on commit"–based process to Infoblox?

I’m also very open to alternative designs if there’s a better way to achieve this than using Outbound Notifications and an external Ansible/ZTP server.

Thanks in advance for any advice or examples!

williamjohn5987son

Have you evaluated whether DHCP lease events are still the best trigger for ZTP, or whether Infoblox's ecosystem offers a more authoritative event source (such as IPAM object creation, extensible attributes, or workflow integrations) that could reduce dependency on lease-state timing?

Olkama

Hi, williamjohn5987son.

Thanks, that's a very good point.

We did evaluate other event sources, but our main requirement is to trigger provisioning as soon as previously unknown device appears on the network.

In our current implementation, the DHCP lease event is effectively the first authoritative indication that a new device has connected. At that stage we can identify the platform from the vendor-class-identifier, register the device in our inventory system, assign a temporary provisioning role, and launch the appropriate automation workflow.

As far as I know, IPAM object creation would happen later in the process and is actually one of the outcomes of provisioning rather than the trigger for it.

Similarly, extensible attributes could potentially be used to drive later workflow stages, but they would still require an initial event to identify and classify the device before those attributes exist.

From our perspective the DHCP lease event is therefore less about IP address allocation and more about device discovery.

That said, if there are Infoblox-native approaches for identifying newly connected devices and launching automation workflows before the device exists in IPAM, I'd be very interested in learning more about them.

nic w

Agree DHCP lease is best. Some of my customers kick off a SOAR or other automation tool directly to handle a more complex use case. Eg a specific playbook for new devices that hooks into their ZTP service, MDM, XDR, etc and does all that enrichment.

A lot of the NAC-like, EDR, and vuln-scanning ecosystem templates reference what you're looking for. If you head over to ecosystem.infoblox.com and look at Rapid7, for example, or Tenable you'll see the examples regarding how to capture DHCP info to forward along.