PXE with IP Helpers/DHCP Relay

[pmj000001]

I'm a Sysadmin and I have a question about what is best practice in regards to PXE servers. We are currently using DHCP Options for PXE clients (options 66,67). This works for most clients but is not the recommended method from either of the vendors we have used (Microsoft or Symantec). They recommend using IP Helpers / DHCP relay to forward the DHCP discover request to the PXE servers so that the PXE server is getting the actual request. This is more of an issue now with UEFI-based machines where the boot file would be different based on if the client is UEFI.

My Network team is against using IP Helpers and thinks it can cause issues. This doesn't seem to make much sense to me, as from what I understand, all that happens is both the DHCP server and the PXE servers get the DHCP discover and respond with their relevant info. Can someone clarify what, if any, issues there are using multiple IP helpers/DHCP relay with PXE Servers like SCCM & Altiris? Is this not standard practice?

[ghostinthenet]

It's very common to use DHCP relays (IP helpers) in order to centralize DHCP infrastructure. Larger organizations will frequently use this approach in order to avoid having to manually edit DHCP configurations at the router or switch level. Having a few servers with a central DHCP configuration for all segments is a good management proposition.

In most environments, there isn't a problem with doing this, but it is a major architectural consideration and not something you just turn on without consideration. This is largely because DHCP works on a broadcast principle. The clients are going to broadcast for the first DHCP server that answers with an acceptable offer, which they will take. If you have a mixture of local DHCP servers and relays, the local servers will respond faster and may not provide the configuration you want to deploy... at best. At worst, you will have a mix of acceptable responses and a lot of potential for conflicting addresses. On any network segment where you're using DHCP relays, the local server needs to be disabled.

It might be worthwhile going back to your network team and asking what sorts of "issues" that they feel the implementation of DHCP relays would cause. There may be something unique to your environment that makes them reluctant to pursue this approach.

[pmj000001]

Thanks for your response. Keep in mind, we already have a single central DHCP server and a central PXE server, there are no local servers and we're not talking about adding more DHCP servers.

The question is just is there some inherent danger in adding an IP Helper/DHCP relay going to the PXE server as well as the central DHCP server instead of using DHCP options?

I have asked for more specifics but really haven't gotten any yet.

[ghostinthenet]

Ah, okay. This comes back to the broadcast nature of DHCP then. Unless you plan to have a dedicated network segment for PXE, it makes sense to leave DHCP where it is and not on the PXE server. As long as the file requests are terminating on the PXE server, it doesn't matter where the DHCP information is sourced from, so long as the options are correct.

[pmj000001]

Yep, DHCP is staying where it is, I only want to add.

My request was just to have an additional IP helper added for the SCCM PXE server, as per Microsoft's instructions. I understand you can have many IP helpers and this is the normal way to add PXE-based imaging servers.

The problem with using the DHCP option 67 is it has to be a static file name, and depending on if it's a normal BIOS or UEFI, there would be a different boot file, hence the need for the PXE server to get the actual request.

[ghostinthenet]

Here we run into the same problem with broadcasting. With the additional helper, there's a semi-random chance that the DHCP request will be answered by the PXE server or the primary DHCP server. If it's answered by the first one, PXE works correctly. If it's answered by the second, PXE fails.

You could change the IP helpers to point only to the PXE server and then rely on the server to redirect requests that it isn't prepared to handle, which is what I believe Microsoft recommends... but that puts why PXE server in the position of being a single point of failure, unless you have more than one of them. This may be what your network team is concerned with.

If your DHCP server supports conditional options, like the ISC DHCP server does, you can always have different option 67 responses for BIOS and UEFI clients, but I'm uncertain as to whether Windows Server's DHCP server has this functionality.

[pmj000001]

Ok, haven't heard of that. From what I read, the client would get both offers back and get it's IP from the DHCP server and respond to the PXE server after (described here, but the example isn't with ip helpers).

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

As to the conditional options, that may be an idea I can have them check into.

[ghostinthenet]

Very cool, I wasn't aware that PXE clients would reject anything that didn't include an option 60. Thanks for the reference.

That covers the PXE clients, which is good... but doesn't cover the non-PXE clients. Those will happily accept an offer whether it contains option 60 or not, so we still run into the problem of the DHCP server on the PXE server handing out addresses to client at large.

Of course, if the DHCP server on the PXE server isn't configured for dynamic pools and only hands out addresses for clients that are pre-configured, that solves that problem and eliminates barriers to having multiple helpers in play.

The network team may be a bit concerned with how the additional DHCP server is configured, because it has a lot of potential to mess things up if it isn't done right.

[pmj000001]

The PXE servers don't do any DHCP or giving out IPs, that's still left to the main DHCP server. They're only responding with their own info of the boot file info and such.
 

[ghostinthenet]

DHCP is a core component of PXE and is what provides the options for network booting. If the PXE servers aren't replying to DHCP requests, then the clients have no way of getting the server or boot file options and IP helpers wouldn't do anything.

In this case, it is more likely that the PXE server is doing a DHCP offer that does not contain an IPv4 address, but only the network boot parameters. If this is true, it will get the network address lease from the offer presented by the DHCP server and the boot server and filename from the PXE server. Having IP helper addresses to both servers in would work well in this case.

Still, I can still see the network guys being a bit twitchy because they're trusting that the PXE server isn't handing out more than it should.

[pmj000001]

Yes sorry, you stated it more eloquently than I did. Yes, it is using the DHCP protocol but not giving any options but the boot settings.

[ghostinthenet · Accepted solution]

So... going back to the beginning. IP helpers are a reasonably standard practice in larger organizations. Having IP helpers to additional servers for PXE deployment is a little bit different, but not too far out in left field. As long as there's no situation where there are DHCP servers arguing with each other about IPv4 address leases or network parameters, I can't think of any problems that this might cause.

[pmj000001]

Thanks for your help.

[jp.briggs]

I know this is ludicrously old, but we're running into a similarly veined issue here. I've done testing, and opened a TAC, but am still awaiting answers.

We've tested with dual ip helpers as outlined in this thread. One 'server' is a secondary IOS switch with a DHCP pool configured for the first switch's SVI, but no boot options. The second helper points to the MDT/PXE server, which does not issue addresses, but only replies with boot information.

This works fine. But this was only a test to prove out the point that dual helpers works. Now cut to the current issue.

Our environment is currently set up with a routed access layer, with DHCP pools on the access switches. I've configured an SVI (which has a local DHCP pool on the switch) with an ip helper pointing to the MDT/PXE server. No dice. I see the DHCPOFFER come back to the client from the switch with the next-server set as the MDT/PXE IP, but the original DHCPDISCOVER from the client never reaches the MDT server; it never leaves the originating VLAN.

No, there are no ACLs blocking it. In a DHCP ACL packet debug I was seeing a FIBipv4-packet-proc error of 'packet routing failed' right after receiving a broadcast (I'm assuming the DHCPDISCOVER), but I'm not sure if this is pertinent. 

In theory, I am trying to accomplish the same thing: get IP/gateway/name-servers/etc from one device (in my case, the switch's dhcp pool), and getting PXE boot information from the other (MDT/PXE server). When the former is ANOTHER IP address off the local switch (even if it's another IOS dhcp pool) rather than the local switch it works - as an IP helper. But not when the local switch is performing the DHCP service. Frustrating.

[ghostinthenet]

We may be dealing with a conflict between the IP helper and having a local DHCP pool on the switch itself. If the switch is expecting to service the subnet directly, the packet may never be forwarded, which lines up with the FIB error you're getting.

This isn't ideal, but what happens if you put the PXE-specific options in the local DHCP pool on the switch? That should be enough to get the clients to initiate TFTP connections to the PXE server.