/build/static/layout/Breadcrumb_cap_w.png

K2000: Unable to PXE boot clients from another subnet

Hello,

Our KACE2000 (192.168.0.2) is working great on it's local subnet, but we are having issues deploying systems in a branch office. This is what we have done:

The firewall in our main office (192.168.0.0/24) is allowing all ip traffic in both directions between the sites.

The router (192.168.1.252) in the branch office (192.168.1.0/24) are also the DCHP server for that location with the following configured options:

default-router; 192.168.1.252
dns-server 192.168.0.1 (dns server in main office)
option 66 ip 192.168.0.2
option 67 ascii kbox2000.0
 
 

However, as we PXE boot the clients and get IP etc, the following errors are ruining the fun.

PXE-E32: TFTP open timeout

PXE-M0f: Exiting Intel Boot Agent.

 

I've tried troubleshooting TFTP by using Telnet, but that doesn't even seem to "work" on the local subnet.

 

Any ideas?


1 Comment   [ + ] Show comment
  • Solved by workaround, read below - szo850 9 years ago

Answers (2)

Answer Summary:
Posted by: genfoch01 9 years ago
Orange Senior Belt
0

Top Answer

first I'd make sure the firewall is allowing UDP and TCP traffic as typically tftp uses UDP protocol

then I'd get on a machine on the subnet in question and see if I could pull data from the K2000 with the tftp client.

Windows machines  the tftp client needs to be turned on
 Linux machines may need to have it installed depending on the distribution

Assuming windows, open a command prompt   (turn off the windows firewall as it will block even outgoing tftp requests )
type :   tftp K2IP get netbootintel/i386/booter

Now you will either get a connection fail  or the command will complete and you will see a 500k file called booter in the directory you ran the command from.

if the connection fails,  run the same test on the subnet you CAN PXE boot from  (as a control) it should work there.
then investigate why the request is failing to cross your subnet.

While you are running this test, you should also test mount the K2000 samba shares to make sure there are no issues there as well.
          

Comments:
  • TFTP didn't work out for me, it returned the following. This was tried from the local subnet where PXE is working and no firewall exist.

    c:\>tftp 192.168.0.2. get netbootintel/i386/booter
    Error on server : File not found
    Connect request failed



    The Samba share is accessible from both sites. - szo850 9 years ago
    • well that looks like you did make a connection
      the response you got "file not found" is coming from the tftp server

      I gave the path for an OSX boot I am sorry about the confusion. go into your deployments > boot environments and open the detail page on any of your working KBE's. the URL at the top will have "boot_image_id=XX"

      as an example here is the url for the detail page of my default x64 kbe
      http://192.168.167.133/boot_environment_detail?boot_image_id=24

      so I will use 24 in place of XX in my examples :


      change the command to tftp K2IP get kbe00XX.iso
      it will take a little longer because its a 200 - 300 mb file

      example of a good response :
      tftp 192.168.112.110 get kbe0024.iso
      transfer successful : 258046340 bytes in 91 seconds

      example of a connection with a bad file name
      tftp 192.168.112.110 get badfilenamehere
      Error on server : File not found
      Connect request failed

      example if the tftp server can not be reached at all
      tftp 192.168.112.110 get kbe0024.iso
      timeout occurred
      connect request failed.

      so it looks like you did make a connection to the tftp server on the k2000 from its subnet.
      try it from your "bad" subnet - genfoch01 9 years ago
      • Ah ok, of course.

        Yes, it works fine from both subnets,
        C:\>tftp 192.168.0.2 get kbe0035.iso
        Transfer successful: 192132329 bytes in 180 second(s), 1067401 bytes/s

        Best Regards,
        Simon - szo850 9 years ago
      • So what can it possibly be? Something with the DHCP option 66 and 67 that isn't working as they should? - szo850 9 years ago
      • I would create a USB boot key (admin guide page 94 for K2 version 3.6 ) and see if you can boot the machine on the bad subnet with it. If you can, then go into "recovery" and open a command prompt and then run kgetdhcp 66 (which should return the IP of your K2000 ) and kgetdhcp 67 (which should return k2000.0 ) - genfoch01 9 years ago
      • I've created a USB boot key, that works fine on the main subnet. When I try to boot a machine on the bad subnet I get these errors.
        https://imageshack.us/download/539/KgBfkO.jpg
        https://imageshack.us/download/540/Nm2JRn.jpg
        https://imageshack.us/download/673/XtlSY0.jpg - szo850 9 years ago
      • From your screenshots it looks like DHCP option 66 is not setup/working correctly. It should be returning the IP of your K2000 and as you can see it is not. I'd start there.

        as another test, you could use KBE Manipulator
        http://www.itninja.com/question/kbe-manipulator
        to build a KBE with a hard coded IP for the K2000 (bypassing the kgetdhcp ). you would still have to load it to a usb key but if that works on your "bad" subnet the issue would for sure be limited to the DHCP option 66 setting. - genfoch01 9 years ago
      • Yes, after hard coding the KBOX IP with KBE Manipulator, I can successfully boot all the way into the menu. This is good enough, thank you! - szo850 9 years ago
Posted by: danwilsn 9 years ago
White Belt
0

Not a network guy but we had a similar situation our network guy resolved by entering a few commands into the switches/routers.(17 remote locations)

We were implementing Wake-on-Lan and ran in to the same limitation. I think he resolved it with an IP Helper Address.

May or may not work for you but here is a link that I think goes over the process. Good Luck.

http://www.ciscopress.com/articles/article.asp?p=330807&seqNum=9 


Comments:
  • Thanks. Not a network guy either, but I'm pretty sure that IP Helper is used during the DHCP discovery process, to help the PXE clients reach a DHCP server located on another subnet. In our case the remote router is supplying the remote PXE clients with IP's and that part seems to work out well. - szo850 9 years ago
 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ