WDS, PXE Boot, DHCP and VLANs… How to manage?

I’m a big fan of easy deployment, scripting, automating etc… Therefore I love deployment tools. I am constantly using tools like Microsoft System Center, WDS, MDT, etc… Thanks to these kinds of tools, I can be alone and have the workforce of an IT army :)

but, as usual, there is always “something” in the way that things won’t always go as smooth as you want. So the problem with these tools is the complexity of setting them up. If you think it’s worth to put it in place and it will make you save a lot of mone… sorry, “time” than there is no doubt that a couple of hours or days that you spend on setting these systems up is worth the effort.

So my problem is with a WDS (Windows Deployment Services) PXE boot with different vlans (subnets).

My Environment:

- Server 2012 R2 (WDS Server with PXE) – VLAN 1

- Server 2008 R2 (DHCP, DNS, AD) – VLAN 1

-          HP 3800 Layer 3 Switch with 2 Vlans. Routing between subnets is enabled.
                                     vlan 1 = 192.168.2.0/24
                                     vlan 8 = 192.168.8.0/22

- Windows 7, PXE enabled clients

Problem Description:

When a client is connected to the VLAN1 or 192.168.2.0/24 subnet, the PXE client can receive the WDS server IP address and the TFTP information to start loading the boot files. So, there is no problem at all with the VLAN 1, because the DHCP, WDS and the client are all on the same subnet.

When a client is connected to the VLAN8 or 192.168.8.0/22 subnet, the PXE client cannot locate the WDS server; therefore it’s not able to get the boot files. The client ends up by displaying the “Error: PXE-E53: No boot filename received.” message.

My notes:

There are a lot of forums, blogs and guides regarding this subject on the internet. The problem is, every environment is not the same and there are a lot of “ifs” and “buts”. Although my findings will not only tell you what to do but if you try, they will also help you to “understand” how the PXE boot mechanisms are working… This helps immensely while troubleshooting.

It’s all about DHCP and broadcasts. I’ll not go into the deep details of the whole procedure but this is what is happening when a client tries to boot with PXE.

- The client will broadcast a DHCP request onto the network.

- Hopefully a DHCP server will get back with an IP address.

- The client will than ask for a TFTP server.

- If everything is well configured, your DHCP server will give the WDS servers ip address to the client.

- The client will than ask the boot files to the WDS server.

- Finally, your client has all it needs to boot onto one of your “boot images”

So, what could possibly go wrong in my environment? I knew I could just fill up the option 66, 67 and option 69 on my DHCP server and this would help the clients to learn about the image file location and the WDS server IP address, but there are limitations. By using these options, you cannot setup multiple boot files so you will have to setup either X64 or X86 boot file for all your clients. See the link below for more information;

http://wiki.r1soft.com/display/CDP3/Configuring+DHCP+Server+on+Windows

http://blogs.technet.com/b/dominikheinz/archive/2011/03/18/dhcp-amp-pxe-basics.aspx

Of course, I wanted to do configure this properly so I extended my research a little bit and that’s when I found out that I could probably resolve this issue by a couple of command on my layer 3 switch.

Resolution:

So I began to looking all the options related to a DHCP, broadcast, tftp or udp on my vlan configuration. I then realized that the only ip helper-address was the ip address of my DHCP server. This is good because it helps all the clients on the VLAN 8 to get an ip address from the DHCP server which sits on the VLAN 1. I added the ip address of the WDS server too because I tought it needed the ip helper-address to find the TFTP broadcasts… And bingo!

Just configure your core switches with the ip helper-address of your WDS server too and you won’t need to modify any configuration on your DHCP server.

What is funny is that, when you go trough all these blogs and forums, everyone is saying a different thing. And usually, people who figured out the ip-helper trick are working with a dedicated network team. If you manage pretty much everything in your environment and you don’t have anyone to hold on… Well, sharpen all of your skills and be ready! There is no other magic.

As usual, here are a couple of links that I found very useful during my researches. I strongly recommend you to have a look to these links.