DHCPD issues.

~Stack~ i.am.stack at gmail.com
Fri Jan 13 04:35:42 UTC 2012

On 01/11/2012 10:09 PM, Glenn Satchell wrote:
> Looks like it's getting closer. Note that the dhcpd network and subnet
> descriptions must match what the real network setup looks like. If you
> have a single subnet then that's what dhcpd.conf must
> reflect.
> Normal practise is to put your host{} declarations outside the subnet.
> They are global in scope, meaning that defining them in the subnet does
> *not* bind them to tht subnet in any way. Trust us, for this setup it's
> just better to do it that way.
> Where you have multiple pools in a subnet, you must define a way for
> given clients to only be valid in the pool you want. The default is for
> them to be valid in all pools. You can do this with a class, a group of
> host statements, or leet them be randomly assigned.

Thank you for the explanation. It helps.

> You say you want dynamic DNS updates to be working, but I can't see and
> zone statements in there to define the setup of how dhcpd should toalk
> to named. In named.conf you need to allow dhcpd to update the zones,
> either using a key or allowing by IP address. For Ip address you should
> use localhost plus any addresses on interfaces. Check your bind logs to
> see if it's denying updates. There is an example config for named.conf
> and dhcpd.conf in the dhcpd.conf man page.

Yeah. I think I accidentally removed them in one of my 'overhauls' of a
broken config. I am working on adding the zone statements back in but I
am still trying to get a config that doesn't throw errors. This is much
further down the networking rabbit-hole then I normally venture and
obviously something I need to spend more time getting familiar with.

> Also in dhcpd.conf is an example using classes and subclasses for
> assigning membership of the class by hardware (MAC) address.
>      class "allocation-class-1" {
>        match pick-first-value (option dhcp-client-identifier, hardware);
>      }
>      class "allocation-class-2" {
>        match pick-first-value (option dhcp-client-identifier, hardware);
>      }
>      subclass "allocation-class-1" 1:8:0:2b:4c:39:ad;
>      subclass "allocation-class-2" 1:8:0:2b:a9:cc:e3;
>      subclass "allocation-class-1" 1:0:0:c4:aa:29:44;
> An example for PXE clients is:
> # PXE boots for x86 boxes
> class "PXE" {
>   match if substring(option vendor-class-identifier, 0, 9) = "PXEClient";
>   next-server tftp.example.com;
>   filename "pxegrub.I86PC.Solaris_10-1";
>   # 10 minutes should be long enough for PXE
>   max-lease-time 600;
>   # don't use multicast tftp option - may not need this
>   vendor-option-space PXE;
>   option PXE.mtftp-ip;
> }
> So now you could have a few different classes. Each of the ranges should
> be distinct, and not overlap with any others. Allowing one class denies
> members of all other classes.
>   pool {
>     range ...
>     allow members of "PXE";
>   }
>   pool {
>     range ...
>     allow members of "allocation-class-1";
>   }
>   pool {
>     range ...
>     allow members of "allocation-class-2";
>   }
>   # catchall for anything that didn't match a class
>   pool {
>     range ...
>   }

Thank you for the example. I have not gotten a chance to implement this
quite yet, but I am working on it.

Thank you everyone who has replied for your time and help. I do
appreciate it. I will post back when I get to my next sticking point.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20120112/8a4434a1/attachment.bin>

More information about the dhcp-users mailing list