Unsolved PXE Boot issue on second FOG-Server
-
Hello everyone,
Here is my problem:
I use two FOG servers on two different sites.
- The first: 10.10.10.38/24 works correctly. I have been using it for several months.
- The second: 10.20.10.38/24 is problematic. It’s a new one.
I configured the second server exactly the same as the first (verified)
I configured DHCP ports 66/67 for both servers in the appropriate VLANs.The server problem (10.20.10.38/24) communicates perfectly with the computers on my network (ping ok, client installation ok, ect)
The problem is that, as soon as I want to boot on the 10.20.10.38 server, nothing happens during pxe booting, it drops IPV4 and searches for IPV6 (it does nothing).
VLAN 10.20.88.0 and 10.20.82.0 (on which I configured port 66/67 from DHCP to server 10.20.10.38) finds NOTHING.
When I change DHCP port 66 to 10.10.10.38 : pxe boot starts directly.
Network/firewall level, nothing seems to hinder anything. My two servers are in VLANs which have freedom.
Obviously, everything is OK in the BIOS.
What are your ideas ? I can provide photos but I think the explanation is clear.
PS:
A little additional info :
The two servers are hosted on two different ESXIs (each on a geographical site) again, there do not seem to be any particular security rules -
@El-Fogito said in PXE Boot issue on second FOG-Server:
VLAN 10.20.88.0 and 10.20.82.0 (on which I configured port 66/67 from DHCP to server 10.20.10.38) finds NOTHING.
The first question is that is 10.20.88.0 fully routable to 10.20.10.38? i.e. can you ping 10.20.10.38 from the 10.20.88.0 subnet?
Do have any firewalls or screening routers that might stop udp port 67 and 68 from reaching 10.20.10.38? You can test this by using a computer on the remote subnet and trying to tftp one of the boot files from the fog server.
You are saying that you can change dhcp option 66 from 10.10.10.38 to 10.20.10.38 and the remote system can’t pxe boot. This eliminates dhcp server and possibly any router dhcp helper/relay settings from the problem.
If you have a witness computer (third computer on the remote subnet running wireshark) on the 10.20.88.0 you might setup a pcap to see what the remote pxe booting computers are being told what to load. This would ensure that the remote pxe booting computer was being told the proper values. If true then you can eliminate dhcp infrastructure issues and then deal with IP routing as the problem.
Is there any WAN links between 10.20.10.38 and 10.20.88.0/24 subnets? I have see WAN links that have a smaller MTU than the tftp block size cause a problem. I think the default block size for tftp is 1468 so if the link MTU is below that value it will case the tftp packet to fragment and then fail to download. From your error message it doesn’t sound like this is the issue, but its always good to ask.