Having done lots of network booting over the years, here are a few of my lessons learned:

PXE is a big improvement over the boot EPROMs that we needed to install on our NICs back in the day. Those would get an address via DHCP and then TFTP the boot image, and boot it.

I've had some trouble with PXE boot that's been caused by STP. If your PXE boot server has, or is behind a bridge with STP turned on, it can prevent the client from booting. I think this has something to do with the STP "learning state", but turning off STP on the bridge can solve the problem, as long as you're sure that you will not be creating any network loops on the affected interfaces.

There's also a new "https boot", which is supposed to be a PXE replacement, but TLS certs have time validity windows, and some clients may not have an RTC, or might have a dead CMOS battery, and those might not boot if the date is wrong.

You don't need to turn off STP, usually it's enough to set the forward delay to a very small value ("port fast" in cisco commands). If there is a loop, the port will usually still detect it, you at the most get a handful of multiplied packets.

And all the "http boot" firmware I've seen either always ignores certificate errors or doesn't do TLS anyways.

> There's also a new "https boot", which is supposed to be a PXE replacement, but TLS certs have time validity windows, and some clients may not have an RTC, or might have a dead CMOS battery, and those might not boot if the date is wrong.

I think the lack of entropy right after boot can also be a problem for the RNG. But, maybe that has been solved in more modern hardware.