Project

General

Profile

Bug #23524

infoblox DHCP gives unreliable free ips.

Added by Sébastien Bernard 3 months ago. Updated 3 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Difficulty:
Triaged:
No
Bugzilla link:
Pull request:
Team Backlog:
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.

History

#1 Updated by Dmitri Dolguikh 3 months 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 3 months 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 3 months 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.

Also available in: Atom PDF