Either DHCP failed or we were unable to access http://(ip)/fog//index.php for connection testing
-
This post is deleted! -
@Sebastian-Roth This two FOG servers in the image are the same, but i tryed to show the case that it works and the cases that it doesn’t worked. All the switches are on the same subnet, the ips of that subnet: 200.236.22.129 to 254, and the DHCP is beeng served by an “external” DHCP server.
-
@Lucas-Sônego So both labs have the same ip subnet?
Both are using the same dhcp server?
What device is your external dhcp server?
-
@george1421 yes, both them are using the same DHCP server and the DHCP is distributed by a server machine on our network central that distribute internet to all the subnets in the university (and the image represents one of those subnets).
-
@Lucas-Sônego OK very good.
For the lab with 43 systems. Do you have a dumb (unmanaged) switch you can use for testing? The more basic switch the better. I want you to insert that dumb switch between the building network switch and one of the pxe booting computers, then pxe boot it to see if it works for you.
Since this issue is impacting the entire lab and not random hosts in both labs, I’m going to suspect its a spanning tree issue, where these 43 PC lab switch have spanning tree enabled (good thing) but don’t have one of the fast spanning tree protocols (RSTP, MSTP, fast-STP) enabled (a bad thing).
If you don’t have a dumb switch then we can find out the issue the hard way. But inserting a dumb switch is the quickest way to test if its a spanning tree issue.
-
-
@Lucas-Sônego Ok this only creates more questions than answers.
In the second picture why are you getting a 192.168.1.1 IP address?
That TP link looks like a home router, does it have dhcp services turned on? I might think yes, If it does you need to turn it off or you will cause chaos on your campus network. But that is a good idea to use a home router switch for a dumb switch. Those should not support spanning tree.
The dumb switch only needs to be between the pxe booting computer and the building network. The FOG server is OK to stay on the building network since it never drops its network link.
-
This post is deleted! -
@george1421 oh, it works, i disabled the DHCP of the home router and connect the fog server back to the building network
-
@Lucas-Sônego said in Either DHCP failed or we were unable to access http://(ip)/fog//index.php for connection testing:
i disabled the DHCP of the home router and connect the fog server back to the building network
OK great. That tells us you need to get your networking team to look at the switches in the 43 system lab. They (network team) need to enable one of the fast spanning tree protocols on those switches.
Simply with standard spanning tree the port doesn’t start forwarding data for 27 seconds every time the network link winks. It will wink 2 times during pxe booting the first time is when the PXE rom hands over network control to the FOG iPXE menu, and the second time is when iPXE hands over the network to FOS Linux. Every time the network winks, it starts the 27 second time over again. FOG/FOS linux boots so fast by the time 27 seconds are up and the port starts forwarding data FOS has already given up. You need to use one of the fast spanning tree options in your switch so that it starts forwarding traffic right away then listens for 27 seconds for a loop back packet.
-
@george1421 ok, so what the network team needs to do is enable RSTP, MSTP, or fast-STP and FOG should work?
-
@Lucas-Sônego said in Either DHCP failed or we were unable to access http://(ip)/fog//index.php for connection testing:
@george1421 ok, so what the network team needs to do is enable RSTP, MSTP, or fast-STP and FOG should work?
In a word, yes.
In a few more words, the lab with 23 computers is configured correctly. So if they compare the settings between the 2 switch groups they should see the solution.
-
@george1421 ok, thanks for the help : )
-
I recently ran across this same issue, but it was not due to the fast spanning tree protocols. Our IT department added 802.1x authentication on the wired ports of all our switches, but the time out to fail back to MAC authentication was just longer than the 27 seconds @george1421 referenced in his post. We had a handful of hosts work, but a large majority failed. Our IT department had to shorten the 802.1X authentication timeout in order to make this work for us.
