Wireless Access

 View Only
  • 1.  AP boot process

    Posted Oct 22, 2020 01:20 PM

    Hello,

     

    I _think_ I know the answer to this, but I'd like to be sure. We have DHCP option 43 configured to supply the cluster address to APs. But we may shortly have a situation where we want some of our APs to talk to a separate cluster. If we provision those APs before we send them out to a location, into a group with a provisioning profile that has the new cluster address will they use that address in preference to the DHCP option?

     

    Thank you



  • 2.  RE: AP boot process

    Posted Oct 22, 2020 01:25 PM

    How is it supposed to work:

     

    - Device finds a controller via DNS, dhcp option 43 or multicast

    - Regardless of the controller the AP finds, the AP-group lms-ip address will point to an ip address of an MD in the desired cluster.



  • 3.  RE: AP boot process

    Posted Oct 22, 2020 01:49 PM

    Thanks Colin,

     

    So are you saying that the AP will talk to the 'old' cluster address that it receives via DHCP, and only talk to a different cluster if it subsequently receives config (LMS IP or prov profile) from that cluster pointing it to the new cluster?

     

    So would we configure a group on the existing cluster with a different provisioning profile/sys profile LMS address which points the AP to the new cluster? The AP would come up on the existing cluster as normal, and then be moved to the new cluster by that method? That could be fine I guess, it just wasn't quite how I was picturing it.

     

    I was imagining a scenario where the AP would never talk to the existing cluster, it would just come up on the new cluster, but perhaps that's not the way to do this, or even possible.

     



  • 4.  RE: AP boot process

    Posted Oct 22, 2020 03:14 PM

    AFAIK in an ArubaOS8 cluster design (managed by an Mobility Master) the LMS IP is superseded by the cluster node list that's pushed in the AP flash. 

     

    A new AP will find the master IP statically configured or via a DNS, DHCP Option 43 or through multicast or broadcast replies. An MC sends the AP its name and group as well as the LMS IP. The LMS IP could be an MC or a cluster of MCs.

     

    An AP that is part of the network and then disconnected due to power failures, or taken out of the network and placed on a shelf, will always remember the following: name, AP group, master IP (if the AP was statically set with an IP address), backup_va_init master IP, server IP or node list.

     

    AP bootup to a cluster:

    1.  AP learns cluster node IP addresses
    2. AP store addressess in a Node list
    3. Node list is saved as Environment variable
    4.  AP contact fist the IP address in node list upon boot up
    5. AP tries next IP address in case of no response.


  • 5.  RE: AP boot process

    Posted Oct 22, 2020 03:53 PM

    @cauliflower wrote:

    Thanks Colin,

     

    So are you saying that the AP will talk to the 'old' cluster address that it receives via DHCP, and only talk to a different cluster if it subsequently receives config (LMS IP or prov profile) from that cluster pointing it to the new cluster?

     

    So would we configure a group on the existing cluster with a different provisioning profile/sys profile LMS address which points the AP to the new cluster? The AP would come up on the existing cluster as normal, and then be moved to the new cluster by that method? That could be fine I guess, it just wasn't quite how I was picturing it.

     

    I was imagining a scenario where the AP would never talk to the existing cluster, it would just come up on the new cluster, but perhaps that's not the way to do this, or even possible.

     


    A new AP will discover a controller using whatever method, DNS, DHCP option.  If there is no LMS-IP in the AP group, it will stay on that controller/cluster.  If there is an ip address in the LMS-IP in the ap-group, it will immediately go to the controller/cluster at that ip address.

     

    The big question is, why would you want to redirect an AP to a foreign cluster?  DHCP option 43 was built to direct an AP to its nearest local cluster when DNS is not specific enough....



  • 6.  RE: AP boot process

    Posted Oct 22, 2020 05:33 PM

    It's a bit messy unfortunately. The current problem is that we are having issues with a particular series of AP (5xx), this may be fixed by an upgrade... but we still have 1xx series APs out there and these will not be supported on the new firmware (8.7). So we may have to split off sites  that have 5xx series APs and run those on a different upgraded cluster (or we might take the reverse approach and split off sites that still have 1xx APs and upgrade the main cluster instead).

    The plan isn't finalised yet, we have a meeting with an Aruba engineer tomorrow so hopefully the way forward will be clearer then.



  • 7.  RE: AP boot process

    Posted Oct 22, 2020 05:58 PM

    Maybe an option to re-provision an AP and set the (vrrp) cluster IP as static, on reboot it wil static lookup for your other cluster. Note. create the same AP group name on both clusters.

     



  • 8.  RE: AP boot process

    Posted Oct 22, 2020 06:22 PM

    Ok so I think I understand from what you have both said. Using a provisioning profile will statically set the cluster address as the 'master IP' so even on a reboot the AP will only talk to that cluster (it will ignore the DHCP option). We would also set the LMS IP* in the system profile to be the new cluster. That should keep them from trying to talk to the existing cluster (which will be on different firmware - in the case of the 5xxs we don't want them to talk to old firmware because we would see the problems return, and in the case of the 1xxs we wouldn't want them to talk to the new firmware because they aren't supported on it.

     

    The two clusters are actually under the same branch on the MM so the AP groups etc are replicated on both. We'll have to make sure we make any changes at the right level in the hierarchy so that only the APs we want to configure are affected.

     

    *Although by the sounds of it the node list may make this redundant anyway