How do I get a Mac to request a new IP address from another DHCP server running in parallel while Ne
- by huyqt
Hello,
I have an interesting situation.
I'm trying to us a Linux based machine to allow Mac's to Netboot (similiar to PXE boot) by running a DHCP service in parallel with the "global" DHCP server.
The local DHCP server hands out IPs in a private subnet, e.g., 10.168.0.10-10.168.254-254, while the "global" DHCP server hands out IPs from the IP range 10.0.0.1 - 10.0.1.254.
The local DHCP range is only supposed to be used in Preboot Execution Environment and Netboot. The local DHCP server is something I have control over, but I do not have access to the global DHCP server.
I have a filter to only allow members with the vendor strings "AAPLBSDPC/i386" and "PXEClient".
PXE works fine, but Netboot has a quirk.
The Apple systems that haven't been connected to the network yet can Netboot fine. But once it grabs a "real" IP address from the global DHCP server, it will "save" it and request it the next time we want it to netboot (which the local dhcp server won't give it).
This is what I want:
Mar 30 10:52:28 dev01 dhcpd: DHCPDISCOVER from 34:15:xx:xx:xx:xx via eth1
Mar 30 10:52:29 dev01 dhcpd: DHCPOFFER on 10.168.222.46 to 34:15:xx:xx:xx:xx via eth1
Mar 30 10:52:31 dev01 dhcpd: DHCPREQUEST for 10.168.222.46 (10.168.0.1) from 34:15:xx:xx:xx:xx via eth1
Mar 30 10:52:31 dev01 dhcpd: DHCPACK on 10.168.222.46 to 34:15:xx:xx:xx:xx via eth1
Mar 30 10:52:32 dev01 in.tftpd[5890]: tftp: client does not accept options
Mar 30 10:52:53 dev01 in.tftpd[5891]: tftp: client does not accept options
Mar 30 10:52:53 dev01 in.tftpd[5893]: tftp: client does not accept options
Mar 30 10:52:54 dev01 in.tftpd[5895]: tftp: client does not accept options
This is what I get when it already has a "stored" IP:
Mar 30 10:51:29 dev01 dhcpd: DHCPDISCOVER from 00:25:xx:xx:xx:xx via eth1
Mar 30 10:51:30 dev01 dhcpd: DHCPOFFER on 10.168.222.45 to 00:25:xx:xx:xx:xx via eth1
Mar 30 10:51:31 dev01 dhcpd: DHCPREQUEST for 10.0.0.61 (10.0.0.1) from 00:25:xx:xx:xx:xx via eth1: ignored (not authoritative).
Do you have any suggestions? It would be much appreciated.
