6

DHCP Server Not Offering to PXE Client

BACKGROUND:

I'm in the process of adding PXE services to an existing SCCM 2007 server. The SCCM server is separate from the DHCP server (Server 2008 x86) and did not have PXE services or WDS installed. I added PXE services in the Config Manager before adding WDS as a role. Because DHCP is on a separate server, I did not make any changes to DHCP Options (there is not a current 60, 66, or 67 configured).

The WDS is configured with both a boot image (ripped from the Win7 install dvd and an install image which was created by someone else). SCCM has a TS configured and advertised to the Unknown Computers collection.

The DHCP server is configured for both DHCP and BOOTP requests (I added BOOTP as part of my troubleshooting, the default lease time is set to 5 minutes). It also has NAP enabled for the IPV4 addresses but disabled for this SCOPE. My host, the VM, the DHCP server, and the SCCM/WDS server are all on the same subnet. Juniper routers move the packets.

I'm testing PXE using a VirtualBox machine configured to network boot and it has an empty dynamically allocated disk attached. Wireshark is installed on both my host computer (running VirtualBox) and the DHCP server.

PROBLEM:

When the VM starts it performs a network PXE boot. I can see the discover request by the VM in Wireshark on both my host and the DHCP server. However, the DHCP server is not responding with an IP offer. If I could get some guidance as to where else to look for an error, or possibilities as to why it's not working, I'd appreciate it.

EDIT:

The dhcpsrvlog does not record an event regarding the request for an IP from the pxe client.

Colyn1337
  • 2,387
  • 2
  • 22
  • 38
  • For your VM networking settings, are you using NAT or a Bridged Adapter? I had an issue similar to this while using NAT, switched it over to a bridged connection and it worked fine. I think it's in Settings > Network > Adapter 1 – Callen L May 02 '14 at 12:37
  • I started out with bridged, but did try NAT when bridged failed. The PXE client used a private address to try for DHCP so I knew that was a bad config and switched it back to bridge. *I think* the primary problem is that the DHCP server isn't responding to the request it's receiving, as evidenced by the wireshark capture. – Colyn1337 May 02 '14 at 12:41
  • Migrating due to user request. – Daniel Beck May 02 '14 at 13:25
  • If it's not bridged, how will it ever see the DHCP server? Fix that first. – Skyhawk May 02 '14 at 14:14
  • @Skyhawk Lol, it is bridged. I thought I'd made that abundantly clear when I said *"The PXE client used a private address to try for DHCP so I knew that was a bad config and switched it back to bridge"*. The only reason I did NAT at all was to test the pxe software in the VM. – Colyn1337 May 02 '14 at 14:21
  • Is there a dhcp log you can post? – MDMoore313 May 02 '14 at 18:20
  • @BigHomie That's just it, the dhcpsrvlog doesn't log anything for the request from the pxe client. But, it does log the offers for other clients. – Colyn1337 May 02 '14 at 18:33
  • So this problem is limited to all virtual clients, virtual clients that share the host nic, or this client in particular? – MDMoore313 May 02 '14 at 18:38
  • I'm testing primarily with a VM but I have tested with a physical box. Same results – Colyn1337 May 02 '14 at 18:39
  • 1
    So, troubleshoot. You need to figure out where it's breaking down. Use Wireshark or `tcpdump` to look for DHCP broadcast traffic on the physical network. If it's there, why isn't it showing up in the server log? If it's missing, why isn't it hitting the physical network from the VM? You need to isolate the problem on one host or the other. That tells you which tree to bark up. Before you know it, the tasty squirrel will be yours. – Skyhawk May 03 '14 at 15:13
  • @Colyn1337 You tell you have juniper router. Does the packet travel by them ? I got issue with DHCP's option and juniper in the past. The juniper used to not handle correctly any non standard DHCP option. The endpoint gear wasnt receiving the needed packet. Check both wireshark from both side and compare, and make sure it's not lost in the transport. – yagmoth555 Dec 23 '14 at 19:57
  • Is the switch layer 3? Layer 3 switches have the ability to filter out non standard DHCP requests. It may be configured to do so by default. If you can try using a dumb switch temporarily to rule it out. – TriadicTech Jun 29 '15 at 05:42

0 Answers0