IP Helper Equivalent for PXE Boot

  • 10 February 2016
  • 9 replies
  • 2275 views

Userlevel 1
We are interested in setting up PXE boot across multiple subnets in our environment, for client imaging. With, e.g., a Cisco switch, the typical approach would be to set up an IP Helper to forward PXE broadcast packets across subnets to the PXE server. What would be the equivalent way to do this on an Extreme switch?
  • The only thing I can find that seems related are bootprelays, but they sound like they are specific to DHCP forwarding. Would these be usable for forwarding PXE traffic as well?
  • We already have booprelays set up for DHCP, so any solution would have to not interfere with the current setup.
If anyone has insight into the best approach to this, I would appreciate it. We are currently running a X670-48x stack for our core, and X440's for our edge switches. Thanks!

9 replies

Userlevel 1
Setting up a UDP profile could be the solution.
Userlevel 4
Matthew,

I believe PXE packets will look like BOOTP packets on the network (same as DHCP). In this case bootprelay should make this work. If it does not fully work with bootprelay, UDP Forwarding would be the next option.
http://documentation.extremenetworks.com/exos/EXOS_All/IPUnicast/t_configure-udp-forwarding.shtml
Userlevel 3
PXE booting is bot like bootp, PXE uses several protocols, one of which IS BOOTP. PXE is simply an extension of DHCP options, which then tells the client where to get it's image/config via TFTP.

So you would need to set up bootprelays, but if you already have them, you just add the additional options to your existing DHCP server. if a client does not PXE boot, then it will just ignore those DHCP options.

This is switch independent, and you would only want to turn this option on, on the subnet's default gateway or whichever device handles the routing.

https://en.wikipedia.org/wiki/Preboot...
Userlevel 5
Hello Matt,

It's been some time since I boned up on PXE but I like Matt H's Preboot link at wiki.

There's a section on integration that paints a picture of PXE sliding right up next to DHCP in an operationally stable but somewhat locked-down network. Their term (current terminology I guess) for this DHCP redirection: "proxyDHCP".

The way I read this - two different independently admin'd services and a two step process. PXE client still gets an IP address etc as with any dhcp client. The proxyDHCP then supplies tftp ip addr and bootstrap info.

The simplicity is appealing, risk appears low and the content seems a tailor-made solution your initial query.

That's neither the experience nor the insight you were looking for at thread start, but I had that happy moment of 'damn, that's great idea' that compelled me to respond if only to keep ideas rolling.

Shamelessly borrowed Wiki content follows. Its not all the puzzle pieces but it covers lots of ground.

Best,

Mike D

Integration
DHCP vs proxyDHCP Server

The PXE Client/Server environment was designed so it can be seamlessly integrated with an already in place DHCP and TFTP server infrastructure. This design goal presented a challenge when dealing with the classic DHCP protocol. Corporate DHCP servers are usually subject to strict policies that conspire against easily adding the additional parameters and rules required to support a PXE environment. For this reason the PXE standard developed the concept of DHCP redirection or "proxyDHCP". The idea behind a proxyDHCP is to split the PXE DHCP requirements in two independently run and administered server units:

  1. The classic DHCP server providing IP address, IP mask, etc. to all booting DHCP clients.
  2. The proxyDHCP server providing TFTP server IP address and name of the NBP only to PXE identified booting clients.
In a DHCP plus proxyDHCP server environment[ the PXE client initially broadcasts a single PXE DHCPDISCOVER packet and receives two complementary DHCPOFFERs; one from the regular non PXE enabled DHCP server and a second one from the proxyDHCP server. Both answers together provide the required information to allow the PXE client to continue with its booting process. This non-intrusive approach allows setting a PXE environment without touching the configuration of an already working DHCP server. The proxyDHCP service may also run on the same host as the standard DHCP service but even in this case they are both two independently run and administered applications. Since two services cannot use the same port 67/UDP on the same host, the proxyDHCP runs on port 4011/UDP. The proxyDHCP approach has proved to be extremely useful in a wide range of PXE scenarios going from corporate to home environments.
Userlevel 1
For anyone interested, adding an additional ip to the bootprelay, pointing at the PXE server, was the solution to this. We were initially concerned this might cause issues with DHCP, but that seems to not be the case - the relay just fowards to both ips and the PXE server ignores regular DHCP traffic. Thanks everyone for your help!
Hi Matthew,

Late reply on this, but do you recall if you just simply added an additional line like so to have two total?:

configure bootprelay add 172.25.1.1 vr VR-Default
configure bootprelay add 10.16.1.1 vr VR-Default

Where 172.25.1.1 represents the DHCP server and 10.16.1.1 represents the PXE server? Anything additional needed on the specific vlan where the PXE clients are located?
Userlevel 1
We have been configuring this on a per vlan basis on our core switch, so our config for a vlan looks like:

code:
configure bootprelay vlan "GHN" add 172.16.1.31

code:
configure bootprelay vlan "GHN" add 172.16.1.29


I have not tried configuring both relays on the vr only, so I can't confirm that would work, but I don't see why it shouldn't.

One thing to note is that configuring a bootprelay on a vlan causes the switch to completely ignore the default config on the vr for that vlan. So e.g. you can't configure the relay for your dhcp server on the vr and then add just the pxe relay on a vlan - you have to add both the dhcp and pxe relays.
Thank you for the quick reply. I did try it on the VR, so I will try it as you described and see if I have better luck. I appreciate the response.
Userlevel 1
No problem. For further reference, show bootprelay configuration on our switch gives the following for the vr and the vlan:

DHCPv4 BOOTP Relay : Enabled on virtual router "VR-Default"
Include Secondary : Disabled
BOOTP Relay Servers : 172.16.1.31
DHCP Relay Agent Information Option: Enabled
DHCP Relay Agent Information Check : Disabled
DHCP Relay Agent Information Policy: Replace

VLAN "GHN":
BOOTP Relay : Enabled
BOOTP Relay Servers : 172.16.1.31 172.16.1.29
DHCP Relay Agent Information Option: Disabled
DHCP Relay Agent Information Check : Disabled
DHCP Relay Agent Information Policy: Replace

Reply