Network Management

Hi

I'm setting up a lab with Airwave (8.2.0.1). I've added the AMP server to the controllers with the default-amp mgmt-server profile (I had to do it via CLI, the GUI didn't put the default-amp profile in the running config).

Polling the controller via SNMP updates the client info.

AMON is enabled on AMP. When I enable 'prefer AMON over SNMP' the client count isn't updated at all. Not automatically, not when polling the controller.

I see the AMONAggregator and PAPI processes in AMP.

'show mgmt-server message-counters process wms' on the controller shows increasing counters.

I see PAPI packets from the controller to AMP.

Is there a way that I can check the AMON handling in AMP?

Thx

Peter

Is there a firewall between your controller and the Airwave server?  

What version of ArubaOS are you running?

You can try the suggestions on the AMON Troubleshooting page here:  http://community.arubanetworks.com/t5/Monitoring-Management-Location/Basic-AMON-troubleshooting-on-Airwave/ta-p/211841  -  Just remember to turn off the "qlog enable" after you are done.

You should not use "Prefer AMON", because there is some data that is not transferred using AMON, and you could lose that information if you turn on Prefer AMON.  Please see the document here:  https://support.arubanetworks.com/Documentation/tabid/77/DMXModule/512/Command/Core_Download/Default.aspx?EntryId=14097 .  Table 4 on page 41 tells you what protocols are required for what communication.  Enabling Prefer AMON would mean missing data for the protocols that do not use AMON.

Also, if you're double checking status of AMON data inbound to AirWave, check System -> Performance -> AMON Statistics.  There's 4 graphs that help show whether AirWave is receiving / processing AMON data.  Aside from that, support would be able to assist in enabling additional logging and translating/parsing those logs to give you a better idea of what information is coming through AMON.

Hi @ll

Again thanks for the replies.

With the qlog I managed to find the cause of the amon error: the controller IP is in another subnet as the AMP server. However, the controller also had an IP address in the subnet of the AMP.

Because of this the source address of the amon packets was the IP address in the AMP subnet. This address wasn't known in AMP, hence the packets were dropped by AMP with 'dropping payload because id is not found' messages.

After removing the IP in the AMP subnet on the controller the amon / papi messages were accepted.

However, I do not find that the updates are really fast in AMP. The amon messages come immediatly after a change occurs on the controller, but it takes several minutes before this change is shown in AMP.

Is this expected behaviour?

Peter

Which change are you referring to?

I am connecting and disconnecting clients.

Clients are disconnected after the user-idle-timeout which means it would be reflected on the controller 5 minutes after a client stops sending traffic.  After that, it would be reflected via an SNMP trap (not amon) to Airwave.

I see. So using AMP as a client location tool (is a customer request, for security purposes) isn't really advised? When I roam with a client device, it's location gets updated after polling the controller.

Am I correct to assume that AMON is not used to get faster updates, but to get more details?

Peter

Let me clear the air on some points here:

- AMON passes data to AirWave at regular intervals that's faster than SNMP (doesn't have to wait for request/response timing - doesn't have large gaps due to larger bulk requests)

- Client association/Client disassociation should be processed as if they were traps - these packets are processed ahead of the queue

- collected data via AMON is held and then processed based on group polling

- AMON data for location is sent to VisualRF in parallel to being added to processing queue (abiding by VRF's terms for recalculation (based on number of samples or time since last sample)

VisualRF should be used for location tracking.  While other AMP data should be available based on 5 minutes pollings (based on lowest possible client polling time allowed).

If you're seeing issues with the above, please open a support case so that someone in support can work with you to make possible performance adjustments to ensure you're AMP is running at optimal processing speed.

Hi Rob

@rgin wrote:

- AMON passes data to AirWave at regular intervals that's faster than SNMP

- Client association/Client disassociation should be processed as if they were traps - these packets are processed ahead of the queue

I see this in Wireshark too.

- collected data via AMON is held and then processed based on group polling

- AMON data for location is sent to VisualRF in parallel to being added to processing queue (abiding by VRF's terms for recalculation (based on number of samples or time since last sample)

VisualRF should be used for location tracking.  While other AMP data should be available based on 5 minutes pollings (based on lowest possible client polling time allowed).

So Visual RF should show the location changes faster than the polling period, while other amon obtained data is updated at the polling period?

It seems as if I only see location changes after a poll (manual or auto after the period).

Correct.  If you're not seeing this behavior then you can probably open a support case for a deeper inspection.  I would expect VRF to keep up if given the proper memory allocation.  It also depends on number of floor plans, APs, and clients per floor.

I' ve opened a TAC call. I'll post the results.

To post the result after the TAC call:

• there were lots of 'rrdcached: illlegal attempt to update' messages in the async_logger_client. A file must have become corrupted. An AMP restart solved the issue.
• Also we've upgraded to 8.2.0.2, because there is a fix for clients not appearing in Visual RF.

All seems ok now.