BIOS + UEFI in a CISCO network
-
@george1421 Thank you very much.
Just tell me one other thing, please: my Cisco is also my DHCP Server.
Do I remove both option 66 and option 67 from the configuration, or just option 67? -
@pcrispim I would remove both. DNSMASQ overrides dhcp options 66 and 67. But when dnsmasq is not running dhcp options 66 and 67 are active you may get unexpected results (like trying to pxe boot from a dead pxe boot device). Its best to just remove values if they are not being used so 3 years from now you don’t scratch your head trying to understand how those values got there.
-
@george1421 , thank you.
I did that, but still can’t get UEFI computers to work with FOG.
I asked the IT team to remove option 66 and 67, and BIOS computers are working, but not UEFI ones.
Could IT guys missed something? -
@pcrispim If you are using my configuration and bios computers are working then so should uefi computers. Lets confirm that the uefi computers are on the same IP subnet as the FOG server?
-
@george1421 Yes, they are. When computers boot, they are placed in a Quarentine VLAN (10.1.8.0/23), which is where the FOG Server is (10.1.8.1).
Another thing: I see UEFI computers boot to PXE, but I get no output messages, only that it is trying to connect (and don’t find a place in UEFI where I can configure so it is a verbose output).
Also, the FOG server as another NIC in a different VLAN, so clients can connect to it once a user logs on (so the FOG Client can communicate with FOG server in a different VLAN).
That has been working for over a decade, so I don’t think that’s the problem.
I also tried to add a line in ltsp.conf with “interface=enp12s0”, which is the interface with the 10.1.8.1 IP Address.Is there a way I can see the dnsmasq log and figure out if the UEFI computers do try to communicate?
-
@george1421 One other thing: in BIOS computers, I get no menu when I boot to PXE, and I think it was supposed to appear the menu, because I see it in the ltsp.conf file, right?
What I’m wondering is that maybe the IT guy removed the options but didn’t restart the service or something like that. -
@pcrispim There is a lot of things to unpack here.
When computers boot, they are placed in a Quarentine VLAN (10.1.8.0/23), which is where the FOG Server is (10.1.8.1).
Ok on this quarantine vlan what device is your dhcp server?
Also, the FOG server as another NIC in a different VLAN, so clients can connect to it once a user logs on (so the FOG Client can communicate with FOG server in a different VLAN).
FOG is only designed to work for imaging with a single network interface. You can have multiple management or interfaces network cards, but as you noted you will need to bind dnsmasq to a single interface so you don’t confuse pxe booting clients on other vlans.
That has been working for over a decade, so I don’t think that’s the problem.
Makes me wonder what version of FOG are you running??
Is there a way I can see the dnsmasq log and figure out if the UEFI computers do try to communicate?
I have a tutorial on using the FOG server to capture the packets the target computer is being told for the dhcp process I think we need to get a pcap to see exactly what is going on. Its a bit more in depth step to see what they are really being told.
https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue
Look at the pcap with wireshark. The DISCOVER packet will be from the target computer. Look at dhcp option 93 or 94 (can’t remember) that is where the client will say I’m a bios or uefi computer. Then look at the offer packets. You should see two. One from your main dhcp server and one from dnsmasq. The dnsmasq OFFER will have dhcp option 60 set to something like PXEClient and the main dhcp sever OFFER will not have dhcp option 60. DHCP option 60 tells the client its a proxydhcp packet. After the ACK packet you should see the client reach out to the FOG server on port 4011. Then you should see the tftp request from the client for the boot loader files. If you don’t know wireshark then post the pcap to a public file share and then either post the link here or DM me the link in FOG chat and I will take a look at it.
-
@george1421 said in BIOS + UEFI in a CISCO network:
@pcrispim There is a lot of things to unpack here.
When computers boot, they are placed in a Quarentine VLAN (10.1.8.0/23), which is where the FOG Server is (10.1.8.1).
Ok on this quarantine vlan what device is your dhcp server?
It’s a CISCO device (I don’t know if it’s a router or a layer 3 switch)
Also, the FOG server as another NIC in a different VLAN, so clients can connect to it once a user logs on (so the FOG Client can communicate with FOG server in a different VLAN).
FOG is only designed to work for imaging with a single network interface. You can have multiple management or interfaces network cards, but as you noted you will need to bind dnsmasq to a single interface so you don’t confuse pxe booting clients on other vlans.
How can I do that? Is it enough to put a line in ltsp.conf to use only the network interface that is bind to IP 10.1.8.1, like this:
interface=enp12s0
That has been working for over a decade, so I don’t think that’s the problem.
Makes me wonder what version of FOG are you running??
I’m in the latest stable version, 1.5.9
Is there a way I can see the dnsmasq log and figure out if the UEFI computers do try to communicate?
I have a tutorial on using the FOG server to capture the packets the target computer is being told for the dhcp process I think we need to get a pcap to see exactly what is going on. Its a bit more in depth step to see what they are really being told.
https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue
Look at the pcap with wireshark. The DISCOVER packet will be from the target computer. Look at dhcp option 93 or 94 (can’t remember) that is where the client will say I’m a bios or uefi computer. Then look at the offer packets. You should see two. One from your main dhcp server and one from dnsmasq. The dnsmasq OFFER will have dhcp option 60 set to something like PXEClient and the main dhcp sever OFFER will not have dhcp option 60. DHCP option 60 tells the client its a proxydhcp packet. After the ACK packet you should see the client reach out to the FOG server on port 4011. Then you should see the tftp request from the client for the boot loader files. If you don’t know wireshark then post the pcap to a public file share and then either post the link here or DM me the link in FOG chat and I will take a look at it.
I’ve sent you by DM the link to the file
-
This post is deleted! -
@george1421 I used TCPDUMP without telling which ports to listen (tcpdump -i enp12s0 -w output3-BIOS-hp.pcap), in 3 computers:
- UEFI Computer #1 - file is “output1-UEFI-insys.pcap” - https://drive.google.com/file/d/1lBxNv2bhjTtMhPEC2gd66tpzV3egZK5i/view?usp=sharing
- UEFI Computer #2 - file is “output1-UEFI-b560m.pcap” - https://drive.google.com/file/d/1TgiQS15RrESjc3Q92euB7UWOMLPOxXFu/view?usp=sharing
- BIOS Computer #3 - file is “output1-BIOS-hp.pcap” - https://drive.google.com/file/d/1gkz71TMr8XzJovDSOZqyvkcvtsjCz2I0/view?usp=sharing
I think in these files, you can see at DHCP information and finally can figure out how to help me. I really need this to be working. School starts next tuesday and I have a lot of computers to deploy images to.
