I'm trying to PXE-boot a Cisco UCS C240 server to install a new OS over the network, but it isn't picking up an IP address via DHCP during boot. I get the "No DHCP or proxyDHCP offers were received" error from the Intel Boot Agent. A tcpdump on the DHCP server shows no DHCP-related packets were received on the DHCP server machine:

tcpdump -n -e -i eth2 ether src FC:99:47:49:D4:9E or ether dst FC:99:47:49:D4:9E

However, when I boot the machine into the installed operating system (in this case, Windows Server 2012), and configure that network interface for DHCP, it gets an IP address from the DHCP server. If I leave tcpdump running, I see the following:

13:34:36.525646 fc:99:47:49:d4:9e > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 126: > UDP, length 84
13:34:40.118071 fc:99:47:49:d4:9e > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 110: > NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
13:34:40.888206 fc:99:47:49:d4:9e > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 110: > NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
13:34:40.975407 fc:99:47:49:d4:9e > 01:00:5e:00:00:fc, ethertype IPv4 (0x0800), length 66: > UDP, length 24
13:34:41.387736 fc:99:47:49:d4:9e > 01:00:5e:00:00:fc, ethertype IPv4 (0x0800), length 66: > UDP, length 24
13:34:41.418849 fc:99:47:49:d4:9e > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 358: > BOOTP/DHCP, Request from fc:99:47:49:d4:9e, length 316
13:34:41.419144 60:73:5c:68:b4:b6 > fc:99:47:49:d4:9e, ethertype IPv4 (0x0800), length 342: > BOOTP/DHCP, Reply, length 300

What could cause DHCP to fail during the PXE boot process while succeeding when booted into the operating system? As far as I can tell, PXE is using the same network interface that Windows is. At least, the MAC address that is reported during PXE boot is the same as the MAC address that gets the IP via DHCP when Windows is up.


I've seen Portfast (or the lack thereof) cause this. Enabling Portfast on the ports between the DHCP client and server resolved the problem for me.

The other time you may see this issue is with Pre-Boot Execution (PXE) devices, such as Windows Deployment Services. The following figure shows a typical PXE implementation. Here is what happens with PXE:

You apply power to your computer, which activates the NIC, but less than five seconds later, the computer’s POST finishes and the NIC attempts to get an IP address from DHCP so that it can load a boot image directly from the PXE server, which fails.

The computer attempts to get an IP address from a DHCP server several times within approximately 10 seconds, after which it gives up and moves onto another boot device, such as the hard drive. The unfortunate part of this process is that because it fails to get an IP address or connect with the PXE server, you are not able to install your new operating system image on that computer.

The problem with this scenario is that because STP makes the computer wait 45 seconds prior to forwarding traffic on the port, the PXE network boot has timed out. image0.jpg PortFast is the solution to this problem of delays when client computers are connecting to switches. PortFast is not enabled by default. With PortFast enabled on a port, you effectively take the port and tell spanning tree not to implement STP on that port.

This solution is not a bad one if only one computer is plugged into the port — so that people will not be creating accidental loops on the network, which can be frighteningly easy to do.


| improve this answer | |
  • Agreed. I think the standard recommendation is to enable portfast on all host connected switch ports. – joeqwerty May 13 '13 at 18:08
  • @joeqwerty Not using portfast on ANY edge ports and enabling BPDUguard on all of them. End-point devices have no business doing STP in the first place (Unless the device is a bridge, which is not really an end-point device and whether or not you want STP over the bridge which depends on what is behind the bridge.) – Tonny May 13 '13 at 18:15
  • Enabling portfast on the port resolved the problem. – Lorin Hochstein May 13 '13 at 19:37

If you're unable/unwilling to turn on portfast (or equivalent) for the computer's port, I found that you can also hit the Pause key on your keyboard at some point after it prints "DHCP...". The ASCII graphics will stop spinning. Wait 30 seconds or whatever's needed, hit a key to unpause, and then you'll network boot just fine.

| improve this answer | |
  • Could work. The same thing was also suggested in an earlier answer. – kasperd Jul 30 '17 at 10:34
  • 2
    Yeah, but other answer suggested hitting it "early in the boot", "before PXE starts its boot attempt". That doesn't work in my situation. PXE prints a message saying it's initializing the link, then immediately also starts the "DHCP......" The pause is only effective at that point. All depends on your hardware and when it brings up the ethernet link I guess - my situation is with recent Dell OptiPlex desktops. – Stingray Jul 30 '17 at 11:29

Usually it is one of 2 things (or both simultaneously).

1) Spanningtree protocol on the edge port to which the server connects, Like Ryan Ries already mentioned above.

2) Auto-negotiate between the PC and the switch which takes longer than the time that the PXE bootloader is willing to wait for an address.

If you have no control over the switch the best option is usually to boot the server to Bios. Wait a minute or so to let the switch settle and then leave the bios to continue booting.
Pressing the Pause/ScrollLock button on the keyboard early in the boot (before PXE starts it's boot atempt) can achieve the same thing.
Both scenarios of course imply that you can attach a keyboard and monitor to the device.

| improve this answer | |

I usually bypass the portfast requirement by making hosts do the extended memory check in the bios (not sure about Cisco but HP and IBM allow this setting) by the time the host boots to PXE everything is able to forward. UEFI systems also seem to slow up the boot process. I'm not saying the portfast option won't work but sometimes it's a tough sell to the "that's the way we do things" networking types. This has worked everytime and everywhere I've tried it, without network intervention.

| improve this answer | |

I had this similar problem after my WDS Server and Switch took a power hit. What I found out was the DNS setting in the Server\Options setup was NULL, so I had to put the DNS setting in, I also verified the other server options setting to see if they were nulled.

| improve this answer | |

Using MAAS 1.7.6 you have to click on Clusers, then on the cluster name, then edit the interface. Then in Management you can add DHCP and DNS and the DHCP particulars. Save the interface. Check that the process dhcpd shows up in your list of processes.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.