Project

General

Profile

Actions

Bug #6916

closed

MS DHCP Timeout

Added by Oliver Weinmann over 9 years ago. Updated over 7 years ago.

Status:
Resolved
Priority:
High
Assignee:
-
Category:
DHCP
Target version:
-
Difficulty:
Triaged:
Fixed in Releases:
Found in Releases:

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.


Related issues 2 (0 open2 closed)

Related to Smart Proxy - Bug #7766: ms_native dhcp smart proxy code scales poorlyClosed10/01/2014Actions
Related to Smart Proxy - Refactor #11866: Replace linear searches in various lookups in DHCP module with constant-time lookups.Closed09/17/2015Actions
Actions #1

Updated by Bryan Seitz over 9 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 ?

Actions #2

Updated by Ruslan Kiianchuk over 9 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.

Actions #3

Updated by Ohad Levy over 9 years ago

did you consider limiting the subnets you are interested in, this should reduce greatly the amount of time.

Actions #4

Updated by Ohad Levy over 9 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?

Actions #5

Updated by Oliver Weinmann over 9 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...

Actions #6

Updated by Oliver Weinmann over 9 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...

Actions #7

Updated by Bryan Seitz over 9 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 :(

Actions #8

Updated by Oliver Weinmann over 9 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. :(

Actions #9

Updated by Dominic Cleal over 9 years ago

  • Related to Bug #7766: ms_native dhcp smart proxy code scales poorly added
Actions #10

Updated by Stefan Berggren almost 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?

Actions #11

Updated by Stefan Berggren almost 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.

Actions #12

Updated by Dominic Cleal almost 9 years ago

  • Category set to DHCP
Actions #13

Updated by Oliver Weinmann almost 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?

Actions #14

Updated by The Foreman Bot over 8 years ago

  • Status changed from New to Ready For Testing
  • Pull request https://github.com/theforeman/smart-proxy/pull/306 added
  • Pull request deleted ()
Actions #15

Updated by Anonymous over 8 years ago

  • Related to Refactor #11866: Replace linear searches in various lookups in DHCP module with constant-time lookups. added
Actions #16

Updated by Anonymous over 8 years ago

  • Status changed from Ready For Testing to New
  • Pull request added
  • Pull request deleted (https://github.com/theforeman/smart-proxy/pull/306)
Actions #17

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.

Actions

Also available in: Atom PDF