DHCP setup to separate PXE and normal clients

From ezUnix
Revision as of 15:34, 19 February 2012 by YazzY (talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
                                    pdf_icon.png Download this article as a single PDF document 


I had a special need where my DHCP server had to hand out dynamic IPs from a specific range to PXE boot thin clients and to
boot normal DHCP clients using a different IP range. In my case there was only one "normal" DHCP client - a laptop which was often replaced.


Software used in this setup:

NOTE: gPXE was forked and the new project can be found at: http://ipxe.org/

Config file

This config file includes setup for gPXE as well. And this is how it looks like:

ddns-update-style none;
log-facility local7;

option space gPXE;
option gPXE-encap-opts code 175 = encapsulate gPXE;
option gPXE.bus-id code 177 = string;

class "PXEClients" {
        match if substring (option vendor-class-identifier, 0, 3)="PXE";
        one-lease-per-client on;
        option root-path "";
        allow booting;
        allow bootp;
        if not exists gPXE.bus-id {
                filename "gpxe/undionly.kpxe";
        } else {
               filename "";
class "Laptop" {
        match hardware;
        lease limit 1;
        set vendor_class_identifier = option vendor-class-identifier;

shared-network "MyNetwork" {
        subnet netmask {
                option subnet-mask;
                option routers;
                option broadcast-address;
                default-lease-time 28800;
                max-lease-time 86400;

                pool {
                        deny members of "PXEClients";

                pool {
                        allow members of "PXEClients";
                        deny members of "Laptop";

Pay attention to the match if substring (option vendor-class-identifier, 0, 3)="PXE"; option.
It lets you fetch information sent by the PXE clients and create a class definition based on that.
The 0 and 3 numbers define to use only 3 letters of the string sent by vendor-class-identifier, which in whole is actually PXEClient. But using just PXE is enough to catch that.
What PXE clients sent looks as follows:

Vendor-Class Option 60, length 32: "PXEClient:Arch:00000:UNDI:002001"

NOTE: It's useful to debug your setup with tcpdump to see all the relevant traffic information:

# tcpdump -s 0 -vv port bootps



That's all folks.

<comments />

Fernando said ...

<comment date="2012-05-19T13:24:29Z" name="Fernando"> The code technically beognls to where I work, so I probably can't, sorry.The theory is, though:Prep: On the Infoblox, have a DHCP range that is limited to only allow MACs that are in a certain filter. On the Infoblox, have a Fixed Address template with the settings you want.In action: Grab the macaddr of the device you want to boot. Create a new fixed address object from the fixed address template. Put it in the DHCP range. Use the device macaddress. To determine the IP, you have to grab all IPs in the DHCP range and dig through them to find one that is not used, and doesn't have an IP/Mac Address assigned. You have to do this vs. using their function because there are situations where it thinks it is free, but is actually assigned. I ran into this on our stuff at least. Create DNS records as necessary. Create a new MAC object holding the mac address of the device. Add that new MAC object to the proper MAC filter. Watch device boot, it should boot on the specific IP.Doing this from memory, but I'm pretty sure this is how I have it going Good luck! </comment>