Project

General

Profile

Bug #23524

infoblox DHCP gives unreliable free ips.

Added by Sébastien Bernard over 2 years ago. Updated about 1 year ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Difficulty:
Triaged:
No
Bugzilla link:
Pull request:
Fixed in Releases:
Found in Releases:

Description

Related to the [[http://projects.theforeman.org/issues/23523]] 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

Related to Smart Proxy - Bug #27692: Make free IP ping optional Closed
Related to Smart Proxy - Feature #27841: Make IP availability extensibleNew

History

#1 Updated by Dmitri Dolguikh over 2 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.

#2 Updated by Sébastien Bernard over 2 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.

#3 Updated by Adam Winberg over 2 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.

#4 Updated by Lukas Zapletal about 1 year 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.

#5 Updated by Lukas Zapletal about 1 year ago

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

#6 Updated by Lukas Zapletal about 1 year ago

Also available in: Atom PDF