Comware Based
1752780 Members
6126 Online
108789 Solutions
New Discussion

5500EI - program for PXE/TFTP on remote subnet

 
unclesid_1
Occasional Contributor

5500EI - program for PXE/TFTP on remote subnet

Problem:



We have a 5500-EI switch with 6 subnets, each defined by VLAN.  We have a single DHCP server, which we use UDP Helper to allow DHCP traffic to cross subnets, so clients on all VLANs can see the DHCP server.



We now have a Microsoft SCCM server which we're using to image via PXE boot.  The PXE server is on a DIFFERENT server than our DHCP server, so while the UDP-HELPER configuration points to the DHCP server, TFTP packets used for the PXE boot process cannot be directed to the PXE server as that address cannot be specified.



In reviewing the SCCM documentation, it appears that this is handled in Cisco switches by using 2 "IP Helper" entries - one would point to the DHCP server (UDP 67/68) and one to the PXE/TFTP server (UDP 69).



Any idea how we would configure this on our 3Com 5500-EI?  We're confined to imaging on just one of our subnets until we can get through this.



P.S. This seems to be a quirk of SCCM.  PXE boot worked fine with the same configuration to a FOG imaging server on a different subnet.



Thanks in advance for any thoughts.  I'm untrained on these things and switch administration is about 5% of my job, so I'm not real adept at it.



4 REPLIES 4
Fred_Mancen_1
Super Advisor

Re: 5500EI - program for PXE/TFTP on remote subnet

Hi.



The 5500 switches do support more than one DHCP Relay group, but only one group can be added to a VLAN interface.



It's possible to assign two IP addresses to the DHCP Relay group, but at the other hand you cannot group both IP addresses in the same group....If you could work with specific VLANs to each service, it will be the solution with one group to each service, and then assign these groups to the VLANs you need. But if you could not work this way, I really don't know how to do.



HTH



Regards,
Fred Mancen
unclesid_1
Occasional Contributor

Re: 5500EI - program for PXE/TFTP on remote subnet

Thanks for your response - it keeps us from continuing to pound our heads against the wall.



We'll simply image machines on the same VLAN/subnet as the imaging/PXE server - less elegant than we'd like, but it will suffice.



rafter_1
Advisor

Re: 5500EI - program for PXE/TFTP on remote subnet

Hi,



I use option 66 & 67 in the DHCP scope to get the PXE boot option to work.



66 Boot Server Host - (IP address)



67 Bootfile Name - OSchooser\i386\startrom.com



I can then be specific to which server these should get PXE from.  It works well.



Hope that helps



LewisRoberts
New Member

Re: 5500EI - program for PXE/TFTP on remote subnet

Anyone looking for the answer to this question will find good reading on Chapter 54 (Page 633) of the Switch 5500 Family Configuration Guide located: http://support.3com.com/documents/switches/5500/3Com_Switch_5500_Family_Configuration_Guide.pdf

 

To give you the finer points, if your DHCP and PXE boot (Windows Deployment Services or SCCM) servers are not one in the same box (why would they be!?), you simply add all DHCP and PXE server IP addresses to the same dhcp server group with a command similar to the following:

 

dhcp-server 0 ip 10.10.10.1 10.10.10.2

(In the example above, your DHCP server IP is 10.10.10.1 and your WDS/SCCM/PXE server is 10.10.10.2)

 

You add the DHCP server group to your VLAN-interface like so:

 

interface Vlan-interface100 (Creates the vlan interface if it didn't already exist)

description "My PXE VLAN" (Just a useful description, nothing more)
ip address 172.16.1.1 255.255.255.0 (Assign an IP address to the VLAN interface, this will be the host's default gateway)
dhcp-server 0 (The important bit! You tell the interface to forward all DHCP broadcasts to this dhcp server group, which is the group you created above)
That should be all you need to do. I use this myself with Windows Deployment Services and it works perfectly. Next task for me is multicasting images across subnets...I've no idea what that entails yet but I'll probably be blogging it sooner or later on lewisroberts.com
In essence, the first reply to the original post was correct, it just didn't supply the exact information required :)
The above method is also the "Microsoft recommended" solution instead of the unsupported option 66 and 67 route which is apparently somewhat unreliable - but if it works for you then ok!
Hope this helps!
Lewis