We have just installed a new controller, it's a test controller that is running in standalone mode but is in the same L2 domain as our current live controllers. It's a 7220 and we are running Airwave 22.214.171.124.
It has been added on Airwave and appears to be polling ok. But we see no client or usage data from it (no graphs) on the monitor page. The SNMP community string seems to be correct, and the Airwave server is added as a mgmt-server on the controller itself. Any ideas what might be missing? Or are there logs that might show where this is stumbling?
Yes these APs are in Airwave, there are 103 of them, all in the same group. This morning I moved them from one of the live locals to this test controller by changing the system profile for the AP group they are in to give them a new LMS address. They moved across fine and people at the site the APs are in have reported that they can connect ok (there are associations showing on the controller and traffic seems to be passing).
We have the following eval licenses that Aruba supplied so that we could perform the test (we will be upgrading the test controller to 6.5.1 shortly):
Hostname IP Address AP PEF RF Protect xSec Module ACR Last update (secs. ago)-------- ---------- --- --- ---------- ----------- --- -----------------------aruba-master-65 126.96.36.199 128 129 129 0 0 7
Total AP License Count :128Total PEF License Count :129Total RF Protect License Count :129Total XSEC License Count :0Total ACR License Count :0
If the APs do not show that they are assigned to the new controller, client statistics will not be reflected in Airwave...
Hmmm they are showing as being on the new controller. I'm just wondering whether this is indicative of something like (eg) SNMP is working but PAPI messages aren't making it for some reason? Or would we not be seeing the data that we are seeing in that case?
Is there anything else that needs configuring on the controller other than SNMP and mgmt-server?
We noticed that the new controller doesn't appear in the list of controllers under the 'Average PAPI packet loss' graph in the Performance section, could that be significant?
It turned out that we had seen something like this before, it's probably fixed in later versions of AOS, but I'll note it here in case anyone else comes up against it. The PAPI messages were not being processed by Airwave, this is because the IP address the controller uses to send them is different to the address Airwave is expecting (must be something to do with the address found during the discovery process I guess). So we manually changed the address for the controller by going to 'Manage'.
We found the problem by turning on raw debugging and looking in the Airwave logs which are located in:
See all logging options:
Turn on raw debugging:
qlog enable amon_dump_raw
qlog disable all
Hello, looks like we've hit this issue, and I'm struggling to get it sorted. How did you view the debug log once generated, I'm prevented from viewing the amp_diag directory. The vi amon command yields a response that tells me the command 'is not allowed.' Very frustrating. Did vi amon work for you?
(My new query is here https://community.arubanetworks.com/discussion/airwave-not-reporting-traffic)I manually added the controllers for which I've got no client or usage data reaching AW, so it shouldn't be a discovery issue. And manually changing (to deliberately wrong) and changing back the controller IP doesn't jog anything into action.Thanks.Nathan
Hello Nathan,I think AW has been tightened up a bit so there is less available under the hood for normal users. I guess you'll need TAC if you need to do anything fancy involving the CLI.Things I remember needing to check (and being caught out by!) - Check and recheck SNMP and CLI credentialsMake sure you have a papi-security profile on the controllers and are using the correct key in AW (AMP Setup -> General -> Additional AMP Services)Make sure "snmp-server user...", "snmp-server host...", "mgmt-server..." and the mgmt server profile are correctly configured on controllersCheck FW isn't getting in the way!Guy
Hello Guy,Thanks for your reply. I drove myself nuts with the SNMP and CLI creds - test, deliberately break, re-test, fix - until I was sure that wasn't the problem.Turns out the problem is something in AW 188.8.131.52, and it did need TAC help (most frustrating TAC call I've ever had!) with all 3 of our AW servers.
airwave=> update seas_config set use_amon_for_thin_ap_status = 0;<o:p></o:p>
root@net-aw3 CentOS7 /var/airwave/home/awsupport # rdAP devices that were being 'discovered' no longer appear where they shouldn't appear.All the best.<o:p></o:p>
Ahhhh that query looks familiar! Glad you got it sorted. We are just upgrading to 8.3.0, needless to say a TAC case was involved ;) (Mostly complete now so no real complaints!)
airwave=> update seas_config set use_amon_for_thin_ap_status = 0;
root@net-aw3 CentOS7 /var/airwave/home/awsupport # rdAP devices that were being 'discovered' no longer appear where they shouldn't appear.All the best.
© Copyright 2023 Hewlett Packard Enterprise Development LPAll Rights Reserved.