Bug #23524


infoblox DHCP gives unreliable free ips.

Added by Sébastien Bernard about 6 years ago. Updated 6 months ago.

DHCP plugin
Fixed in Releases:
Found in Releases:


Related to the [[]] I'm opening also an issue with the infoblox dhcp plugin.
Ip reservation are now processed in the Proxy::DHCP::FreeIps::find_free_ip without calling the infoblox for a new ip address.
This seems a regression regarding the previous version.
At this time, the generic IP reservation is throwing random addresses without checking the infoblox.
This logic is not working correctly, giving address which are already used in the infoblox.
This makes the host creation fails at the dhcp reservation creation.
Maybe one could supersede the find_free_ip with an infoblox specialized version to avoid this problem.

Related issues 2 (1 open1 closed)

Related to Smart Proxy - Bug #27692: Make free IP ping optional ClosedLukas ZapletalActions
Related to Smart Proxy - Feature #27841: Make IP availability extensibleNewActions
Actions #1

Updated by Anonymous about 6 years ago

Maybe one could supersede the find_free_ip with an infoblox specialized version to avoid this problem.

We stopped using vendor implementations across the board, as they break workflows where multiple hosts are being created quickly/in parallel. Could you confirm that tcp and/or icmp pings work on the subnet in question -- this is required for this functionality to work.

Actions #2

Updated by Sébastien Bernard about 6 years ago

1- That's a huge regression. It used to work in 1.16, it's no longer the case.
2- Some of the subnets are not reachable by the foreman host.
3- I understand quite well the case you're trying to fix, however, the validation with tcp or icmp, is, IMHO, very unreliable.
For example, if the host is powered off, then its IP address is considered as available which is not correct.
In our case, creation of the DHCP entries creates its entries in the infoblox DNS, a good test would be : get the reverse lookup from the IP.

The smart_proxy is doing something like this :
take any random address in the range
check if it available (first tcp_connect on the 7 port, or ping the machine).
Sends back the selected adress if it's available.

The host gets the available IP from the smart proxy, tries to create a dhcp entry with the given address, then fails miserably because the address is already taken.

IMHO, the function to check should be selectable : ping, tcp (port configurable), dns, dhcp (check leases or static provisionning) or provider specific.

Actions #3

Updated by Adam Winberg about 6 years ago

Hm, relying on icmp to decide if an ip address is available for use or not seems like a bad idea to me. If a host is down, it wont work. If an ip address is reserved for future use, it wont work. If icmp is not allowed from the dhcp proxy to the subnet, it wont work. I just see a lot of cases where this would fail, which seriously disrupts automation pipelines. Any link to the discussion where this decision was made? I don't see anything in the release notes, and this seems like a pretty big change that would affect a lot of customers.

We use InfoBlox which has worked very smoothly in this aspect, by Foreman using infoblox api methods to get next available ip address. This change really puts me off updating to 1.17.

As stated by Sébastien, an option to choose to use provider specific method to allocate ip address would be welcome.

Actions #4

Updated by Lukas Zapletal almost 5 years ago

I like the idea of checking availibility of an IP address to be extendable function provided by individual implementations. We slightly touched this in #27692 but it is probably worth revisiting this.

Actions #5

Updated by Lukas Zapletal almost 5 years ago

  • Related to Bug #27692: Make free IP ping optional added
Actions #6

Updated by Lukas Zapletal almost 5 years ago

Actions #7

Updated by Ewoud Kohl van Wijngaarden 6 months ago

  • Category set to DHCP plugin

Also available in: Atom PDF