Bug #6916
closedMS DHCP Timeout
Description
Hi,
just updated to Foreman 1.5.2 today as I already had issues with 1.5.1 deploying hosts. Sometimes that host creation took ages to complete. I guess this is because our MS DHCP has more than 3 subnets and already many reservations. On our DMZ MS DHCP this works fine. Just one subnet and not so many reservations.
Now I get this error with 1.5.2:
Create DHCP Settings for gedasvl10.a.space.corp task failed with the following error: ERF12-6899 [ProxyAPI::ProxyException]: Unable to set DHCP entry ([RestClient::RequestTimeout]: Request Timeout) for proxy https://gedasvw16.a.space.corp:8443/dhcp
To me it looks like the whole MS DHCP smart-proxy thing would need to be changed to get around this error as it only happens when there are many subnets and reservations on the MS DHCP.
Updated by Bryan Seitz almost 10 years ago
Oliver Weinmann wrote:
Hi,
just updated to Foreman 1.5.2 today as I already had issues with 1.5.1 deploying hosts. Sometimes that host creation took ages to complete. I guess this is because our MS DHCP has more than 3 subnets and already many reservations. On our DMZ MS DHCP this works fine. Just one subnet and not so many reservations.
Now I get this error with 1.5.2:
Create DHCP Settings for gedasvl10.a.space.corp task failed with the following error: ERF12-6899 [ProxyAPI::ProxyException]: Unable to set DHCP entry ([RestClient::RequestTimeout]: Request Timeout) for proxy https://gedasvw16.a.space.corp:8443/dhcp
To me it looks like the whole MS DHCP smart-proxy thing would need to be changed to get around this error as it only happens when there are many subnets and reservations on the MS DHCP.
We too are seeing this issue and it is impacting our deployment. Should we downgrade to 1.5.1 ?
Updated by Ruslan Kiianchuk almost 10 years ago
Bump. The same issue.
It seems like the proxy readds all subnets upon addition of single server to Foreman, causing the proxy to timeout eventually, when number of hosts grows.
Also impacting our deployments, so if it's not fixable, we'll be forced to switch to Cobbler.
Updated by Ohad Levy almost 10 years ago
did you consider limiting the subnets you are interested in, this should reduce greatly the amount of time.
Updated by Ohad Levy almost 10 years ago
Ruslan Kiianchuk wrote:
Also impacting our deployments, so if it's not fixable, we'll be forced to switch to Cobbler.
How would that solve the issue? after all, cobbler does not manage windows dhcp, if you can switch to a non windows dhcp server then this issue is also not relevant afaiu?
Updated by Oliver Weinmann almost 10 years ago
Ohad Levy wrote:
did you consider limiting the subnets you are interested in, this should reduce greatly the amount of time.
I limited it to only two subnets. But the subnets are quite big /22. The proxy has become totally unusable for us. A fix would be really appreciated. We can't switch to a Linux DHCP. :( I'm happy to help solving the problem. But my ruby programming skills are absolutely zero. I can test and report if that is ok. I can sign in on IRC...
Updated by Oliver Weinmann almost 10 years ago
Ok, it creates the dhcp reservation when it runs into a timeout. Clicking on submit again will fail with another error. I then deleted the DHCP reservation on the windows server and submitted it again and after approx 2-3 minutes it works... sometimes. So yes it is ridicously slow and you have to be lucky that it works...
Updated by Bryan Seitz almost 10 years ago
We see this with ISC DHCP as well, as it iterates over every single subnet/server when you are only adding a single server. This is really bad at any sort of scale :(
Updated by Oliver Weinmann almost 10 years ago
Another user has a similar issue:
http://projects.theforeman.org/issues/7766
He might have a solution for it... Currently the smart-proxy is absolutely unusable for us. :(
Updated by Dominic Cleal almost 10 years ago
- Related to Bug #7766: ms_native dhcp smart proxy code scales poorly added
Updated by Stefan Berggren over 9 years ago
I am having this issue as well, with isc-dhcp-server. Getting timeout while creating reservation. Worked well with a couple of subnets in dhcp.yml, but now with four subnets, one of them is a /21, the proxy is not working. Is there a way to change the timeout setting in order to work around the problem?
Updated by Stefan Berggren over 9 years ago
This also applies to 1.8. I have changed the timeout setting and now the provisioning works 100% but the dhcp thing still takes about 100 sec to complete.
Updated by Oliver Weinmann about 9 years ago
Hi,
since upgrading to 1.8.1 and then 1.8.2 the whole windows smart proxy has become totally unusable. I only manage one /22 subnet and CPU usage stays at 100%. I guess the whole windows smart-proxy needs to be re-written. Netsh commands are not really fast. Maybe some Powershell CMDlets can help?
Updated by The Foreman Bot about 9 years ago
- Status changed from New to Ready For Testing
- Pull request https://github.com/theforeman/smart-proxy/pull/306 added
- Pull request deleted (
)
Updated by Anonymous almost 9 years ago
- Related to Refactor #11866: Replace linear searches in various lookups in DHCP module with constant-time lookups. added
Updated by Anonymous almost 9 years ago
- Status changed from Ready For Testing to New
- Pull request added
- Pull request deleted (
https://github.com/theforeman/smart-proxy/pull/306)
Updated by Anonymous over 7 years ago
- Status changed from New to Resolved
Ms dhcp provider has been re-written and the issue should be resolved now. I'm going to close the ticket, please re-open it if you continue to experience the problem with the new version of the provider.