Hi all,
Just so I'm belt and braces on this, I'm working up the dhcpd.conf and dnsmasq.conf files ready for Monday. I'll send these out so that you can all peruse, approve/check my working.
Thanks
Dave
OK. Here they are.
Please get me feedback as soon as possible. This is going to take time to do properly.
Thanks
Dave
On 7 Dec 2012, at 11:03, Dave Pigott dave.pigott@linaro.org wrote:
Hi all,
Just so I'm belt and braces on this, I'm working up the dhcpd.conf and dnsmasq.conf files ready for Monday. I'll send these out so that you can all peruse, approve/check my working.
Thanks
Dave
On 12/07/2012 09:26 AM, Dave Pigott wrote:
On 7 Dec 2012, at 11:03, Dave Pigott dave.pigott@linaro.org wrote:
Hi all,
Just so I'm belt and braces on this, I'm working up the dhcpd.conf and dnsmasq.conf files ready for Monday. I'll send these out so that you can all peruse, approve/check my working.
Why both dnsmasq.conf and dhcpd.conf? Is dhcpd.conf a backup plan in case dnsmasq.conf doesn't work for us?
My other question (likely me being dense). We have:
dhcp-range=192.168.2.0,192.168.255.254,255.255.0.0,10m dhcp-range=192.168.1.0,192.168.1.255,static,255.255.0.0
Does this mean this dhcp server will just hand out addresses on 192.168.2.x except for nodes specifically listed like:
dhcp-host=68:b5:99:be:54:8c,control,192.168.1.10
?
And if that assumption is right. I guess that then frees up enough of the 192.168.1.x that OpenStack's IP allocation will *just work*?
On 7 Dec 2012, at 16:53, Andy Doan andy.doan@linaro.org wrote:
On 12/07/2012 09:26 AM, Dave Pigott wrote:
On 7 Dec 2012, at 11:03, Dave Pigott dave.pigott@linaro.org wrote:
Hi all,
Just so I'm belt and braces on this, I'm working up the dhcpd.conf and dnsmasq.conf files ready for Monday. I'll send these out so that you can all peruse, approve/check my working.
Why both dnsmasq.conf and dhcpd.conf? Is dhcpd.conf a backup plan in case dnsmasq.conf doesn't work for us?
To save connectivity disruption time, dhcpd.conf is for control, so that I can switch all the nodes over to statically served IP addresses based on their MAC addresses before switching over to dnsmasq on gateway. Then, when I switch over go back round and restart networking on all nodes so they get refreshed with the /16 based config. I've fleshed out the BP to try to explain the steps.
My other question (likely me being dense). We have:
dhcp-range=192.168.2.0,192.168.255.254,255.255.0.0,10m dhcp-range=192.168.1.0,192.168.1.255,static,255.255.0.0
Does this mean this dhcp server will just hand out addresses on 192.168.2.x except for nodes specifically listed like:
dhcp-host=68:b5:99:be:54:8c,control,192.168.1.10
This is why I need feedback. :)
According to the documentation I've read, this means that 192.168.2...255.x will be dhcp served, and because of the "static" declaration in the second, this reserves that range for fixed addresses served based on MAC addresses. Which reminds me: I also need to add some steps to the BP for reconfiguring the cloud.
?
And if that assumption is right. I guess that then frees up enough of the 192.168.1.x that OpenStack's IP allocation will *just work*?
With the probable exception of the netmask as configured on the control node. And adding the 192.168.0.x IP pool.
Dave
Dave Pigott dave.pigott@linaro.org writes:
On 7 Dec 2012, at 16:53, Andy Doan andy.doan@linaro.org wrote:
On 12/07/2012 09:26 AM, Dave Pigott wrote:
On 7 Dec 2012, at 11:03, Dave Pigott dave.pigott@linaro.org wrote:
Hi all,
Just so I'm belt and braces on this, I'm working up the dhcpd.conf and dnsmasq.conf files ready for Monday. I'll send these out so that you can all peruse, approve/check my working.
Why both dnsmasq.conf and dhcpd.conf? Is dhcpd.conf a backup plan in case dnsmasq.conf doesn't work for us?
To save connectivity disruption time, dhcpd.conf is for control, so that I can switch all the nodes over to statically served IP addresses based on their MAC addresses before switching over to dnsmasq on gateway. Then, when I switch over go back round and restart networking on all nodes so they get refreshed with the /16 based config. I've fleshed out the BP to try to explain the steps.
So to be clear (to me): what you've done is you've collected all the addresses that have been allocated by DHCP to "fixed" hardware (servers, PDUs, routers and the like, but *not* test devices) and this new dhcpd.conf will ensure that these devices always get the IP address they have now for as long as dhcpd shall live? And then dnsmasq.conf is also set up so that these bits of hardware will get the same address when we start dnsmasq and kill dhcpd? So the net effect of these devices renewing their leave will be to widen their netmask but not change address?
This seems like a fine plan to me.
Hm... or is part of this plan also involving moving some devices from having IPs fixed by their networking configuration to having IPs fixed by the DHCP server configuration? That seems sensible enough too, I just like to have these things clear in my head.
My other question (likely me being dense). We have:
dhcp-range=192.168.2.0,192.168.255.254,255.255.0.0,10m dhcp-range=192.168.1.0,192.168.1.255,static,255.255.0.0
Does this mean this dhcp server will just hand out addresses on 192.168.2.x except for nodes specifically listed like:
dhcp-host=68:b5:99:be:54:8c,control,192.168.1.10
This is why I need feedback. :)
According to the documentation I've read, this means that 192.168.2...255.x will be dhcp served, and because of the "static" declaration in the second, this reserves that range for fixed addresses served based on MAC addresses.
This matches my reading of the docs too.
Which reminds me: I also need to add some steps to the BP for reconfiguring the cloud.
?
And if that assumption is right. I guess that then frees up enough of the 192.168.1.x that OpenStack's IP allocation will *just work*?
With the probable exception of the netmask as configured on the control node. And adding the 192.168.0.x IP pool.
Some more thoughts:
1) This work item at the end:
"Go round each node and restart networking (different for each node - pdu, serial, servers etc): TODO"
-- I don't really see the point if our DHCP lease time is 10 minutes. Why don't you just wait 10 minutes and then go around checking that the netmask has updated on them all?
2) I don't see anything on there about ensuring that there are no other DHCP servers running. I thought that last time I checked the main buffalo router was still running DHCP, but I may be wrong.
In other respects, the plan gets the mwhudson stamp of approval (tm).
Cheers, mwh
On 10 Dec 2012, at 02:56, Michael Hudson-Doyle michael.hudson@linaro.org wrote:
Dave Pigott dave.pigott@linaro.org writes:
On 7 Dec 2012, at 16:53, Andy Doan andy.doan@linaro.org wrote:
On 12/07/2012 09:26 AM, Dave Pigott wrote:
On 7 Dec 2012, at 11:03, Dave Pigott dave.pigott@linaro.org wrote:
Hi all,
Just so I'm belt and braces on this, I'm working up the dhcpd.conf and dnsmasq.conf files ready for Monday. I'll send these out so that you can all peruse, approve/check my working.
Why both dnsmasq.conf and dhcpd.conf? Is dhcpd.conf a backup plan in case dnsmasq.conf doesn't work for us?
To save connectivity disruption time, dhcpd.conf is for control, so that I can switch all the nodes over to statically served IP addresses based on their MAC addresses before switching over to dnsmasq on gateway. Then, when I switch over go back round and restart networking on all nodes so they get refreshed with the /16 based config. I've fleshed out the BP to try to explain the steps.
So to be clear (to me): what you've done is you've collected all the addresses that have been allocated by DHCP to "fixed" hardware (servers, PDUs, routers and the like, but *not* test devices) and this new dhcpd.conf will ensure that these devices always get the IP address they have now for as long as dhcpd shall live? And then dnsmasq.conf is also set up so that these bits of hardware will get the same address when we start dnsmasq and kill dhcpd? So the net effect of these devices renewing their leave will be to widen their netmask but not change address?
This seems like a fine plan to me.
Hm... or is part of this plan also involving moving some devices from having IPs fixed by their networking configuration to having IPs fixed by the DHCP server configuration? That seems sensible enough too, I just like to have these things clear in my head.
Essentially, yes. Only 3 units (the hack boxes and NI battery simulator are currently dhcp served fixed IP addresses. This is to enable us to switch over and from hereon in to always add IP addresses through dhcp, rather than static assignment. Just something we probably should have done a while ago, so now seems a good time to add it.
My other question (likely me being dense). We have:
dhcp-range=192.168.2.0,192.168.255.254,255.255.0.0,10m dhcp-range=192.168.1.0,192.168.1.255,static,255.255.0.0
Does this mean this dhcp server will just hand out addresses on 192.168.2.x except for nodes specifically listed like:
dhcp-host=68:b5:99:be:54:8c,control,192.168.1.10
This is why I need feedback. :)
According to the documentation I've read, this means that 192.168.2...255.x will be dhcp served, and because of the "static" declaration in the second, this reserves that range for fixed addresses served based on MAC addresses.
This matches my reading of the docs too.
Good. That gives me +1 confidence that this will work. :)
Which reminds me: I also need to add some steps to the BP for reconfiguring the cloud.
?
And if that assumption is right. I guess that then frees up enough of the 192.168.1.x that OpenStack's IP allocation will *just work*?
With the probable exception of the netmask as configured on the control node. And adding the 192.168.0.x IP pool.
Some more thoughts:
- This work item at the end:
"Go round each node and restart networking (different for each node - pdu, serial, servers etc): TODO"
-- I don't really see the point if our DHCP lease time is 10 minutes. Why don't you just wait 10 minutes and then go around checking that the netmask has updated on them all?
I thought about this, and what I wasn't sure about was whether fixed ip addresses renewed as well as floating. I suppose it's probably a case of "suck it and see". :)
- I don't see anything on there about ensuring that there are no other
DHCP servers running. I thought that last time I checked the main buffalo router was still running DHCP, but I may be wrong.
No, we disabled DHCP on the router a while back, or at least I'm 99% sure Andy did. I'll double check.
In other respects, the plan gets the mwhudson stamp of approval (™)
Excellent. Thanks. I feel a lot more confident now.
One "D'oh" moment. I forgot to put the boards offline yesterday. Should have set a calendar event. Am doing so now.
Thanks
Dave
linaro-validation@lists.linaro.org
-
Andy Doan -
Dave Pigott -
Michael Hudson-Doyle