We have several sites that seem to have high latency since they are VSAT links, so we run into a problem with new APs connecting to a controller. Has anyone tried to store the tftp files on a device other other than the controllers so that APs can at least get the initial load so that it can then connect to a controller? Since I think the default is like 5 minutes for tftp fo the file with high latency the links are pretty slow and cannot get the download completed before the AP reboots and starts over.Does anyone have better luck with this. We have tried some things but to no real avail so far....i can go so far as seeing the APs connecting but you can tell that it is still just tftp'ing the initial load still...
The best practice in that scenario (unfortunately) is to stage the access points so that they at least get a base image before you send them out. The problem with new (factory) APs is that they use TFTP which is very, very inefficient, even over fast links; this is much worse over slow links. After the AP gets a base image, it will then upgrade after that with FTP, which is much faster and more efficient.If your process is to first stage the APs by connecting to a controller, getting the up-to-date code, naming them and sending them out, it will save alot of time and effort. It will ensure that the AP functions properly, you can name it and optionally give it a static IP address before sending it out. It sure beats troubleshooting an upgrade/wan issue, if you can make it happen.
Pre-staging gets the TFTP over slow links issue off the table. That said, a couple of thoughts if that is not possible:- First, TFTP taking a long time should not prompt the AP to reboot unless the TFTP retry count is reach for a specific packet, which indicates loss on the link instead of latency. I have seen some of these APs take upwards of 10~15 minutes for a TFTP upload...their was some loss and a lot of latency, but not a long string of lost packets. - Second, you can setup the AP to boot via TFTP to a TFTP server locally. To do so, you must set some environmental settings via the AP console. Specifically, if you set "setenv serverip " and "setenv bootcmd tftpboot", the AP will boot via the local TFTP server instead of contacting the controller for that code. BTW, this will involve you pulling the code from the controller and hosting this on a TFTP server. That said, because you MUST touch the AP to set these commands, and get the code off the controller and host on a TFTP server locally, it is generally easier to just plug the AP in and gets its code before deployment to the VSAT site. Once that is done, the AP will only download code when the controller code is upgraded and it will upgrade via FTP.
@bs4284 you would look at extending the heartbeat timers ('Bootstrap Threshold' in the AP system profile, default is 8 missed heartbeats, one per second. If your expected outage is 2min, you would want to try 120 as na example. That also means that it would be at least 2 min before the AP would reboot strap. There's no detection on if the tunnel flaps and you need to take an alternate path. But in most cases if you are doing vsat, you have one path :)
This is perfect for a setup I have.
However, now my question is how to extend the timers on the AP so it doesnt try to fail over if a EIGRP tunnel flaps on a VSAT link.
At Aruba, we believe that the most dynamic customer experiences happen at the Edge. Our mission is to deliver innovative solutions that harness data at the Edge to drive powerful business outcomes.
© Copyright 2021 Hewlett Packard Enterprise Development LPAll Rights Reserved.