Wireless Access

Hello,

We have a trial running with a controller (all licenses enabled), Airwave and three AM. The goal is to convince the client Aruba has a viable IDS/IPS solution (the customer needs to protect his enviroment; he does not have WiFi access.

With this setup, he is able to see on the map of both controller WebUI and VisualRF the AMs and rogue APs. However, the following does not show grapically (allthough most of this info is availiable in textual form):

• Heat maps (penetration/detection zones) for installed AMs
• Neighbour APs (as opposed to rogue APs), and their heat maps
• Clients
• Client associations  with rogue and neihbour APs
• In general, the whole "relations" tab in VisualRF is of no use: nothing is shown

Can anyone please advise me if this info should be present on the graphical maps of WebUI/VisualRF? With mixed AP/AM deployment all of this is indeed present, so why the AM-only deployment should be different?

Thanks a lot,

Yuly

You should be able to see the same data with both AP/AM modes.  Several customers are running AirWave the same way (for purely RAPIDS), so it might have something to do with the setup.  The things I'd check off the top:

1. Is the AirWave installed test server suitable for running AirWave?  (Is it hitting swap?  is it 64bit capable?  Is it out of disk space?)

2. Is controller pointing traps to AirWave?

3. Are the traps on the controller enabled?

Also, for a wired deployment, the customer would get more out of RAPIDS if he added his edge/core switches.  That way they can monitor both the wired ports and wireless for any overlap.

If the setup looks correct, but is still behaving in this way, then opening a support case may be the best next step.  They can double check and run some additional logging to make sure the information is coming through.

Hi,

I have opened a case with techsupport, and the answer I was given is that VisualRF can only display your own APs/AMs and the rogue APs. No Neighbor, suspected neighbor or client association can be shown.

Assuming this is correct, my question is as follows:

• Is it possible to visually distinguish between rogues and suspected rogues (both of them shall be shown on the map)? With different icon colors maybe, or in some other way

This design severely limits implementation, at least in my client's case.

Thanks,

Yuly

That's correct, the current implementation of VisualRF limits you to only monitored/managed devices, rogue devices, and active clients.  I agree that it'd be useful to show neighbor, suspected neighbor, and neighbor clients, which makes it a good feature request to make through your currently open support case.  I also agree that having colors to distinguish between rogues and suspected rogues would be another valuable feature request to make.

For now, you can potentially use the RAPIDS Export Threshold (under RAPIDS -> Setup).  This is the setting that designates what data is passed from RAPIDS to VisualRF for display.  It's a 'top and down' selection, meaning whichever option you choose, it and the items listed below it will be exported to VisualRF.  If you set it to Rogues, you'll only see Rogues and Contained Rogues in VisualRF.  It's set to 'suspected rogue' by default.  Try to not set it to anything higher as that increases the number of items passed to VisualRF for location calculation.  You want the data passed from RAPIDS to VisualRF to be of value instead of cluttered.  VisualRF has a hardcoded limit to the number of RAPIDS generated items that can be displayed per floor which is done as a performance limiter since some environments can have a large number of rogues.

Also, make sure that your client is making use of the RAPIDS rules.  It's important to classify as many heard devices as possible to narrow down the number of suspected rogues and rogues to a number that they will actually care about.  I've seen many customers who have only the default rules which may not make sense in their environment.  Things like coffee shop hotspots, video game consoles, teleconference devices, and scanners should be classified to something between valid and suspected neighbor.