IPXE / DHCP problem?

[cf20corvuss]

Hi! Just to give some context, I’m a student doing a class poject about FOG project.
I don’t know how much information I can provce further than a few screencaps that i’ve taken during the process.

Thing is that, after quick registering a host in my server (everything is done through virtual machines), the client begins to loop giving me a DHCP /IPXE related problem. DHCP works, I assume, because my clients are getting IPs as soon as they connect to the server via network.

Beyond that, all I can say is that the server has a NAT+Host only adapter, and clients also have a H.

Thanks in advance for the help.

[Sebastian Roth]

@cf20corvuss I suppose your are using VirtualBox, right? This is a known issue. If you shutdown the VM and “cold start” it up the issue does not happen.

A quick fix is to change your DHCP config to send ipxe.pxe (instead of the default undionly.kkpxe).

[george1421]

@cf20corvuss Well lets think about this for a minute.

The screen shot you provided looks like the fog ipxe boot loader. If it is we can then make a few assumptions. My hesitation ATM is that some hypervisor’s use iPXE as their pxe boot rom (Virtual box being one). If we work under the assumption that the screen shot shows the FOG iPXE boot loader we know this.

1. The target computer can speak to the FOG server. We know then because the iPXE boot loader was sent by the FOG server and received by the PXE booting computer.
2. The target computer is getting a dhcp address from some place AND that dhcp information told the client where to get the iPXE boot loader from. So we know that dhcp is working.
3. We know that iPXE has the proper driver for the network card in the pxe booting computer because iPXE sees the mac address of the network adapter.

Where we typically see this is with the network configuration where Spanning Tree is enabled but one of the fast spanning tree protocols are not used. Standard spanning tree will listen for a loop back interface for the first 27 seconds a link is active then start forwarding data. With imaging when the PXE ROM hands off control to iPXE, iPXE will reset the network interface causing the link to drop briefly as iPXE boots. Well this link briefly dropping causes the spanning tree counter to reset. So when the target computer is trying to get an IP address again, spanning tree is still listening for a loop back. By the time standard spanning tree starts forwarding data again, iPXE and FOG have already given up.

You can test this in a physical world by putting a dumb unmanaged switch between the building network and the pxe booting computer. This unmanaged switch will keep the building switch from seeing the brief link drop. Most cheap switches do not support spanning tree. So its all good there.

Now NAT and imaging do not go together with FOG. Everything needs to be bridged with real addresses for FOG imaging to work.