Yep, that solved it. Routing was the whole problem. Option 3 on the DHCP server for Vlan 300 was indeed outside of the subnet for that scope. I pointed it to the SVI on the routing stack and everything is great. We now have FOG with vlans! Thanks guys.

@Sebastian-Roth I changed the FOG server over to 255.255.240.0, the old subnet was from before vlans were implemented it just got passed over

@defcon said in Unable to PXE boot on from different subnet:

On the subnet that is 10.80.x.x the Dell computer won’t PXE boot, but when I bring the computer physically on this network it boots just fine in PXE.

When you move this computer are you hooking it up to an entirely different switch? I recently ran into both of those errors you have posted a picture of. Here’s a checklist I’ve found that works for us:

Ip-helper address or dhcp-relays set up on each VLAN, and on each switch.
Spanning-Tree set to rapid-pvst (because of the switch model that we have.)
Portfast enabled.

Specifically with that bottom error I had to add all of the hosts to a new group (that I called Encryp Reset), go into the group general settings for that group - reset their encryption data. Deploy an image to the hosts again - got that same error again (no configuration methods succeeded) Then I rebooted the computer and upon the next cycle it worked just fine. I’ve had to do this maybe 50-60 times so far. Random Dell Optiplex 990s just seem to do it.

@george1421 Well, I think I have it figured out. Thanks for the kick in the right direction. The problem was apparently that the primary stp root for vlan 300 was a completely different switch in a different building. I set the main switch here in this building (where vlan 300 is anyways) to be the primary root and so far every one I’ve tested works. I am about to image a few labs so that will be the real test.

Wireshark data posted privately. Some info about the data:
The problematic client is getting a dhcp address successfully of 10.241.96.20. (It says it for PXE and I can see it pop up on the DHCP server.)
I let the capture run from a computer right beside (also on the same vlan and switch) . The capture ran for two loops of “no configuration methods succeeded”. There are a lot of TCP retransmissions coming from the fog server.

To simplify matters early on I unplugged 3 of the members of the fog’s NIC team so it only has one right now and I am pretty sure the capture caught the tail end of a computer lab imaging.

I see the “malformed” dhcp packets, but I have no idea what is causing them… aside from laughing at their name I am reading up on the topic.

@george1421 Yeah, I know. I will still make that diagram outlining the problem as best I can and post it along with some wireshark data. I tried digging through some capture data following the dhcp discovery/offer/request/acknowledge and they were all there for client and all of the numbers looked good.

Sweet deal. I updated to the latest trunk build, set the boot file on the dhcp server to the 10 second ipxe.kpxe file and now everything boots.

Is there an easy way for me to adjust that delay? Say…make it 5 seconds?

Something else I noticed:

The computers that were continuously failing with “no configuration method succeeded” were filling up the DHCP lease with bad address entries…

I tried pinging those IPs from everything I could just to make sure they’re not static on something (nothing should be outside of the management vlan here).

Another weird thing is that now that I am using the 10s delay to boot they do not fill up the dhcp scope anymore with bad addresses. They even get the old IP that was otherwise “bad” in the previous case. ?.?

I checked on the switch’s config files. Portfast is enabled globally as is the spanning-tree mode (rapid-pvstp). I have found something else out that seems a little odd to me. On the machines that are giving this error, when it gets to the “hit s to enter the shell” part I can do that, give iPXE a static IP, and then ping the DHCP server just fine.

Also, while turning on one of these machines and watching in the DHCP leases on the server I can indeed see that it does create the lease - but the odd thing is that by the time it gets to “no configuration methods succeeded” the lease is gone from the server.

@george1421 I am going to put together a detailed diagram complete with configs and network info and maybe something will jump out. I’ll probably toss that up on Spiceworks too.

@george1421 Well we still have some kind of problem.

I am working with one machine now to try and solve it. It keeps getting the “no configuration methods succeeded message”. Placing the D-Link switch in between it and the cisco switch fixes the problem.

I traced the physical port back to the switch to be 100% and then logged in and check the settings. It is part of vlan 300 with the stp mode set to rpsvt. It has portfast enabled.

It definitely seems like the switch is taking too long. Portfast is supposed to immediately put the port into a state of forwarding according to everything I have read but this PC flies right through the menu with a D-Link switch in place…

To complicate matters, when the D-Link is not in place there isn’t a 100% failure rate - it succeeds some times.

Does anyone have any ideas on what I could check next? For the time being I am reading up on c2960x stacks and STP, but I am considering just turning it off completely on something. Maybe make a new VLAN, turn STP off for it, set the switches to it in order to deploy my images and then revert back to normal afterwards.

@george1421 Well, I think I have it figured out. Thanks for the kick in the right direction. The problem was apparently that the primary stp root for vlan 300 was a completely different switch in a different building. I set the main switch here in this building (where vlan 300 is anyways) to be the primary root and so far every one I’ve tested works. I am about to image a few labs so that will be the real test.

@george1421 Just put a little 5 port D-Link in place and rebooted the computer a few times. It has not failed yet. The computers in this room are connected to the second member of a 2960x cisco stack. The stack master has spanning-tree mode set to rapid. I guess I will try to make sure that each member also has the spanning-tree mode set that way? I thought that the master would set it for all.

I ran this command after it failed and am now trying to track down why there is such a high RXE value.

Server

• FOG Version:1.5.0-RC-2
  OS: CentOS 7

Client

• Service Version: 11.12
• OS: Windows 10

Description

Random computers give this error when you turn them on.
This is not an extremely pressing issue as a few reboot cycles always seems to fix it, but it would be nice to know what is causing it.

Here’s some info about the setup:
1.) All Dell Optiplex 990s
2.) All latest BIOS versions.
3.) All in the same LAN (vlan 300)
4.) All set to legacy boot with NIC at the top, then HDD
5.) Spanning-tree is set to rapid mode on all switches. (c2960x)

There seems to be no pattern to the error - the same computer can successfully boot and then the very next time give this error. Then you can restart that one and it will succeed the next time. This leads me to believe it might be something network related and not a FOG setting? Any ideas on what I could check?

@sebastian-roth Hmm. I definitely do not reinstall anything after sysprep. I run .\sysprep /generalize /oobe /unattend /shutdown and then capture. I have the fog service set to manual with recovery options set to restart it. After the images are deployed the batch file does a net start fogservice and then they join the domain.