@fradlo said in Configuring net0... slowly:
Attempt 1: The same thing happens. It passes through the Intel Boot Agent PXE, grabs DHCP quickly, and then chainloads into iPXE 1.0.0 just fine. Then it hangs at configuring net0(MAC) for awhile before successfully continuing forward.
This issue has me a bit baffled. The description above precisely reacts like I would expect if spanning tree was enabled and only standard mode is used. The unmanaged switch should have masked this fact, unless the unmanaged switch supported spanning tree for some reason.
Let me describe what I’m thinking is going on. When the computer boots up the PXE roms have control of the network adapter which then loads iPXE. When the iPXE kernel takes over the network adapter it will momentarily drops (a.k.a winks) the network link as iPXE initializes the network adapter. When the switch sees the network drop, spanning tree switches the port from forwarding to learning, listening for a BPU packet. I will listen for 27 seconds then if no BPU is received it will move the port back to forwarding mode. Then when you transfer control to FOS by either scheduling an imaging task or registration, when iPXE hands off to FOS, FOS will again wink the network link as it takes control over the network adapter, restarting the STP counter. That description matches pretty close to what you are seeing with your 3 tests. When you remove the network cable the kernels see the link state down and just skip trying to get a dhcp address. That also matches up with what you are seeing with wireshark, there is no activity while iPXE is configuring the network adapter.
I guess we need to see if you can confirm with your network admin that you are using one of the fast spanning tree protocols on your building switch??
Random other thought: Do you by chance have some kind of nac/nap system that might delay a port coming up?