Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements
Webcast-Catalyst9k
New Member

PXE with IP Helpers/DHCP Relay

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?

1 ACCEPTED SOLUTION

Accepted Solutions

So... going back to the

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.

16 REPLIES

It's very common to use DHCP

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.

New Member

Thanks for your response.

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.

Ah, okay. This comes back to

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.

New Member

Yep, DHCP is staying where it

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.

Here we run into the same

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.

New Member

Ok, haven't heard of that.

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.

 

 

Very cool, I wasn't aware

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.

New Member

The PXE servers don't do any

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.
 

DHCP is a core component of

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.

New Member

Yes sorry, you stated it more

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.

So... going back to the

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.

New Member

Thanks for your help.

Thanks for your help.

New Member

I know this is ludicrously

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.

We may be dealing with a

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.

New Member

This will work for the most

This will work for the most part, but like I mentioned in my original post, you need the PXE server to see the actual request and not use DHCP options for imaging UEFI machines (of course on many PCs you can switch them to legacy/BIOS compatibility, but Surfaces and other machines are only UEFI).

New Member

Nothing is "ludicrously old"

Nothing is "ludicrously old" if it keeps coming up and biting you in the a**... Was having the same problem lately with where to place the IP helpers command. We have local Cisco DHCP servers provided by routers (3945s) where the VLANs are described/SVI'd (no VTP here). I was putting the "ip helper" statement on the SVI interface, at the router ... which is not where the initial client broadcasts are being received (which is at the switch).

We had been trying to get SCCM client provisioning (imaging) going for a while, with client and SCCM on different subnets, and DHCP being offered on the local client subnet.

Was getting nowhere until I discovered that the "ip helper" statement had to be on the SVI interface (pointing to SCCM address, on a different subnet/VLAN) on the switch ... Maybe you guys already knew this, but it took me a couple of days.

In summary:
- DHCP requests on/from router, servicing the to-be clients, on a switch;

- SCCM on different VLAN/subnet;

- "ip helper-address" on the VLAN definition, on the client-facing switch, pointing to the IP address of the SCCM WDS server;

BTW - still didn't work (machine gets an IP, downloads and runs the PXE boot, then requires "authorization from WDS), but now a Windows server admin issue, and off my book ... :-)

15543
Views
5
Helpful
16
Replies
CreatePlease to create content