TFTP/PXE Boot Issues
-
This post is deleted! -
That was correct, but I recently moved the FOG server to a different subnet for testing purposes. Ideally I’d like to house it on the 172.16.50.x/24 subnet, so I’ll move it back since the issues still exists.
-
@CamGreezy well if you could leave it for some testing it will help.
The idea is that we will use the fog server and the tcpdump utility to record the dhcp / pxe booting process to understand who the actors are in the pxe booting process. The output of the tcpdump utility we can look at with wireshark to understand who is saying what. If the fog server is on a different subnet then we won’t hear the dhcp announcements.
This tutorial will help you generate the necessary pcap file. https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue
Then upload that pcap file to a google drive or dropbox and share the link with me in the forum or via FOG Project messaging if you don’t want it public.
-
https://drive.google.com/file/d/0B7KKPwLD3OQQU3l5RGg5MTNpSGs/view?usp=sharing Is the output file when trying to boot from the same subnet.
https://drive.google.com/file/d/0B7KKPwLD3OQQZGNEdFc0WmF2Smc/view?usp=sharing Is the output file when trying to boot from the workstation subnet.
-
@CamGreezy digesting it right now.
-
@CamGreezy first file (will need you to process what I will tell you)
pxe booting hardware vmware vm in bios (legacy) mode.
DHCP server 172.16.50.41 (which may also be a AD/DNS server too) responds with:- next server 172.16.50.29
- boot file undionly.kpxe
Then we see a normal request and ack sequence
Target computer queries 172.16.50.29 for undionly.kpxe file size
Target then asks for undionly.kpxe from tftp server
Then nothing… I would expect to see the target computer download that file.
Then after a timeout the client goes through a discover / offer sequence.
I don’t see any reference to 172.16.50.23 in the first one.
-
@CamGreezy The second one doesn’t have any usable information. It just looks like more of the post dhcp request from the first one.
-
I can’t find anything that explains the picture you posted initially other than there is a second dhcp server somewhere with a different next server (dhcp option 66) setting.
-
Oh ok, that’s exactly the issue. Have not worked with PXE much before and thought the option 66 and 67 info would replicate to our 2nd DC, but that was not the case. Fixing that lets me boot right into FOG. Thanks for the help!
-
I expect the 2nd file didn’t give any output because it was from a different subnet. Could you please point me to the info I need to configure FOG to run across subnets before you mark this as solved?
Thanks again, feel a little silly but now I know!
-
@CamGreezy Great you found the issue. This one was a real brain buster because I didn’t see a second offer in the dhcp pcap you sent. A lot of times if there are two dhcp servers on the same network you will see an offer from both. That tells us right away what is wrong. Obviously you had a silent dhcp server when we were scanning.
Anyway. It sounds like you are good to go now.
-
@CamGreezy said in TFTP/PXE Boot Issues:
I expect the 2nd file didn’t give any output because it was from a different subnet. Could you please point me to the info I need to configure FOG to run across subnets before you mark this as solved?
Whoops, I just marked it solved.
FOG will run across subnets as long as you have routing setup correctly on the fog server. If the fog server can ping hosts on remote subnets then you should be able to image across subnets. Are you seeing a specific issue?
-
Nothing specific, just know it’s something I have to do that I haven’t yet. I was having trouble finding anything referring to that specifically on the wiki so if you have a link to any documentation that would be helpful, otherwise I’ll put some time into it and make a new post if I hit any specific issues.
-
@CamGreezy If the subnet is at the same site then as long as routing is working then you can image. It uses the same tools. There is an issue with WOL (wake on lan) if you have different subnets you need to allow directed broadcasts on your network. But from an imaging stanpoint as long if the fog server can reach it, it should work.
Now if your remote site is connected over a low speed link (like mpls) then you might want to think about installing a fog storage node at the remote location to help with the imaging process.
