Wireless Access

last person joined: 13 hours ago 

Access network design for branch, remote, outdoor, and campus locations with HPE Aruba Networking access points and mobility controllers.
Expand all | Collapse all

Best practices for AP failover

This thread has been viewed 9 times
  • 1.  Best practices for AP failover

    Posted Feb 27, 2015 11:58 AM

    Hi all,

     

    I'm working through the different AP best practices for failover, trying to determine the most optimal one for my environment. In terms of my environment we deploy our controllers in a master/master-backup with no locals.

     

    - Assign each controller an IP, and assign an IP from the same subnet for the VRRP. Configured on my DHCP server, the VRRP ip which is pushed to the client when they boot and request a DHCP address. In the AP system profile in the LMS ip address configure the VRRP ip address. As far as I understrand this is a valid way of providing HA to the AP as if the master was to die the AP would remain up and online as it has associated with the VRRP ip.

     

    - Use HA Fast Failover, I am unsure about this method. I've read in the docs that in 6.4 you can use it in my deployment model. What I'm not sure if how the AP gets the master controller IP address? I know you configure the HA group, configure the two controllers in the group with the controller-ip. What I'm not sure about is how the AP would get an ip address if it wasn't L2 adjacent to the controller. And if it was to be given an ip address by the DHCP server, i.e. the master, then if the master was offline, the AP rebooted and DHCP told the AP to use the offline master, then the AP would not associated with the controller.

     

    Hope this makes sense? Any advice would be much appreciated :)

     

    Cheers



  • 2.  RE: Best practices for AP failover

    Posted Mar 03, 2015 03:36 PM

    from what i understand VRRP is still one of the fastest and perfectly valid AP failover method.

     

    in my opinion the HA fast failover is more for a situation where you can't have your controllers do VRRP so you need something quicker then the LMS / LMS BACKUP IP system.

     

    as for how to get that working you seem to focus to much on a setup where the controller does all kind of things like hand out IPs to the IPs and be on the same subnet. APs can discover the controller also via DNS and DHCP option. in that case the APs can get IPs from some other DHCP server and just need an IP to connect to to setup their tunnel. with AP fast failover they will have two tunnels once they have been on the first controller once and the config has been found.

     

    if you have any further question do let me know.



  • 3.  RE: Best practices for AP failover

    EMPLOYEE
    Posted Mar 03, 2015 03:50 PM
    HA AP fast failover is recommended at this point and offers failover times of 1-2 seconds.


    Thanks,
    Tim


  • 4.  RE: Best practices for AP failover

    Posted Mar 03, 2015 04:25 PM

    what is the failover time for VRRP Tim? isn't it pretty much instant either?

     

    why would HA fast failover be preferred? from what i read it also doesn't support fail over for RAP and bridged forwardig.

     

    and this is also still in the 6.4 guide: "High Availability:Fast Failover providesredundancy for APs, but not for controllers. Deployments that require master controller redundancy should continue to use an existing VRRP redundancy solution."

     



  • 5.  RE: Best practices for AP failover



  • 6.  RE: Best practices for AP failover

    Posted Mar 04, 2015 03:27 PM

    thank you victorfabian. for me that just confirms what i said, for master-master backup VRRP is the way to go. for master local AP fast failover can be useful if it fits with your deployment.

     

    if there are other opions please share them with arguments, just stating AP fast failover is recommended without a reason or any aruba reference is confusing.



  • 7.  RE: Best practices for AP failover

    Posted Mar 11, 2015 04:39 PM

    Thanks for all the advice guys, all really useful. In my particular situation we will be continuing to use the VRRP IP as the LMS IP. It works well in my environment and is defined in the 6.4 user guide so I'm happy with this choice. Cheers



  • 8.  RE: Best practices for AP failover

    Posted Apr 14, 2015 04:01 PM

    Ok, it's a month later and it looks like some changes have been made or new configurations are supported in 6.4.2.5.

     

    I plan to configure (2) 7205's as Active/Standby and use VRRP.

    Additionally, I plan to use AP Fast-failover.

    My understanding is that:

    - Configure the controller(s) IP address in the HA profile (and not the VRRP IP)

    - Do not enter an address in the ap profile for LMS/BLMS fields

    - Ensure that there is a DNS entry for "aruba-master" pointing to an "active" controller IP.

     

    My concern is the term "active" controller IP if I'm running Active/Standby? Is the solution (2) DNS entries?

     

    Let me know if clarification is needed.

     

    Thanks!

     



  • 9.  RE: Best practices for AP failover

    Posted Apr 14, 2015 05:03 PM
    The DNS entry should pointed to the Active controller in the HA group


  • 10.  RE: Best practices for AP failover

    Posted Apr 14, 2015 05:17 PM

    So, if the configuration is Active/Standby...the DNS entry should point to the Active controllers IP. But what if the Active controller fails and now the Standby controller takes over? Is a DNS entry required for both controllers?

     

    Example:

    Active IP = 10.10.10.1

    Standy IP = 10.10.10.2

    If the DNS entry for "aruba-master" points to the Active controller (10.10.10.1), how does it work in a failover situation where the Active fails and is unreachable?

     

    Thanks!



  • 11.  RE: Best practices for AP failover

    Posted Apr 14, 2015 06:01 PM
    At that point the APs will have another GRE tunnel build to the standby controller


  • 12.  RE: Best practices for AP failover

    Posted Apr 14, 2015 06:09 PM

    Ahhh, I see. I read a little more as well.

    It will use HA before attempting to use LMS/BLMS.

    The IP's for the controllers are identified in the HA group.

     

    I believe that's how it works.

     

    Thanks for your help!

    -Herman



  • 13.  RE: Best practices for AP failover

    Posted Apr 15, 2015 03:04 PM

    Fast Failover seems like it only helps if the AP has already successfully booted from an active Master controller.  That doesn't address bootstrap failover at all.

     

    They way I see it -- and someone please chime in if I'm wrong, because I probably am -- you have two options for boot-time failover:

     

    1) Use VRRP between two controllers in a layer-2 domain.  They may as well be in an HA group as well, so you also get Master role redundancy.  You can assign this VRRP IP to the LMS field in the profile, as a DHCP option, as a DNS A record for "aruba-master", or leave it to ADP to discover.

     

    2) Use LMS / Backup-LMS to point to two different controller IPs.

     

    I've been testing the latter option, and so far it doesn't seem to work ... at all.  If the AP's home controller goes away (pull the data cable), the AP shuts down the radios, and the power LED blinks.  It does this for about a minute or two, then reboots.  At this point, it can't find its controller via ADP (the BLMS is a few layer-3 hops away in my case), and just reboots itself perpetually.

     

    So, when exactly is the BLMS IP supposed to kick in?  It doesn't seem like the AP-105 bothers to attempt to connect to the backup controller after losing connectivity to its home controller.  It just waits for a while, then reboots.  And then, it doesn't have the BLMS setting in memory anymore.

     

    DHCP option 43 apparently only supports one IP, so that's no good.  You would ordinarily want it to go to the local controller.

     

    DNS supports multiple IPs, but is the order deterministic?  I.e., if I assign multiple A records with my preferred controller and at least one backup, how do I know it's going to try the preferred IP first?  Also, that doesn't seem to be a reasonable option when you have multiple sites, and want to give the local controller first dibs at each site.  That would require per-site DNS entries.  Wouldn't you normally just have, for e.g., a central AD server for internal DNS?



  • 14.  RE: Best practices for AP failover

    Posted Apr 15, 2015 06:05 PM

    What I planned to do was to use VRRP for the controller failover (which should take only seconds) and then to use HA groups so that the AP's build a second GRE tunnel and does not re-bootstrap. I am still trying to find out client reconnectivity time but assume that it depends on the load.

     

    In your setup: LMS/BLMS, do your AP's have static IP addresses or are you using DHCP? Have you consoled into an AP while it's booting to see where the error occurs?



  • 15.  RE: Best practices for AP failover

    Posted Apr 15, 2015 10:00 PM
    I would expect VRRP to take longer than a few seconds -- depends on the dead timer, but I don't see anything like instant failover on pings. Fast Failover might be a different matter.

    Mine are DHCP, with the server on the layer-3 switch(es, actually). I do watch the console... The AP says nothing when the home controller goes down. Nothing until it restarts, then it's just a normal boot procedure. Gets an IP and gateway, runs ADP, and "Master is 0.0.0.0", then it reboots again.


  • 16.  RE: Best practices for AP failover

    Posted May 14, 2015 01:10 PM

    Well, I found out what's breaking BLMS failover...  The controllers were running different AOS versions, which means they had different AP firmware versions.  By now, the problem should be apparent, but for those who aren't as familiar:

     

    When the AP fails over to the backup controller, the controller checks the firmware version of the AP and sees that it needs to be "upgraded."  (It might actually downgrade, depending on which controller has the higher version number, but the end result is the same.)  According to our rep at Aruba, the firmware upgrade procedure removes the AP's config, which means it must contact its local controller to re-provision itself.  Except, in this case, the local controller isn't there anymore, so it just reboots continuously, waiting for someone to claim it as a provisioned AP.

     

    Seems obvious now, but I didn't catch on while I was labbing this up.  (oops)  Hope this saves someone else some troubleshooting time.