@Sebastian-Roth OK. No problem.

@Sebastian-Roth Yes. I marked @Quazz as the correct answer.

From what I’m finding this may be a router issue. I created a VM FOG server on VLAN 192, connected the client to the same VLAN and successfully PXE booted. When I plugged in the client to VLAN 194, PXE times out on http again. Are there any suggestions to resolve this?

I saw in this post https://forums.fogproject.org/topic/12368/fog-dhcp-server-on-multiple-vlan-network/4 mention of properly configuring Windows 2012 DHCP by Goerge1421. He also mentioned PXE roms may be an issue.

"Lets take a step back here. With such a complex network why are you using the FOG DHCP server instead of your network infrastructure dhcp servers?

FOG does work across subnets, what you need is the dhcp server responsible for those other subnets to set dhcp option 66 to the fog server IP and dhcp option 67 to the boot kernel. The issue you will run into now is that if you have both bios and uefi systems on your network, your dhcp server will need to be smart enough to send the right boot kernel name based on the target hardware. Windows dhcp on 2012 and newer will do this correctly if configured right. Linux dhcp server does that automatically like FOG uses.

If you have inter vlan routing working correctly, you can/should be able to image with FOG. There are some pxe roms that are not very smart and may not like pxe booting across subnets.

Instead of messing with all of these dhcp helpers, you should take a step back and answer what device provides your dhcp services for these other subnets?"

@sebastian-roth Prior to NIC configuring it states Sleeping 10 seconds to wait for STP/Powersave to switchoff and on

@tom-elliott bummer no luck. The NIC activity lights have continuous blinking during the http chaining. Would this indicate it’s not sleeping?

@sebastian-roth Nope. It’s still an issue. I’m just demonstrating after boot.php timeout I can reach the http address manually from ipxe shell. So port 80 isn’t blocked but for some reason it times out.

@tom-elliott I hit ‘s’ to access iPXE shell after boot.php timeout, typed in http command found in default.ipxe and was able to reach boot.php.

Default.ipxe contents:

#!ipxe
cpuid --ext 29 && set arch x86_64 || set arch ${buildarch}
params
param mac0 ${net0/mac}
param arch ${arch}
param platform ${platform}
param product ${product}
param manufacturer ${product}
param ipxever ${version}
param filename ${filename}
param sysuuid ${uuid}
isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme
isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme
:bootme
chain http://10.20.164.94/fog/service/ipxe/boot.php##params

@tom-elliott 7450 iPXE config

7490 iPXE config

@tom-elliott Here is the 7450.

@tom-elliott The other machine is on the same subnet. I have it plugged into the same switch as the nonworking devices. This also occurs on Dell AIO 7490 and later release than the working Dell 7450 AIO.

@sebastian-roth I just updated to 1.5.9 and getting same issue. Still works on older Dell PCs. Also, updated kernel to version 5.10.34.

@sebastian-roth It’s not that I don’t want to, rather I have time restraints. We have a large environment running 10 nodes and I usually run into DB issues when upgrading. Perhaps I’m not upgrading in the correct manner? What’s best practice? The main server is a VM so I have lots of flexibility.