Wireless Access

last person joined: yesterday 

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

Re: Internal Error when reprovisioning an AP

This thread has been viewed 4 times
  • 1.  Re: Internal Error when reprovisioning an AP

    Posted Jan 29, 2015 10:21 AM

    The data doesn't propegate from the local to the master, so changes made on the local do not report to the master. IPSec is up and the master and local do communicate with each other at least L2. All devices connect to an Alcatel Service router.

     

    Code version is 6.3.1.5 

     

    My running theory was there is a possible database issue with the controllers and is causing the master to not "find" the information when it comes to provisioning.



  • 2.  RE: Re: Internal Error when reprovisioning an AP

    Posted Jan 29, 2015 10:47 AM

    Hi,

     

    When we configure the master-Local, WLAN config, Firewall policies and local database will be shared with local ( also with the standby).

     

    In your case issue might be with master discovery. ensure the following,

     

    1. Disable ADP in both the controllers

    2. Use either DHCP option 43 or DNS for master discovery

     

    As a good practice, always specify the Master controller IP as the Master IP for all the APs and you can specify the Local IP as the LMS as required.

     

    Please ensure the above points are in place and try and please feel free for any further query on this.

     



  • 3.  RE: Re: Internal Error when reprovisioning an AP

    Posted Jan 29, 2015 02:18 PM

    That's the case.

     

    The problem is when you provision from group 3 which is that specific local controller 33. On the master, using the GUI, I can provision anything from any other group (1, 2, 4, 5, etc) but when we select an AP from group 3, it locks up and refuses to proceed.

     

    On the local .33 controller, I can easily provision no problem. I tested by reprovisioning one from group 3 to group 4. It shows up on controller 34 and the master 30. I then used the master to move it back to group 3 and controller 33. NO problem. But that AP no longer shows up on the master.

     

    We are trying to rename existing APs to conform to a new standard.

     

    TAC is currently searching as well.

     

    Thanks



  • 4.  RE: Re: Internal Error when reprovisioning an AP

    Posted Jan 30, 2015 04:34 AM

    Hi,

     

    Let me understand something here.

     

    1. When you say group 3 means, AP-Group 3 or are you talking about device group ( Airwave )

    2.Why and how can you provision APs with Local (As you said" On the local .33 controller, I can easily provision no problem" )

     

    Please clarify the above so that I can understand your issue and help.



  • 5.  RE: Re: Internal Error when reprovisioning an AP

    Posted Jan 30, 2015 08:39 AM

    My apologies:

     

    Our setup is a Master/Active/Local

    We have two 4704 controllers running the roles of Master/Standby (.30/.35)

    We have 8 Sup 3 controllers running local

    Each local has an AP group tied to the local. eg Group 1 to .31, 3 to .33 etc.

     

    On the local .33 controller's GUI, I can easily click an AP and provision it with a new name. It however doesn't sync. If I provision it to a new group, it will show up on the master. If I provision it back to the Group 3 controller, it will not update on the master.

     

    Trying to provision any AP that's in group 3 currently on the master causes a brief lockup and an internal server error.

     

    We are probably going to reboot the local soon to see if that corrects the miscommunication.



  • 6.  RE: Re: Internal Error when reprovisioning an AP
    Best Answer

    Posted Feb 06, 2015 05:21 AM

    Ok, so after contacting TAC, they indicated to upgrade the code, the customer wishes not to. So instead, we performed troubleshooting steps below:
    Fail the master over to the standby - Same problem

    Shut down the VRRP for .33, the APs then pointed to their backup local .38, rebooted .33 then turned the VRRP back up. This resolved the issue.