Hoping someone may have come across this issue before and can help...
We have a DNS record for aruba-master setup for our VRRP IP and have problems with AP's being discovered ready for provisioning (i.e. they dont appear under wireless installation / show ap database) on our master 3400 controller. They seem to eventually appear after hours of reboots. They do get an IP address (found via checking the MAC on the DHCP server) but do not appear to be discovered. However, when querying the traffic of the IP there is some UDP traffic connecting to the controller, so I assume the DNS discovery is working in part, but no PAPI ports or GRE protocol seen. The AP IP is 172.31.30.66 and the VRRP IP is 172.31.200.82:
Console output is in attachment (couldnt embed it for some reason).
I have a TAC case logged but am not getting anywhere fast. At the moment any new AP bought potentially is unusable (I know it can be configured manually, but they are dispatched to remote sites, so its not easy to configure).
Has anyone seen this before?
Appreciate any help.
It's seems AP'S Doesn't getting DHCP address as u think:
Take a look ----> DHCP timed out..Valid v6 ....
Does your ap's getting Address from any DHCP server?!
Did you pre configure static address to your new AP'S
Did u configure an assignment or a pool for the new AP'S?
Without IP address , there is no DNS resolving or any GRE tunnel building...
Hope it will give u some idea - on where your issue is.
Keep us update - if it helped u solved the issue.:smileywink:
The thing is - I am not sure if that error reflects the true situation. When you check the MAC against the DHCP server, you do see a lease. I initially thought it was a DHCP issue until I saw this. Also - as above, the fact that you can see traffic coming from the IP of the AP surley prooves that it does get an IP?
The console output below is one of a local AP I use to test, which doesnt always exhibit the same problem. The datapath session table is of a live AP (its brand new - no config) which I am not seeing under AP installation.
There are no firewalls in the way which could block any traffic.
Also - just to add, the AP seems to randomise the port number each time I refresh.
I do see port 69 mentioned which I think is TFTP - so I wonder if it is downloading the OS?
Thoese are the used ports (for CAP ap's)
And yes,port 69 is TFTP and the AP using it in order to upgrade is own OS to the same OS of the controller u are using - without this process or until this process will not be done / the ap will not boot.
if the AP does getting an IPv4 address as u wrote - and trying to esatblish an OS upgrade to itself,u should see in the the GUI of the controller under AP instaliision with a mark: upgrading ...and after a few second 20-35 u will see rebooting.
what AOS are u using?
I see nothing under AP installation or show ap database.
Also - I have run show log all | i 172.31.30.66 and show log all | i MAC Address
And I see nothing apart from me adding the MAC's to the RAP whitelist.
Why could there be the odd port numbers from the datapath session shown above?
I am using 188.8.131.52.
So your AP dosent connecting your controller at all. (if u arent seeing your ap in the ap installison page once in a while trying to upgrade themself or rebooting)
Start by seeing and checking (be sure) that u AP'S getting and IP (v4) and can establish a connecitivy to your controller- the best way is to take a laptop to the AP location and connecting your laptop to the same port - 1.check that u getting connectivity 2.check that u are able to establish a working traffic to your controller
(BTW: if your ap are behind other other Router NAT/WAN - over the internet ....GRE will not work!)
Agian - as it seems from the screenshots u sent - your AP'S arent getting an IP address.
check another thing
if you right - and the AP really got a working connectiviy to your controller - when the AP botting (and u connectd with console cable to it) u should see the same AOS version - in your case 184.108.40.206 ... if u see other version in your AP so your AP didnt success to connect at all to your controller. TIPS: <connectiviy problem!> <check ip,check trace,check ports>
The screenshot of the console is an old screenshot from a test AP I had here (not on our remote sites), so it may be that is a different issue.
Unfortunatly the site is not local so I am not able to easily check the OS / IP on the console.
The AP is in our WAN and so has no NAT or firewalling in place. The switches being used have a very simple VLAN configuration and are all using the same VLAN, so it is not likely it could be a VLAN configuration at fault.
Are there any more avenues I can explore as far as remote troubleshooting goes?
I cant understand how it gets an IP and is able to communicate with the controller but not complete the communication. If I am seeing TFTP traffic shoudl the OS download show in the logs?
are u using control-plane-secuirty? if so - u should whitelist thoese new AP'S
Slight update - but puzzling.
We have now plugged in another 5 AP's at our remote site to total 6. Two of the APs have now shown up.
The strange thing is - I have always been told by our Aruba partner to copy the existing whitelist settings, and for these two AP's, there were slightly different settings. From memory, for some reason I could not set all the 6 MAC's to the same settings.
The two which are working are set to factory-cert in a state of certified-switch-cert.
The others are factory certs, but a state of certified-factory-cert. I cannot seem to change the whitelisting to match the working two.
Could this be the issue?
I should note I have tried putting debug level logging on but see no 'rejects' as such which I would expect to see if the control plane security were rejecting AP's. Also - they are not RAP's yet, just brand new AP's.
They are also in the campus whitelist.
Interesting one - but surley proves the IP is valid...
I run a ping to the IP and I get no response, but the show datapath session table shows protocol 1 traffic in both directions - which is ICMP unless I am mistaken.
Virtual Router 20: Description Admin State UP, VR State MASTER IP Address 172.31.200.82, MAC Address 00:00:5e:00:01:14, vlan 1 Priority 120, Advertisement 1 sec, Preemption Enable Delay 1 Auth type PASSWORD, Auth data: ******** tracking is not enabled
Virtual Router 20: Description Admin State UP, VR State BACKUP IP Address 172.31.200.82, MAC Address 00:00:5e:00:01:14, vlan 1 Priority 110, Advertisement 1 sec, Preemption Enable Delay 1 Auth type PASSWORD, Auth data: ******** tracking is not enabled
RAP's ultimatly, but just hoping to see them as campus AP's in order to configure them. The only mention of the MAC in the logs was the user commands to add them to the whitelist
No - and no chaneg during TFTP traffic
As per previous post - we have plugged in 5 more AP's and now 2 of the 6 are working and provisioned as RAP's successfully.
Not easily - they are mounted on the side of a building, but as a last resort, I could try to arrange
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 2020 Hewlett Packard Enterprise Development LPAll Rights Reserved.