Image being downloaded from the K2000, not the RSA.
I have an SDA installed at a remote site. The only accessible DHCP server at the site has its scope configured so Option 66 was for the local SDA.
When deploying a scripted install we notices that the deployment was incredibly slow. While the image was deploying we ran a CTRL+ALT+DEL to bring up Task Manager and opened another command window to see where the drive letters were mapped. The drive mappings were pointed to the main K2000 at the home office, not the local RSA. We also only sync select scripts to the local RSAs at each site, however at this site the tech mentioned that they were able to see all the scripts.
Is there a setting that would cause the remote RSA to redirect the local clients back to the main K2000?
-
Have you synced and replicated the scripted install from the main SDA to the RSA? - akmagnum 5 years ago
-
It shows that the 2 scripted installs are complete. Because of the speed of the connection to the remote site it did take almost 24 hours to sync out and I did run the first test image about 30 min after the sync completed. Maybe I will wait for another sync to run tonight. - JordanNolan 5 years ago
Answers (3)
You have two options:
1. setup a DHCP server on the remote site (the RSA has one on board if it is sufficient) and let it handle the remote site
2. build your own KBE for every location where the IP/DNS name of the SDA/RSA is hard coded.
You can use the KBE manipulator to manipulate these settings
Comments:
-
Sorry, I may not have been clear. There is a DHCP server at the remote site and it is pointing to the correct RSA. I just meant to say that the site was definitely not getting DHCP from anywhere else.
Non of the other remote sites have this behavior. - JordanNolan 5 years ago-
That DHCP or a Rogue DHCP is sending the devices to the main SDA.
OR
The devices are unable to reach that Remote Site, and they are using the main SDA IP as fallback - Channeler 5 years ago-
Having option 66 and 67 configured and pointing to the to the main K2000 would be very unlikely. When I was checking where the drives were mapped during the scripted install I did and IPCONFIG and verified it was using my DHCP and that 66 and 67 were pointing to the correct RSA.
I know the K1000 has a "fall back" setting if the local share is not reachable, but does the RSA have this for the K2000? That would explain it. Where is this setting located? - JordanNolan 5 years ago -
"Having option 66 and 67 configured and pointing to the to the main K2000 would be very unlikely"
Negative there, that could be the cause, your DHCP on that RSA's network or a Rogue DHCP over there, is forwarding iPXE attempts to the main SDA, double check your option 66 only.
Also, go to the main SDA logs, Settings > Logs > File Servers, Open the TFTP transfer Log.
That log audits any incoming iPXE request from a DHCP, there is one for each appliance (SDA and RSAs).
Do you see any device IP address from the RSA site?
Same applies to the TFTP log located in the RSA, it should show your iPXE boot attempts there at the RSA office, not in the main SDA TFTP logs.
Unfortunately, there isn't an option to do that, the KBEs remember the IP were they were born, if the RSA is unreachable, they will automatically reach their "mother" as fallback.
Unless you create a Static IP KBE with KBE Manipulator - Channeler 5 years ago -
OK, so since the DHCP on the remote site with the RSA is definitely pointing to the RSA and no other DHCPs are reachable over the WAN, it must be falling back to the main K2000 for some reason.
I am going to try putting in a firewall rule that only allows the RSA at the remote site to speak to the main K2000. No clients at the remote site should be trying to access it directly. I will see if this prevents clients from trying to access the main K2000 - JordanNolan 5 years ago -
@JordanNolan
Review your RSA's TFTP Transfer Log, make sure the DHCP RRQ -request-- attempts are registered there, check the IP and time stamps.
If that TFTP log is idle, or doesn't show your PXE attempts, your DHCP is not contacting that RSA , but the main SDA. (formerly known as K2000) - Channeler 5 years ago
Are you on version 6 of the k2000.
Have you updated your dhcp option 67 to the latest string on your remote site dhcp.
As you can find in the release notes, if you are trying to boot with PXELinux which was retired with 6.0 (and only as alternate since 4.0) in favour for the much faster (usually 2-4 times), more reliable and more secure iPXE.
Just a hunch , but refer to this article....
So .........if you have updated to the latest version.........
and....... if you haven't updated the remote site dhcp settings......
then maybe your devices are trying to pxe boot into your remore site dhcp settings , and failing........thereby failing over to the main SDA.
Comments:
-
I am still on version 5.1. I am using K2000.0 as the boot file. We did not get any errors. - JordanNolan 5 years ago
Comments:
-
I never had to build a site specific KBE for any of the RSA's I have deployed. Should that be necessary? - JordanNolan 5 years ago
-
I have never had to build site specific KBE's either. Just replicating them from the main SDA to the RSA should do it. - akmagnum 5 years ago
