The documentation I'm finding for DHCP is not very systematic in its approach. So I'm seeking help on this list...
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:
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.
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.
--Donald Teed
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
On Wed, 3 Nov 2004, Jaco Kroon wrote:
If you find any really good documentation on DHCP, let me know.
Yes, I find that getting good documentation on the oldest Internet stuff - mainly the ones from ISC - is difficult. There is no O'Reilly book, which is surprising. The existing docs (man pages for dhcp, dhcpd.conf, and dhcp-options) cover the granular information, but other than finding existing examples, it is hard to see the DHCP stuff documented in a wholistic way.
For example, nothing I found indicated that class labels had to be unique, even though they appear in different subnet sections of the config. The examples at isolinux do not mention a class with match.
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.
I knew I could mention the full hexed IP, but I didn't realize how a partial match could be done. We have over 5000 clients, so just breaking it down to subnets getting custom boot menus is all we need.
One of the possible services we may put out is a self-serve udpcast session, so this thread is a relevant topic to the list.
Thanks for your suggestion on making hex IP default files. I think this may prove to be the simplest solution. At least we can implement it without testing and causing disruptions to the DHCP server.
--Donald Teed
-
Donald Teed -
Jaco Kroon