FOG works great in local office. TFTP timeout over long distance link.
-
Greetings!
I’ve read the TFTP timeout entry here: https://wiki.fogproject.org/wiki/index.php?title=Tftp_timeout… I don’t think this applies in this situation but did successfully retrieve ‘undionly.kpxe’ via a Windows TFTP client on the remote subnet so that bit is working.Brief topology: I’ve got cross-subnet working in SF using MS DHCP to handout 66/67 via IPHELPER address. Server is x.x.70.x, clients are x.x.40.x. No issues. In Dublin, we replicated the existing setup in SF but we don’t have a MS DHCP server there and use a Cisco switch to handle DHCP instead. The master FOG server is in SF but there is a storage node in Dublin. Clients and Storage Node are part of their own ‘DUBFOG’ group. So Cisco DHCP is pointing its PXE clients to SF FOGs address for TFTP.
Attachment pic is what happens when this goes down. It shows this screen for ~30 seconds and then times out and boots from disk.
There’s no actual error displayed, I think it’s just taking too long. I’ve read some articles related to trunking Cisco and STP and am currently investigating that angle. Looking for any advice I can get. I realize 1.3.0 does have the ability for clients to PXE boot off of storage nodes but that wasn’t working when I last tested it a couple months ago.
-
What is SF?
Do you have multiple DHCP Servers? If so, the subnet that’s getting the timeout, is it using the appropriate DHCP and DHCP Scope options? IP Helpers would certainly help but I don’t know the environment to give any good help.
-
Booting from storage nodes worked fine a few months ago. I think your problem is DHCP option 066 and 067 on the switch - until that is fixed, none of it is going to work.
-
SF = San Francisco
-
I do have multiple DHCP servers.
San Francisco DHCP = MS DHCP = Works fine over 2 subnets. FOG is x.x.70.x. local clients are x.x.40.x.
Dublin DHCP = Cisco DHCP via the switch. DHCP points PXE clients to SF TFTP. DUB clients get an IP but timeout on TFTP attempts. Using a DUB client on 40.x, and attempting to retrieve undionly.kpxe from SF is successful within the OS. There is no firewall issue.Dublin client begins PXE boot as displayed in the screenshot but never gets the PXE boot file.
-
@Wayne-Workman That may be but we have verified the entries there and they are accurate. 66 is pointing to the IP of San Francisco’s FOG/TFTP server and 67 is specifying undionly.kpxe.
-
@BardWood do you have a hub (as opposed to a switch)? I’m just asking, because there’s something you can do to help solve this.
