Donald Teed wrote:
The documentation I'm finding for DHCP is not very systematic in its approach. So I'm seeking help on this list...
If you find any really good documentation on DHCP, let me know.
I'd like to have DHCP point to different PXE boot menus depending on what subnet the client is coming from. The config I've tried already is something like this:
I note you are using pxelinux. pxelinux already has this functionality built in, thus no need to /pxe1/pxelinux.0 and /pxe2/pxelinux.0, if I recall you have a config directory with default in it to provide a default config, but it tries different names first, starting the the complete ip address written out in hex, for example C0A80101 for 192.168.1.1, and then it starts chopping off digits at the end until it is left with the empty string (at which point it loads default) untill it finds a config. Just read the docs again to make sure I'm not talking bollocks here.
subnet 192.168.1.0 netmask 255.255.255.0 { range dynamic-bootp 192.168.1.2 192.168.1.3; next-server 192.168.1.1; class "pxe1" { match if substring(option vendor-class-identifier, 0, 9) = "PXEClient"; filename "/pxe1/pxelinux.0"; # Uncomment } }
subnet 192.168.2.0 netmask 255.255.255.0 { range dynamic-bootp 192.168.2.3 192.168.2.4; next-server 192.168.1.1; class "pxe2" { match if substring(option vendor-class-identifier, 0, 9) = "PXEClient"; filename "/pxe2/pxelinux.0"; # Uncomment } }
This isn't exactly the configuration on our live DHCP server, but it should artificially reproduce the problem I want to handle, which is making two subnets refer to the TFTP server.
Hmm, same physical network? If so, perhaps the shared-network directive might help. If not, are you using two interfaces for dhcp? Otherwise, how does dhcpd know on which physical network a host is located?
shared-network network_name { subnet ... { } subnet ... { } }
What I see with this configuration is that one connection to TFTP goes ahead and boots OK, and then I get errors that there are "no free leases" available. In this testing with this configuration, I'm never seeing a client assigned 192.168.2.*
It behaves as if the match is made and then it cannot move onto the next subnet block where there is also a good match.
Jaco