Airwaveand arubabestpracticesguide

  • 154 views
Uploaded on

 

More in: Technology , Travel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
154
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
7
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Aruba and AirWave 7.7 BestPracticesGuide
  • 2. June 2013 | 0510831-08 AirWave 7.7 | Best Practices Guide Copyright © 2013 Aruba Networks, Inc. Aruba Networks trademarks include , Aruba Networks®, Aruba Wireless Net- works®, the registered Aruba the Mobile Edge Company logo, Aruba Mobility Management System®, Mobile Edge Archi- tecture®, People Move. Networks Must Follow®, RFProtect®, Green Island®. All rights reserved. All other trademarks are the property of their respective owners. Open Source Code Certain Aruba products include Open Source software code developed by third parties, including software code subject to the GNU General Public License (GPL), GNU Lesser General Public License (LGPL), or other Open Source Licenses. Includes software from Litech Systems Design. The IF-MAP client library copyright 2011 Infoblox, Inc. All rights reserved.This product includes software developed by Lars Fenneberg et al. The Open Source code used can be found at this site: http://www.arubanetworks.com/open_source Legal Notice The use of Aruba Networks, Inc. switching platforms and software, by all individuals or corporations, to terminate other vendors’ VPN client devices constitutes complete acceptance of liability by that individual or corporation for this action and indemnifies, in full, Aruba Networks, Inc. from any and all legal actions that might be taken against it with respect to infringe- ment of copyright on behalf of those vendors. Warranty This hardware product is protected by the standard Aruba warranty of one year parts/labor. For more information, refer to the ARUBACARE SERVICE AND SUPPORT TERMS AND CONDITIONS. Altering this device (such as painting it) voids the warranty.
  • 3. AirWave 7.7 | Best Practices Guide | iii Contents Chapter 1 Overview 5 Understanding Aruba Topology 5 Prerequisites for Integrating Aruba Infrastructure 5 Feature Implementation Schedule 6 Chapter 2 Configuring AirWave for Aruba Infrastructure 9 Disabling Rate Limiting in AMP Setup > General 9 Entering Credentials in Device Setup > Communication 10 Setting Up Recommended Timeout and Retries 11 Setting Up Time Synchronization 11 Manually Setting the Clock on a Controller 11 Enabling Support for Channel Utilization And Statistics 11 AirWave Setup 12 Controller Setup (Master And Local) 12 Chapter 3 Configuring an Aruba Group in AMP 13 Basic Monitoring Configuration 13 Advanced Configuration 14 Chapter 4 Discovering Aruba Infrastructure 15 Discovering or Adding Master Controllers 15 Local Controller Discovery 17 Thin AP Discovery 17 Chapter 5 AMP and Aruba Integration Strategies 19 Integration Goals 19 Example Use Cases 20 When to Use Enable Stats 20 When to Use WMS Offload 20 When to Use RTLS 20 When to Define AMP as a Trap Host 20 When to Use Channel Utilization 21 Prerequisites for Integration 21 Enable Stats Utilizing AMP 21 WMS Offload with AMP 22 Define AMP as a Trap Host using the ArubaOS CLI 23 Ensuring That IDS And Auth Traps Display in AMP 23 Understanding WMS Offload Impact on Aruba Infrastructure 24 Chapter 6 Aruba Specific Capabilities in AMP 27 Aruba Traps for RADIUS Auth and IDS Tracking 27 Remote AP Monitoring 28 ARM and Channel Utilization Information 28
  • 4. iv | AirWave 7.7 | Best Practices Guide VisualRF and Channel Utilization 29 Configuring Channel Utilization Triggers 30 Viewing Channel Utilization Alerts 31 Channel Utilization Alerts on the APs/Devices > Monitor Page 31 Channel Utilization Alerts on the System > Alerts Page 32 View Channel Utilization in RF Health Reports 32 Viewing Controller License Information 32 Rogue Device Classification 33 Rules-Based Controller Classification 35 Using RAPIDS Defaults for Controller Classification 35 Changing RAPIDS based on Controller Classification 35 Appendix A ArubaOS and AMP CLI Commands 37 Enable Channel Utilization Events 37 Enable Stats With the ArubaOS CLI 37 Offload WMS Using the ArubaOS or AMP CLI 37 ArubaOS CLI 37 AMP SNMP 38 Pushing Configs from Master to Local Controllers 38 Disable Debugging Utilizing the ArubaOS CLI 38 Restart WMS on Local Controllers 39 Configure ArubaOS CLI when not Offloading WMS 39 Copy and Paste to Enable Proper Traps with the ArubaOS CLI 39 Appendix B AMP Data Acquisition Methods 41 Appendix C WMS Offload Details 43 State Correlation Process 43 Using AMP as a Master Device State Manager 43 Appendix D Increasing Location Accuracy 45 Understand Band Steering's Impact on Location 45 Leveraging RTLS to Increase Accuracy 45 Prerequisites 45 Deployment Topology 46 Enable RTLS Service on the AMP Server 46 Enable RTLS on the Controller 47 Troubleshooting RTLS 48 Using the WebUI 48 Using the CLI 48 Wi-Fi Tag Setup Guidelines 49
  • 5. AirWave 7.7 | Best Practices Guide Chapter 1 Overview | 5 Chapter 1 Overview This document provides best practices for leveraging AirWave to monitor and manage your Aruba infrastructure. Aruba wireless infrastructure provides a wealth of functionality such as firewall, VPN, remote AP, IDS, IPS, and ARM, as well as an abundance of statistical information. Follow the simple guidelines in this document to garner the full benefit of your Aruba infrastructure. This overview chapter contains the following topics: l "Understanding Aruba Topology" on page 5 l "Prerequisites for Integrating Aruba Infrastructure " on page 5 l "Feature Implementation Schedule" on page 6 Understanding Aruba Topology Figure 1 depicts a typical master-local deployment for the AirWave Wireless Management System (AWMS): Figure 1 Typical Aruba Deployment There should never be a local controller managed by an AMP server whose master controller is also not under management. Prerequisites for Integrating Aruba Infrastructure You will need the following information to monitor and manage your Aruba infrastructure: l SNMP community string (monitoring and discovery) l Telnet/SSH credentials (configuration only) l Enable password (configuration only)
  • 6. 6 | Chapter 1 Overview AirWave 7.7 | Best Practices Guide Withoutproper Telnet/SSH credentials AMP will not be able to acquire license and serial information from controllers. l SNMPv3 credentials are required for WMS Offload: n Username n Auth password n Privacy password n Auth protocol Feature Implementation Schedule The following table describes the feature implementation schedule for AMP: Feature AMP Implementation Ability to filter User Session by ArubaOS roles 7.0 ArubaOS 5.0 support 7.0 RAP white list management for RN 3.1 7.0 Added support for rogue containment 7.0 Added support for configuring controller- specific overrides 7.0 Client dot11counter status 7.0 Added support for AP-92 and AP-93 7.1 Ability to use controller WIPS classification within RAPIDS 7.1 Use controller classification/confidence level within a RAPIDS rule 7.1 ArubaOS provides Ad-Hoc rogues and encryption type 7.1 Channel Utilization 7.1 AP dot11counter statistics 7.1 Support for SNMPv3 informs 7.1 Track BW on wired users connected to RAPs 7.1 Ability to configure SNMP local configuration 7.1 Ability to track ARM power and channel changes 7.2 Ability to track Noise Floor 7.2 Ability to track Interfering Devices 7.2 Ability to store and display ARM logs 7.2 Table 1: Feature Implementation Schedule for AMP
  • 7. Feature AMP Implementation Ability to track user associations and roaming via SNMP traps 7.2 Ability to pull Channel Summary CLI statistics from controller 7.2 AMP requires a 64-bit operating system 7.3 VisualRF and RAPIDS are now standard part of the AMP 7.3 System > Syslog and Traps page has been added to display all syslog messages and SNMP traps that AMP receives 7.3 Aruba Mobile Device Access Control (MDAC) secures, provisions and manages network access for Apple® iOS and other employee-owned mobile devices by enabling device fingerprinting, device registration, and increased device visibility 7.3 Basic monitoring support for wired users on the new Aruba Mobility Access Switch. 7.3 Support for Aruba AirMesh 7.3 Session-based authentication in AMP (login/logout) 7.3 Ability to filter on list tables (new funnel icon) 7.3 Device Type filtering on reports 7.3 Interferer location ability 7.3 Added Open controller web UI drop-down menu to the APs/Devices > Monitor and Users > User Detail pages for Aruba devices 7.3 Single Sign-on between AirWave and Aruba devices 7.4 VPN User monitoring, including Aruba VIA 7.4 Configuration for standalone and stacked Aruba Mobility Access Switch 7.4 Extended support for Aruba Instant 7.4 Extended support for Remote Access Points (RAPs) 7.4 Mesh support for Aruba AP-175 7.4 Support for Aruba Instant 6.1.3.1-3.0.0.0 7.5 Authentication with LDAP 7.5 Recurring Configuration Changes 7.5 Configurable Authentication Priority 7.5 Configurable Mail Relay Server 7.5 Support for Aruba Instant 6.1.3.4-3.1.0.0 7.5.6 Print Reports in PDF format 7.6 AirWave 7.7 | Best Practices Guide Chapter 1 Overview | 7
  • 8. 8 | Chapter 1 Overview AirWave 7.7 | Best Practices Guide Feature AMP Implementation RF Performance Page 7.6 Bulk Edit Instant Devices 7.6 Support for ArubaOS 6.2 7.6 Support for Instant 3.1 Configuration 7.6 Support for Aruba 7x00 Controller 7.6 Support for Aruba S3500-24F Mobility Access Switch 7.6 Single Sign-on between AirWave and Instant devices 7.6 Support for Instant 6.2.0.0-3.2.0.0 7.6.1 Support for Instant 6.2.0.0-3.3.0.0 7.6.4 Support for RAP-155 7.6.5 Support for ArubaOS 6.3 7.7 Highcharts 7.7 Support for ARM 3.0 7.7 Policy Enforcement Firewall (PEF) Visibility 7.7 View/Monitor Network Deviations 7.7 Switch Configuration for Mobility Access Switches running AOS 7.2 or greater 7.7 Add and Monitor Watched Clients 7.7 Email Reports in CSV Format 7.7 Support for SNMPv3 Informs 7.7 RF Capacity (beta version) 7.7 Instant Config (beta version) 7.7
  • 9. AirWave 7.7 | Best Practices Guide Chapter 2 Configuring AirWave for Aruba Infrastructure | 9 Chapter 2 Configuring AirWave for Aruba Infrastructure This section explains how to optimally configure AirWave to globally manage your global Aruba infrastructure. Refer to the following topics: l "Disabling Rate Limiting in AMP Setup > General" on page 9 l "Entering Credentials in Device Setup > Communication" on page 10 l "Setting Up Recommended Timeout and Retries" on page 11 l "Setting Up Time Synchronization" on page 11 l "Enabling Support for Channel Utilization And Statistics" on page 11 Disabling Rate Limiting in AMP Setup > General The SNMP Rate Limiting for Monitored Devices option adds a small delay between each SNMP GET request, thus the actual polling intervals will be longer than what is configured. For example, setting a 10-minute polling interval will result in an actual 12-minute polling interval. Disabling rate limiting is recommended in most cases unless you are using legacy Aruba devices, such as M2 devices. To disable rate limiting in AirWave, follow these steps: 1. Navigate to AMP Setup > General. 2. Locate the Performance section on this page. 3. In the SNMP Rate Limiting for Monitored Devices field, select No, as shown in Figure 2. 4. Select Save. Figure 2 SNMP Rate Limiting in AMP Setup > General
  • 10. 10 | Chapter 2 Configuring AirWave for Aruba Infrastructure AirWave 7.7 | Best Practices Guide Entering Credentials in Device Setup > Communication AMP requires several credentials to properly interface with Aruba devices. To enter these credentials, follow these steps: 1. Navigate to Device Setup > Communication. 2. In the Default Credentials section, select the Edit link next to Aruba. The page illustrated in Figure 3 appears. 3. Enter the SNMP Community String. Be sure to note the community string because it must match the SNMP trap community string, which is configured later in this document. Figure 3 Credentials in Device Setup > Communication 4. Enter the required fields for configuration and basic monitoring: l Telnet/SSH Username l Telnet/SSH Password l enable Password 5. Enter the required fields for WMS Offload: l SNMPv3 Username l Auth Password l SNMPv3 Auth Protocol l Privacy Password l SNMPv3 Privacy Protocol The authentication and privacy protocols should be SHA-1 and DES in order for WMS Offload to work.
  • 11. 6. Click Save when you are finished. Setting Up Recommended Timeout and Retries To set recommended timeout and retries settings, follow these steps: 1. In the Device Setup > Communication page, locate the SNMP Setting section. 2. Change the SNMP Timeout setting to a value or either 3, 4, or 5. This is the number of seconds that AMP will wait for a response from a device after sending an SNMP request, so a smaller number is more ideal. 3. Change the SNMP Retries value to 10. This value represents the number of times AMP tries to poll a device when it does not receive a response within the SNMP Timeout Period or the Group’s Missed SNMP Poll Threshold setting (1- 100). Although the upper limit for this value is 40, some SNMP libraries still have a hard limit of 20 retries. In these cases, any retry value that is set above 20 will still stop at 20. Figure 4 Timeout settings in Device Setup > Communication 4. Click Save when you are done. Setting Up Time Synchronization You can set the clock on a controller manually or by configuring the controller to use a Network Time Protocol (NTP) server to synchronize its system clock with a central time source. Manually Setting the Clock on a Controller You can use either the WebUI or CLI to manually set the time on the controller’s clock. 1. Navigate to the Configuration > Management > Clock page. 2. Under Controller Date/Time, set the date and time for the clock. 3. Under Time Zone, enter the name of the time zone and the offset from Greenwich Mean Time (GMT). 4. To adjust the clock for daylight savings time, click Enabled under Summer Time. Additional fields appear that allow you to set the offset from UTC and the start and end recurrences. 5. Click Apply. Enabling Support for Channel Utilization And Statistics In order to enable support for channel utilization statistics, you must have the following: l AirWave 7.2 or later l ArubaOS 6.0.1 or later ArubaOS 6.0.1 can report RF utilization metrics, while ArubaOS 6.1 is necessary to also obtain classified interferer information. AirWave 7.7 | Best Practices Guide Chapter 2 Configuring AirWave for Aruba Infrastructure | 11
  • 12. 12 | Chapter 2 Configuring AirWave for Aruba Infrastructure AirWave 7.7 | Best Practices Guide l Access points - Aruba AP-92, AP-93, AP-105, AP-124, AP-125, AP-134, AP-135 l Controllers - Aruba 600 Series, 3000 Series, 6000 Series, or 7200 Series AirWave Setup Follow these steps in AirWave: 1. Navigate to AMP Setup > General. 2. In the Additional AMP Services section, set Enable AMON Data Collection to Yes, and set Prefer AMON vs SNMP Polling to Yes. Figure 5 AMON Data Collection setting in AMP Setup > General 3. Click Save when you are done. Controller Setup (Master And Local) Enabling these commands on ArubaOS versions prior to 6.0.1.0 can result in performance issues on the controller. If you are running previous firmware versions such as ArubaOS 6.0.0.0, you should upgrade to ArubaOS 6.0.1 (to obtain RF utilization metrics) or 6.1 (to obtain RF utilization and classified interferer information) before you enter this command. Use SSH to access the controller’s command-line interface, enter enable mode, and issue the following commands: (Controller-Name) # configure terminal Enter Configuration commands, one per line. End with CNTL/Z (Controller-Name) (config) # mgmt-server type amp primary-server <AMP-IP> (Controller-Name) (config) # write mem You can add up to four <AMP-IP> addresses.
  • 13. AirWave 7.7 | Best Practices Guide Chapter 3 Configuring an Aruba Group in AMP | 13 Chapter 3 Configuring an Aruba Group in AMP It is prudent to establish one or more Aruba Groups within AMP. During the discovery process you will move new discovered controllers into this group. This section contains the following topics: l "Basic Monitoring Configuration" on page 13 l "Advanced Configuration " on page 14 Basic Monitoring Configuration 1. Navigate to Groups > List. 2. Select Add. 3. Enter a Name that represents the Aruba device infrastructure from a security, geographical, or departmental perspective and select Add. 4. You will be redirected to the Groups > Basic page for the Group you just created. On this page you will need to verify and/or change the following Aruba-specific settings. a. Find the SNMP Polling Periods section of the page, as illustrated in Figure 6. b. Verify that the Override Polling Period for Other Services option is set to Yes. c. Verify that Client Data Polling Period is set to 10 minutes. Do not configure this interval lower than 5 minutes. Enabling the SNMP Rate Limiting for Monitored Devices option in the previous chapter adds a small delay between each SNMP Get request, thus the actual polling interval is 12 minutes for 10 minute polling interval. d. Verify that the Device-to-Device Link Polling Period option is set to 30 minutes. e. Verify that the Rogue AP and Device Location Data Polling Period option is set to 30 minutes. Figure 6 SNMP Polling Periods section of Groups > Basic 5. Locate the Aruba section of this page, as illustrated in Figure 7. 6. Configure the proper SNMP Version for monitoring the Aruba infrastructure.
  • 14. 14 | Chapter 3 Configuring an Aruba Group in AMP AirWave 7.7 | Best Practices Guide Figure 7 Group SNMP Version for Monitoring 7. Click Save and Apply when you are done. Advanced Configuration Refer to the AirWave 7.7 Configuration Guide located at Home > Documentation for detailed instructions.
  • 15. AirWave 7.7 | Best Practices Guide Chapter 4 Discovering Aruba Infrastructure | 15 Chapter 4 Discovering Aruba Infrastructure AMP utilizes the Aruba topology to efficiently discover downstream infrastructure. This section guides you through the process of discovering and managing your Aruba device infrastructure. Refer to the following earlier sections in this document before attempting discovery: l "Configuring AirWave for Aruba Infrastructure" on page 9 l "Configuring an Aruba Group in AMP" on page 13 The following topics in this chapter walk through the basic procedure for discovering and managing Aruba infrastructure: l "Discovering or Adding Master Controllers" on page 15 l "Local Controller Discovery" on page 17 l "Thin AP Discovery" on page 17 Always add one controller and its affiliated Thin APs into management or monitoring mode in a serial fashion, one at a time.Adding new devices is a very CPU intensive process for AMP and can quickly overwhelm all of the processing power ofthe server if hundreds of Thin APs are added (migrated from New to Managed or Monitoring) simultaneously. Discovering or Adding Master Controllers Scan networks containing Aruba master controllers from Device Setup > Discover. - or - Manually enter the master controller by following these steps in the Device Setup > Add page: 1. Select the Aruba Device type and select Add. The page illustrated on Figure 8 appears. 2. Enter the Name and the IP Address for the controller. 3. Enter SNMP Community String, which is required field for device discovery. Be sure to note the community string because it must match the SNMP trap community string, which is configured later in this document.
  • 16. 16 | Chapter 4 Discovering Aruba Infrastructure AirWave 7.7 | Best Practices Guide Figure 8 Aruba Credentials in Device Setup > Add 4. Enter the required fields for configuration and basic monitoring: n Telnet/SSH Username n Telnet/SSH password n enable password 5. Enter the required fields for WMS Offload n SNMPv3 Auth Protocol n SNMPv3 Privacy Protocol n SNMPv3 Username n Auth Password n Privacy Password The protocols for SNMPv3 Auth and SNMPv3 Privacy should be SHA-1 and DES in order for WMS Offload to work. Ifyou are using SNMPv3, and the controller's date/time is incorrect, the SNMP agent will not respond to SNMP requests from the AMP SNMP manager. This will result in the controller and all of its downstream access points showing as Down in AMP.
  • 17. 6. Assign the controller to a Group and Folder. 7. Ensure that the Monitor Only option is selected. Ifyou select Manage read/write, AMP will push the group setting configuration, and existing device configurations will be deleted/overwritten. 8. Select Add. 9. Navigate to the APs/Devices > New page. 10.Select the Aruba master controller you just added from the list of new devices. 11.Ensure Monitor Only option is selected. 12.Select Add. Local Controller Discovery Local controllers are added to AMP via the master controller, by a discovery scan, or manually added in Device Setup > Add. After waiting for the Thin AP Polling Period interval or executing a Poll Now command from the APs/Devices > Monitor page, the local controllers will appear on the APs/Devices > New page. Add the local controller to the Group defined previously. Within AMP, local controllers can be split away from the master controller's Group. Local Controller Discovery/monitoring may not work as expected if AirWave is unable to communicate directly with the targetdevice. Be sure and update any ACL/Firewall rules to allow AirWave to communicate with your network equipment. Thin AP Discovery Thin APs are discovered via the local controller. After waiting for the Thin AP Polling Period or executing a Poll Now command from the APs/Devices > Monitor page, thin APs will appear on the APs/Devices > New page. Add the thin APs to the Group defined previously. Within AirWave, thin APs can be split away from the controller's Group. You can split thin APs into multiple Groups if required. AirWave 7.7 | Best Practices Guide Chapter 4 Discovering Aruba Infrastructure | 17
  • 18. 18 | Chapter 4 Discovering Aruba Infrastructure AirWave 7.7 | Best Practices Guide
  • 19. AirWave 7.7 | Best Practices Guide Chapter 5 AMP and Aruba Integration Strategies | 19 Chapter 5 AMP and Aruba Integration Strategies This section describes strategies for integrating AMP and Aruba devices and contains the following topics: l "Integration Goals" on page 19 l "Example Use Cases" on page 20 l "Prerequisites for Integration" on page 21 l "Enable Stats Utilizing AMP" on page 21 l "WMS Offload with AMP" on page 22 l "Define AMP as a Trap Host using the ArubaOS CLI" on page 23 l "Understanding WMS Offload Impact on Aruba Infrastructure" on page 24 Integration Goals The following table summarizes the types of integration goals and strategies for meeting them in certain architectural contexts: Integration Goals All Masters Architecture Master/Local Architecture Rogue And Client Info enable stats Rogue containment only ssh access to controllers ssh access to controllers Rogue And Client containment WMS Offload WMS Offload Reduce Master Controller Load WMS Offload debugging off IDS And Auth Tracking Define AMP as a trap host Define AMP as a trap host Track Tag Location enable RTLS WMS Offload enable RTLS WMS Offload Channel Utilization enable AMON enable AMON Spectrum enable AMON enable AMON Policy Enforcement Firewall (PEF) visibility enable AMON enable AMON Health Information enable ARM enable ARM Table 2: Integration Goals in All Masters or Master/Local Architectures Key integration points to consider include the following: l IDS Tracking does not require WMS Offload in an all-master or master/local environment. l IDS Tracking does require enable stats in a master/local environment. l WMS Offload will hide the Security Summary tab on master controller’s web interface. l WMS Offload encompasses enable stats or enable stats is a subset of WMS Offload.
  • 20. 20 | Chapter 5 AMP and Aruba Integration Strategies AirWave 7.7 | Best Practices Guide l Unless you enable stats on the local controllers in a master/local environment, the local controllers do not populate their MIBs with any information about clients or rogue devices discovered/associated with their APs. Instead the information is sent upstream to master controller. Example Use Cases The following are example use cases of integration strategies: l "When to Use Enable Stats" on page 20 l "When to Use WMS Offload" on page 20 l "When to Use RTLS" on page 20 l "When to Define AMP as a Trap Host" on page 20 l "When to Use Channel Utilization" on page 21 When to Use Enable Stats You want to pilot AMP, and you do not want to make major configuration changes to their infrastructure or manage configuration from AMP. Enable Stats still pushes a small subset of commands to the controllers via SSH. See "Enable Stats Utilizing AMP" on page 21. When to Use WMS Offload l You have older Aruba infrastructure in a master/local environment and their master controller is fully taxed. Offloading WMS will increase the capacity of the master controller by offloading statistic gathering requirements and device classification coordination to AMP. l You want to use AMP to distribute client and rogue device classification amongst multiple master controllers in a master/local environment or in an All-Masters environment. l See the following topics: n "WMS Offload with AMP" on page 22 n "Understanding WMS Offload Impact on Aruba Infrastructure" on page 24 n "WMS Offload Details" on page 43 When to Use RTLS l A hospital wants to achieve very precise location accuracy (5 -15 feet) for their medical devices which are associating to the WLAN. l You want to locate items utilizing WiFi Tags. RTLS can negatively impact your AMP server's performance. l See "Leveraging RTLS to Increase Accuracy" on page 45. When to Define AMP as a Trap Host l You want to track IDS events within the AMP UI.
  • 21. l You are in the process of converting their older third-party WLAN devices to Aruba devices and want a unified IDS dashboard for all WLAN infrastructure. l You want to relate Auth failures to a client device, AP, Group of APs, and controller. AMP provides this unique correlation capability. See "Define AMP as a Trap Host using the ArubaOS CLI" on page 23. When to Use Channel Utilization l You have a minimum version of ArubaOS 6.1.0.0 and AP-105 or AP-135. Prerequisites for Integration If you have not discovered the Aruba infrastructure or configured credentials, refer to the previous chapters of this book: l "Configuring AirWave for Aruba Infrastructure" on page 9 l "Configuring an Aruba Group in AMP" on page 13 l "Discovering Aruba Infrastructure" on page 15 Enable Stats Utilizing AMP To enable stats on the Aruba controllers, follow these steps: 1. Navigate to AMP Setup > General and locate the Device Configuration section. 2. Set the Allow WMS Offload Configuration in Monitor-Only Mode field to Yes, as shown in Figure 9: Figure 9 WMS Offload Configuration in AMP Setup > General 3. Navigate to Groups > Basic for the group that contains your Aruba controllers. 4. Locate the Aruba section on the page. 5. Set the Offload WMS Database field to No, as shown in Figure 10: Figure 10 Offload WMS Database field in Groups > Basic AirWave 7.7 | Best Practices Guide Chapter 5 AMP and Aruba Integration Strategies | 21
  • 22. 22 | Chapter 5 AMP and Aruba Integration Strategies AirWave 7.7 | Best Practices Guide 6. Select Save and Apply. 7. Select Save. This will push a set of commands via SSH to all Aruba local controllers. AMP must have read/write access to the controllers in order to push these commands. This process will not reboot your controllers. Ifyou don't follow the above steps, local controllers will not be configured to populate statistics. This decreases AMP's capability to trend client signal information and to properly locate devices. See "ArubaOS CLI" on page 37 for information on how to utilize the ArubaOS CLI to enable stats on Aruba infrastructure. If your credentials are invalid or the changes are not applied to the controller, error messages will display on the controller's APs/Devices > Monitor page under the Recent Events section. If the change fails, AMP does not audit these setting (display mismatches) and you will need to apply to the controller by hand. See "ArubaOS CLI" on page 37 for detailed instructions. These are the commands pushed by AMP while enabling WMS Offload. Do not enter these commands: configure terminal no mobility-manager <Active WMS IP Address> wms general collect-stats enable stats-update-interval 120 show wms general write mem WMS Offload with AMP To offload WMS on the Aruba controllers using AMP 1. In AMP Setup > General, locate the Device Configuration section and enable or disable Allow WMS Offload Configuration in Monitor-Only Mode. 2. Select Save and Apply. This will push a set of commands via SSH to all Aruba master controllers. If the controller does not have an SNMPv3 user that matches the AMP database it will automatically create a new SNMPv3 user. AMP must have read/write access to the controllers in order to push these commands 3. Navigate to Groups > Basic and locate the Aruba section. 4. Set the Offload WMS Database field to Yes. This process will not reboot your controllers. See "ArubaOS and AMP CLI Commands " on page 37on how to utilize the ArubaOS CLI to enable stats for WMS Offload. The SNMPv3 user's Auth Password and Privacy Password must be the same. Do not enter these commands; these are pushed by AMP while enabling WMS Offload. configure terminal mobility-manager <AMP IP> user <AMP SNMPv3 User Name> <AMP Auth/Priv PW> stats-update-interval 120 write mem
  • 23. AMP will configure SNMPv2 traps with the mobile manager command. Define AMP as a Trap Host using the ArubaOS CLI To ensure the AMP server is defined a trap host, access the command line interface of each controller (master and local), enter enable mode, and issue the following commands: (Controller-Name) # configure terminal Enter Configuration commands, one per line. End with CNTL/Z (Controller-Name) (config) # snmp-server host <AMP IP ADDR> version 2c <SNMP Community String of Controller> Ensure the SNMP community matches those that were configured in "Configuring AirWave for Aruba Infrastructure" on page 9. (Controller-Name) (config) # snmp-server trap source <Controller-IP> (Controller-Name) (config) # write mem AMP supports SNMP v2 traps and SNMP v3 informs in ArubaOS 3.4 and higher. SNMP v3 traps are not supported. Ensuring That IDS And Auth Traps Display in AMP Validate your ArubaOS configuration by exiting the configure terminal mode and issue the following command: (Controller-Name) # show snmp trap-list If any of the traps in the output of this command do not appear to be enabled enter configure terminal mode and issue the following command: (Controller-Name) (config) # snmp-server trap enable <TRAPS FROM LIST ABOVE> See "ArubaOS CLI" on page 37 for the full command that can be copied and pasted directly into the ArubaOSCLI. (Controller-Name) (config) # write mem Ensure the source IP of the traps match the IP that AMP utilizes to manage the controller, as shown in Figure 11. Navigate to APs/Devices > Monitor to validate the IP address in the Device Info section. Figure 11 Verify IP Address on APs/Devices > Monitor Page Verify that there is a SNMPv2 community string that matches the SNMP Trap community string on the controller. (Controller-Name) # show snmp community AirWave 7.7 | Best Practices Guide Chapter 5 AMP and Aruba Integration Strategies | 23
  • 24. 24 | Chapter 5 AMP and Aruba Integration Strategies AirWave 7.7 | Best Practices Guide SNMP COMMUNITIES ---------------- COMMUNITY ACCESS VERSION --------- ------ ------- public READ_ONLY V1, V2c (Controller-Name) # #show snmp trap-host SNMP TRAP HOSTS --------------- HOST VERSION SECURITY NAME PORT TYPE TIMEOUT RETRY ---- ------- ------------- ---- ---- ------- ----- 10.2.32.4 SNMPv2c public 162 Trap N/A N/A Verify that firewall port 162 (default) is open between AMP and the controller. Validate that traps are making it into AMP by issuing the following commands from AMP command line. [root@AMP ~]# qlog enable snmp_traps [root@AMP ~]# tail -f /var/log/amp_diag/snmp_traps 1241627740.392536 handle_trap|2009-05-06 09:35:40 UDP: [10.2.32.65]->[10.51.5.118]:-32737 sends trap: DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (127227800) 14 days, 17:24:38.00 SNMPv2- MIB::snmpTrapOID.0 = OID: SNMPv2-SMI::enterprises.14823.2.3.1.11.1.2.1106 SNMPv2-SMI::enterpris es.14823.2.3.1.11.1.1.60 = Hex-STRING: 07 D9 05 06 09 16 0F 00 2D 08 00 SNMPv2-SMI::enterpri ses.14823.2.3.1.11.1.1.5.0 = Hex-STRING: 00 1A 1E 6F 82 D0 SNMPv2-SMI::enterprises.14823.2.3.1. 11.1.1.6.0 = STRING: aruba-apSNMPv2-SMI::enterprises.14823.2.3.1.11.1.1.1.0 = Hex-STRING: 00 1A 1E C0 2B 32 SNMPv2-SMI::enterprises.14823.2.3.1.11.1.1.56.0 = INTEGER: 2 SNMPv2-SMI::enterpr ises.14823.2.3.1.11.1.1.17.0 = STRING: aruba-124-c0:2b:32 SNMPv2-SMI::enterprises.14823.2.3.1.1 1.1.1.18.0 = INTEGER: 11 SNMPv2-SMI::enterprises.14823.2.3.1.11.1.1.58.0 = STRING: http://10. 51.5.118/screens/wmsi/reports.html?mode=ap&bssid=00:1a:1e:6f:82:d0 You will see many IDS and Auth Traps from this command. AMP only processes a small subset of these traps which display within AMP. The traps that AMP does process are listed above. We recommend that you disable qlogging after testing. Leaving it turned on can negatively impact AMP performance: [root@AMP ~]# qlog enable snmp_traps Understanding WMS Offload Impact on Aruba Infrastructure When offloading WMS, it is important to understand what functionality is migrated to AMP and what functionality is deprecated. The following ArubaOS tabs and sections are deprecated after offloading WMS: l Plan - The tab where floor plans are stored and heatmaps are generated. Prior to offloading WMS, ensure that you have exported floor plans from ArubaOS and imported them into AMP. All functionality within the Plan Tab is incorporated with the VisualRF module in AMP. l Dashboard > Security Summary - The Security Summary section (Figure 12) disappears after offloading WMS. The data is still being processed by the master controller, but the summary information is not available. You must use AMP to view data for APs, clients and events in detail and summary from. n AMP displays information on Rogue APs in the RAPIDS > Overview pages. n Information on Suspected Rogue, Interfering and known interfering APs is available in AMP on each APs/Devices > Manage page. n IDS events data and reports appear on AMP’s Reports > Generated > IDS Events page.
  • 25. Figure 12 Security Summary on the Master Controller See "Rogue Device Classification" on page 33 for more information on security, IDS, WIPS, WIDS, classification, and RAPIDS. AirWave 7.7 | Best Practices Guide Chapter 5 AMP and Aruba Integration Strategies | 25
  • 26. 26 | Chapter 5 AMP and Aruba Integration Strategies AirWave 7.7 | Best Practices Guide
  • 27. AirWave 7.7 | Best Practices Guide Chapter 6 Aruba Specific Capabilities in AMP | 27 Chapter 6 Aruba Specific Capabilities in AMP This section discusses Aruba specific capabilities in AMP and contains the following topics: l "Aruba Traps for RADIUS Auth and IDS Tracking" on page 27 l "Remote AP Monitoring" on page 28 l "ARM and Channel Utilization Information" on page 28 l "Viewing Controller License Information" on page 32 l "Rogue Device Classification" on page 33 l "Rules-Based Controller Classification" on page 35 Aruba Traps for RADIUS Auth and IDS Tracking The authentication failure traps are received by the AMP server and correlated to the proper controller, AP, and user. See Figure 13 showing all authentication failures related to a controller. You can view RADIUS authentication issues by selecting the RADIUS Authentication Issues link in the Alert Summary table. Figure 13 RADIUS Authentication Traps in AMP The IDS traps are received by the AMP server and correlated to the proper controller, AP, and user. See Figure 14 showing all IDS traps related to a controller. You can view IDS events by selecting the IDS Events link in the Alert Summary table. Figure 14 IDS Events in AMP
  • 28. 28 | Chapter 6 Aruba Specific Capabilities in AMP AirWave 7.7 | Best Practices Guide Remote AP Monitoring To monitor remote APs, follow these steps: 1. From the APs/Devices > List page, filter on the Remote Device column to find remote devices. 2. To view detailed information on the remote device, select the device name. The page illustrated in Figure 15 appears. Figure 15 Remote AP Detail Page 3. You can also see if there are users plugged into the wired interfaces in the Connected Clients list below the Clients and Usage graphs. This feature is only available when the remote APs are in split tunnel and tunnel modes. ARM and Channel Utilization Information ARM statistics and Channel utilization are very powerful tools for diagnosing capacity and other issues in your WLAN. 1. Navigate to an APs/Devices > Monitor page for any of the following: Aruba AP-105, AP-92, AP-93, AP-124, AP- 125, AP-134, or AP-135. 2. In the Radios table, select a radio link under the Name column for a radio. 3. The graphs default to Client and Usage. Select the drop down icon for each to change these to Radio Channel and Channel Utilization.
  • 29. Figure 16 ARM and Channel Utilization Graphs See the AirWave 7.7 User Guide in Home > Documentation for more information on the data that displays in the Radio Statistics page for these devices. VisualRF and Channel Utilization To view how channel utilization is impacting an area within a building, follow these steps: 1. Navigate to a floor plan by clicking on the thumbnail on a device’s APs/Devices > Monitor page or navigating to VisualRF > Floor Plans page. 2. Select the Overlays menu. 3. Select the Ch. Utilization overlay. 4. Select Current or Maximum (over last 24 hours). l If Maximum is selected, then use the drop down menu to select total (default), receive (RX), transmit (TX), or interference (Int.). 5. Select to view information for the current floor, the floor above, and/or the floor below. 6. Select a frequency of 5 GHz and/or 2.4 GHz. AirWave 7.7 | Best Practices Guide Chapter 6 Aruba Specific Capabilities in AMP | 29
  • 30. 30 | Chapter 6 Aruba Specific Capabilities in AMP AirWave 7.7 | Best Practices Guide Figure 17 Channel Utilization in VisualRF (Interference/2.4 GHz) Configuring Channel Utilization Triggers 1. Navigate to System > Triggers and select Add. 2. Select Channel Utilization from the Type drop-down menu as seen on Figure 18:
  • 31. Figure 18 Channel Utilization Trigger 3. Enter the duration evaluation period. 4. Click the Add New Trigger Condition button. 5. Create a trigger condition for Radio Type and select the frequency to evaluate. 6. Select total, receive, transmit, or interference trigger condition. 7. Set up any restrictions or notifications. (Refer to the AirWave 7.7 User Guide in Home > Documentation for more details.) 8. When you are finished, click Add. Viewing Channel Utilization Alerts You can view Channel Utilization alerts from the APs/Devices > Monitor page and on the System > Alerts page. Channel Utilization Alerts on the APs/Devices > Monitor Page 1. Navigate to APs/Devices > Monitor page for a selected device. AirWave 7.7 | Best Practices Guide Chapter 6 Aruba Specific Capabilities in AMP | 31
  • 32. 32 | Chapter 6 Aruba Specific Capabilities in AMP AirWave 7.7 | Best Practices Guide 2. Scroll down to the Alert Summary page and select AMP Alerts. Figure 19 Channel Utilization alerts Channel Utilization Alerts on the System > Alerts Page 1. Navigate to the System > Alerts page. 2. Sort the Trigger Type column and find Channel Utilization alerts. Figure 20 Channel Utilization alerts on the System > Alerts page View Channel Utilization in RF Health Reports 1. Navigate to Reports > Generated. 2. Find and select an RF Health report. 3. Scroll down to view most and least utilized 2.4 and 5 channel usage information. Figure 21 Channel Utilization in an RF Health Report (partial view) Viewing Controller License Information Follow these steps to view your controller’s license information in AMP: 1. Navigate to the APs/Devices > Monitor page of a controller. 2. Select the Licenses link in the Device Info section. A pop-up window appears listing all licenses.
  • 33. Figure 22 License Popup from APs/Devices > Monitor page a controller Rogue Device Classification Complete this section if you have completed WMS Offload procedure above. After offloading WMS, AMP maintains the primary ARM, WIPS, and WIDS state classification for all devices discovered over-the-air. AMP Controller Classification ArubaOS (WIPS/WIDS) Unclassified (default state) Unknown Valid Valid Suspected Valid Suspected Valid Suspected Neighbor Interfering Neighbor Known Interfering Suspected Rogue Suspected Rogue Rogue Rogue Contained Rogue DOS Table 3: WIPS/WIDS to AMP ControllerClassification Matrix To check and reclassify rogue devices, follow these steps: 1. Navigate to the RAPIDS > Detail page for a rogue device, as shown in the following figure. 2. Select the proper classification from the RAPIDS Classification Override drop-down menu. Figure 23 Rogue Detail Page Illustration Changing the controller's classification within the AMP UI will push a reclassification message to all controllers managed by the AMP server that are in Groups with Offloading the WMS database set to Yes. To reset the controller classification of a rogue device on AMP, change the controller classification on the AMP UI to unclassified. AirWave 7.7 | Best Practices Guide Chapter 6 Aruba Specific Capabilities in AMP | 33
  • 34. 34 | Chapter 6 Aruba Specific Capabilities in AMP AirWave 7.7 | Best Practices Guide Controller classification can also be updated from RAPIDS > List via the Modify Devices link. All rogue devices will be set to a default controller classification of unclassified when WMS is first offloaded except for devices classified as valid. Rogue devices classified in ArubaOS as valid will also be classified within AMP as valid for their controller classification as well. As APs report subsequent classification information about rogues, this classification will be reflected within AMP UI and propagated to controllers that AMP manages. The device classification reflected in the controller's UI and in the AMP UI will probably not match, because the controller/APs do not reclassify rogue devices frequently. To update a group of devices' controller classification to match the ArubaOS device classification, navigate to RAPIDS > List and utilize the Modify Devices checkbox combined with the multiple sorting a filtering features. AMP AOS (ARM) Unclassified (default state) Unknown Valid Valid Contained DOS Table 4: ARM to AMP Classification Matrix 1. Navigate to the Clients > Client Detail page for the user. 2. In the Device Info section, select the proper classification from the Classification drop-down menu as seen in Figure 24: Figure 24 User Classification Changing User Classification within the AMP UI will push a user reclassification message to all controllers managed by the AMP server that are in Groups with Offloading the WMS database set to Yes. All users will be set to a default classification of unclassified when WMS is first offloaded. As APs report subsequent classification information about users, this classification will be reflected within the AMP UI and propagated to controllers that AMP manages. It is probable that the user’s classification reflected in the controller’s UI and in the AMP UI will not match, because the controllers/APs do not reclassify users frequently.
  • 35. There is no method in the AMP UI to update user classification on mass to match the controller’s classification. Each client must be updated individually within the AMP UI. Rules-Based Controller Classification Using RAPIDS Defaults for Controller Classification To use the controller's classification as RAPIDS classification, follow these steps: 1. Navigate to the RAPIDS > Rules page and select the pencil icon beside the rule that you want to change. 2. In the Classification drop-down menu, select Use Controller Classification as seen in Figure 25. Figure 25 Using Controller Classification 3. Click Save when you are done. Changing RAPIDS based on Controller Classification 1. Navigate to RAPIDS > Rules and select the desired rule. 2. In the Classification drop-down menu, select desired RAPIDS classification. 3. Select Controller Classification from the drop-down menu, as shown in Figure 26. AirWave 7.7 | Best Practices Guide Chapter 6 Aruba Specific Capabilities in AMP | 35
  • 36. 36 | Chapter 6 Aruba Specific Capabilities in AMP AirWave 7.7 | Best Practices Guide Figure 26 Configure Rules for Classification 4. Click Add. 5. A new Controller Classification field displays. Select the desired controller classification to use as an evaluation in RAPIDS. 6. Click Save.
  • 37. AirWave 7.7 | Best Practices Guide Appendix A ArubaOS and AMP CLI Commands | 37 Appendix A ArubaOS and AMP CLI Commands Enable Channel Utilization Events Enabling these commands on ArubaOS versions prior to 6.1 can result in performance issues on the controller. To enable channel utilization events utilizing the ArubaOS CLI, use SSH to access a local or master controller’s command-line interface, enter enable mode, and issue the following commands: (Controller-Name) # configure terminal Enter Configuration commands, one per line. End with CNTL/Z (Controller-Name) (config) # mgmt-server type amp primary-server <AMP IP> (Controller-Name) (config) # write mem Enable Stats With the ArubaOS CLI The following commands enable collection of statistics (up to 25,000 entries) on the master controller for monitored APs and clients. Do not use these commands if you use the AMP GUI to monitor APs and Clients. Enabling these commands on ArubaOS versions prior to 6.1 can result in performance issues on the controller. Use SSH to access the master controller’s command-line interface, enter enable mode, and issue the following commands: (Controller-Name) # configure terminal Enter Configuration commands, one per line. End with CNTL/Z (Controller-Name) (config) # ids wms-general-profile collect-stats enable (Controller-Name) (config-ids-wms-general-profile) # collect-stats (Controller-Name) (config-ids-wms-general-profile) # exit (Controller-Name) (config) # write mem Offload WMS Using the ArubaOS or AMP CLI Do not use these commands if you use the AMP GUI to monitor APs and clients. Additional commands can be used to offload WMS using the ArubaOS command-line interface or the AMP SNMP Walk. Refer to: "ArubaOS CLI" on page 37 "AMP SNMP " on page 38 ArubaOS CLI SSH into all controllers (local and master), and enter enable mode, and issue the following commands: (Controller-Name) # configure terminal
  • 38. 38 | Appendix A ArubaOS and AMP CLI Commands AirWave 7.7 | Best Practices Guide Enter Configuration commands, one per line. End with CNTL/Z (Controller-Name) (config) # mobility-manager <AMP IP> user <MMS-USER> <MMS-SNMP-PASSWORD> (Controller-Name) (config) # write mem This command creates an SNMPv3 user on the controller with the authentication protocol configured to SHA and privacy protocol DES. The user and password must be at least eight characters because the Net-SNMP package in AMP adheres to this IETF recommendation. ArubaOS automatically creates Auth and Privacy passwords from this single password. If mobility-manager is already using a preconfigured SNMPv3 user, ensure the privacy and authentication passwords are the same. Example: mobility-manager 10.2.32.1 user airwave123 airwave123 AMP SNMP Log in into the AMP server with proper administrative access and issue the following command for all controllers (master and locals): [root@AMP ~]# snmpwalk -v3 -a SHA -l AuthPriv -u <MMS-USER> -A <MMS-SNMP-PASSWORD> -X <MMS-SNMP- PASSWORD> <Controller-IP> wlsxSystemExtGroup WLSX-SYSTEMEXT-MIB::wlsxSysExtSwitchIp.0 = IpAddress: 10.51.5.222 WLSX-SYSTEMEXT-MIB::wlsxSysExtHostname.0 = STRING: aruba-3600-2 . .. WLSX-SYSTEMEXT-MIB::wlsxSysExtSwitchLastReload.0 = STRING: User reboot. WLSX-SYSTEMEXT-MIB::wlsxSysExtLastStatsReset.0 = Timeticks: (0) 0:00:00.00 response [root@AMP ~]# Unless this SNMP walk command is issued properly on all of the controllers, they will not properly populate client and rogue statistics. Ensure the user and passwords match exactly to those entered in above sections. Example: snmpwalk -v3 -a SHA -l AuthPriv -u airwave123 -A airwave123 -X airwave123 10.51.3.222 wlsxSyste mExtGroup If you do not use the AMP WebUI to offload WMS, you must add a cronjob on the AMP server to ensure continued statistical population. Because the MIB walk/touch does not persist through a controller reboot, a cronjob is required to continually walk and touch the MIB. Pushing Configs from Master to Local Controllers Use the following ArubaOS CLI commands to ensure that the master controller is properly pushing configuration settings from the master controller to local controllers. This command ensures configuration changes made on the master controller will propagate to all local controllers. Do not use these commands if you use the AMP GUI to monitor APs and clients. (Controller-Name) (config) # cfgm mms config disable (Controller-Name) (config) # write mem Disable Debugging Utilizing the ArubaOS CLI If you are experiencing performance issues on the master controller, ensure that debugging is disabled. It should be disabled by default. Debugging coupled with gathering the enhanced statistics can put a strain on the controller's CPU,
  • 39. so it is highly recommended to disable debugging. To disable debugging, SSH into the controller, enter enable mode, and issue the following commands: (Controller-Name) # show running-config | include logging level debugging If there is output, then use the following commands to remove the debugging: (Controller-Name) # configure terminal Enter Configuration commands, one per line. End with CNTL/Z (Controller-Name) (config) # no logging level debugging <module from above> (Controller-Name) (config) # write mem Restart WMS on Local Controllers To ensure local controllers are populating rogue information properly, use SSH to access the command-line interface of each local controller, enter enable mode, and issue the following commands: (Controller-Name) # configure terminal Enter Configuration commands, one per line. End with CNTL/Z (Controller-Name) (config) # process restart wms After executing the restart wms command in ArubaOS, you will need to wait until the next Rogue Poll Period on AMP and execute a Poll Now operation for each local controller on the APs/Devices > List page before rogue devices begin to appear in AMP. Configure ArubaOS CLI when not Offloading WMS To ensure proper event correlation for IDS events when WMS is not offloaded to AMP, access the command line interface of each controller (master and local), enter enable mode, and issue the following commands: (Controller-Name) # configure terminal Enter Configuration commands, one per line. End with CNTL/Z (Controller-Name) (config) # ids management-profile (Controller-Name) (config) # ids general-profile <name> (Controller-Name) (config) # ids-events logs-and-traps (Controller-Name) (config) # write mem Copy and Paste to Enable Proper Traps with the ArubaOS CLI To ensure the proper traps are configured on Aruba controllers, copy and paste the following command in config mode: snmp-server trap enable wlsxNUserAuthenticationFailed snmp-server trap enable wlsxUserAuthenticationFailed snmp-server trap enable wlsxNAuthServerReqTimedOut snmp-server trap enable wlsxSignatureMatchAP snmp-server trap enable wlsxSignatureMatchSta snmp-server trap enable wlsxSignAPNetstumbler snmp-server trap enable wlsxSignStaNetstumbler snmp-server trap enable wlsxSignAPAsleap snmp-server trap enable wlsxSignStaAsleap snmp-server trap enable wlsxSignAPAirjack snmp-server trap enable wlsxSignStaAirjack snmp-server trap enable wlsxSignAPNullProbeResp snmp-server trap enable wlsxSignStaNullProbeResp snmp-server trap enable wlsxSignAPDeauthBcast snmp-server trap enable wlsxSignStaDeauthBcastwlsxChannelFrameErrorRateExceeded snmp-server trap enable wlsxChannelFrameFragmentationRateExceeded snmp-server trap enable wlsxChannelFrameRetryRateExceeded AirWave 7.7 | Best Practices Guide Appendix A ArubaOS and AMP CLI Commands | 39
  • 40. 40 | Appendix A ArubaOS and AMP CLI Commands AirWave 7.7 | Best Practices Guide snmp-server trap enable wlsxNIpSpoofingDetected snmp-server trap enable wlsxStaImpersonation snmp-server trap enable wlsxReservedChannelViolation snmp-server trap enable wlsxValidSSIDViolation snmp-server trap enable wlsxStaPolicyViolation snmp-server trap enable wlsxRepeatWEPIVViolation snmp-server trap enable wlsxWeakWEPIVViolation snmp-server trap enable wlsxFrameRetryRateExceeded snmp-server trap enable wlsxFrameReceiveErrorRateExceeded snmp-server trap enable wlsxFrameFragmentationRateExceeded snmp-server trap enable wlsxFrameBandWidthRateExceeded snmp-server trap enable wlsxFrameLowSpeedRateExceeded snmp-server trap enable wlsxFrameNonUnicastRateExceeded snmp-server trap enable wlsxChannelRateAnomaly snmp-server trap enable wlsxNodeRateAnomalyAP snmp-server trap enable wlsxNodeRateAnomalySta snmp-server trap enable wlsxEAPRateAnomaly snmp-server trap enable wlsxSignalAnomaly snmp-server trap enable wlsxSequenceNumberAnomalyAP snmp-server trap enable wlsxSequenceNumberAnomalySta snmp-server trap enable wlsxApFloodAttack snmp-server trap enable wlsxInvalidMacOUIAP snmp-server trap enable wlsxInvalidMacOUISta snmp-server trap enable wlsxStaRepeatWEPIVViolation snmp-server trap enable wlsxStaWeakWEPIVViolation snmp-server trap enable wlsxStaAssociatedToUnsecureAP snmp-server trap enable wlsxStaUnAssociatedFromUnsecureAP snmp-server trap enable wlsxAPImpersonation snmp-server trap enable wlsxDisconnectStationAttackAP snmp-server trap enable wlsxDisconnectStationAttackSta You will need to issue the write mem command.
  • 41. AirWave 7.7 | Best Practices Guide Appendix B AMP Data Acquisition Methods | 41 Appendix B AMP Data Acquisition Methods The following table describes the different methods through which AMP acquires data from Aruba devices on the network. Data Elements Controller/Thin AP Aruba Instant SNMP MIB SNMP Traps AMON CLI/SSH WMS Offload RTLS HTTPS Configuration interface Device configuration/audit X X User and client interfaces Assoc/auth/roam X X X Bandwidth X X Signal quality X X X Auth failures X N/A AP/radio interfaces CPU And memory utilization <--------------------------------N/A----------------------------------------> X Bandwidth X X Transmit Power X X Channel utilization X X Noise floor X Frame rates X X Error counters X X Channel summary X N/A ARM events X N/A Active interferers X N/A Table 5: Methods by which AMP Acquires Data from Aruba Devices
  • 42. 42 | Appendix B AMP Data Acquisition Methods AirWave 7.7 | Best Practices Guide Data Elements Controller/Thin AP Aruba Instant Active BSSIDs/SSIDs X X Security IDS events X N/A Neighbors/rogues X X X Neighbor re-classification X X N/A Client classification X N/A User deauthorization X N/A
  • 43. AirWave 7.7 | Best Practices Guide Appendix C WMS Offload Details | 43 Appendix C WMS Offload Details WMS Offload instructs the master controller to stop correlating ARM, WIPS, and WIDS state information amongst its local controllers because AMP will assume this responsibility. Figure 27 depicts how AMPcommunicates state information with local controllers. Figure 27 ARM/WIPS/WIDS Classification Message Workflow State Correlation Process 1. AP-1-3-1 hears rogue device A. 2. Local controller 1-3 evaluates devices and does initial classification and sends a classification request to AMP. 3. AMP receives message and re-classifies the device if necessary and reflects this within the AMP GUI and via SNMP traps, if configured. 4. AMP sends a classification message back to all local controllers managed by master controller 1, (1-1, 1-2, and 1-3). 5. AMP sends a classification message back to all additional local controllers managed by theAMP server. In this example all local controllers under master controller 2, (2-1, 2-2, and 2-3) would receive the classification messages. 6. If an administrative AMP user manually overrides the classification, then AMP will send a re-classification message to all applicable local controllers. 7. AMP periodically polls each local controller's MIB to ensure state parity with the AMP database. If the local controller's device state does not comply with the AMP database, AMP will send a re-classification message to bring it back into compliance. The Rogue Detail page includes a BSSID table for each rogue that displays the desired classification and the classification on the device. Using AMP as a Master Device State Manager AMP offers the following benefits as a master device state manager:
  • 44. 44 | Appendix C WMS Offload Details AirWave 7.7 | Best Practices Guide l Ability to correlate state among multiple master controllers. This will reduce delays in containing a rogue device or authorizing a valid device when devices roam across a large campus. l Ability to correlate state of third party access points with ARM. This will ensure that Aruba infrastructure inter- operates more efficiently in a mixed infrastructure environment. l Ability to better classify devices based on AMP wire-line information not currently available in ArubaOS. l AMP provides a near real-time event notification and classification of new devices entering air space. l RAPIDS gains additional wire-line discovery data from Aruba controllers.
  • 45. AirWave 7.7 | Best Practices Guide Appendix D Increasing Location Accuracy | 45 Appendix D Increasing Location Accuracy This section describes the impact that band steering can have on location accuracy. It also explains how RTLS can be used to increase location accuracy. Understand Band Steering's Impact on Location Band steering can negatively impact location accuracy when testing in highly mobile environment. The biggest hurdle is scanning times in 5 GHz frequency. Operating Frequency Total Channels Scanning Frequency Scanning Time Total Time One Pass 2.4 GHz 11 (US) 10 seconds 110 milliseconds 121.21 seconds 5 GHz 24 (US) 10 seconds 110 milliseconds 242.64 seconds Table 6: Location accuracy impact Leveraging RTLS to Increase Accuracy This section provides instructions for integrating the AMP and Aruba WLAN infrastructure with Aruba's RTLS feed to more accurately locate wireless clients and Wi-Fi Tags. Prerequisites You will need the following information to monitor and manage your Aruba infrastructure. l Ensure that the AMP server is already monitoring Aruba infrastructure. l Ensure that the WMS Offload process is complete. l Ensure that the firewall configuration for port 5050 (default port) supports bidirectional UDP communication between the AMP server's IP address and each access point's IP address.
  • 46. 46 | Appendix D Increasing Location Accuracy AirWave 7.7 | Best Practices Guide Deployment Topology Figure 28 Typical Client Location Figure 29 Typical Tag Deployment Enable RTLS Service on the AMP Server To enable RTLS service on the AMP server, follow these steps: 1. Navigate to AMP Setup > General and locate the Additional AMP Services section 2. Select Yes for the Enable RTLS Collector option. 3. A new section will automatically appear with the following settings: l RTLS Port - the match controller default is 5050 l RTLS Username - This must match the SNMPv3 MMS username configured on the controller. l RTLS Password - This must match the SNMPv3 MMS password configured on the controller.
  • 47. Figure 30 RTLS Fields in AMP Setup> General 4. Click Save at the bottom of the page when you are done. Enable RTLS on the Controller RTLS can only be enabled on the master controller and it will automatically propagate to all local controllers. SSH into master controller, enter enable mode, and issue the following commands: (Controller-Name) # configure terminal Enter Configuration commands, one per line. End with CNTL/Z (Controller-Name) (config) # ap system-profile <Thin-AP-Profile-Name> (Controller-Name) (AP system profile default) # rtls-server ip-addr <IP of AMP Server> port 5050 key <Controller-SNMPv3-MMS-Password> (Controller-Name) (AP system profile default) # write mem To validate exit configuration mode: (Controller-Name) # show ap monitor debug status ip-addr <AP-IP-Address> ... RTLS configuration ------------------- Type Server IP Port Frequency Active ---- --------- ---- --------- ------ MMS 10.51.2.45 5070 120 Aeroscout N/A N/A N/A RTLS 10.51.2.45 5050 60 * AirWave 7.7 | Best Practices Guide Appendix D Increasing Location Accuracy | 47
  • 48. 48 | Appendix D Increasing Location Accuracy AirWave 7.7 | Best Practices Guide Troubleshooting RTLS You can use either the WebUI or CLI to ensure the RTLS service is running on your AMP server. Using the WebUI In the AMP WebUI, navigate to the System > Status page. Scroll down through the Services list to locate the RTLS service, as shown below. Figure 31 RTLS System Status Using the CLI Use SSH to access the command-line interface of your AMP server, and issue the following commands: [root@AMPServer]# daemons | grep RTLS root 17859 12809 0 10:35 ? 00:00:00 Daemon::RTLS Issue the logs and tail rtls commands to check the RTLS log file and verify that Tag chirps are making it to the AMP server. [root@AMPServer]# logs [root@AMPServer]# tail rtls payload: 00147aaf01000020001a1ec02b3200000001000000137aae0100000c001a1ec02b320000001a1e82b322 590006ddff02 1224534900.588245 - got 96 bytes from 10.51.1.39 on port 5050 Mon Oct 20 13:35:00 2008: 1224534900.588338 - got 96 bytes from 10.51.1.39 on port 5050 payload: 0014c9c90100003c001a1ec050780000000200000013c9c70100000c001a1ec050780000000d54a7a280 540001ddff020013c9c80100000c001a1ec050780000000cdb8ae9a9000006c4ff02 1224534900.588245 - got 96 bytes from 10.51.1.39 on port 5050 Mon Oct 20 13:35:00 2008: 1224534900.588338 - got 96 bytes from 10.51.1.39 on port 5050 payload: 0014c9c90100003c001a1ec050780000000200000013c9c70100000c001a1ec050780000000d54a7a280 540001ddff020013c9c80100000c001a1ec050780000000cdb8ae9a9000006c4ff02 Ensure chirps are published to Airbus by snooping on RTLS tag reports. [root@AMPServer]# airbus_snoop rtls_tag_report Snooping on rtls_tag_report: Mon Oct 20 13:49:03 2008 (1224535743.54077) % ap_mac => 00:1A:1E:C0:50:78 battery => 0 bssid => 00:1A:1E:85:07:80 channel => 1 data_rate => 2 noise_floor => 85 payload =>
  • 49. rssi => -64 tag_mac => 00:14:7E:00:4C:E4 timestamp => 303139810 tx_power => 19 Verify external applications can see WiFi Tag information by exercising the Tag XML API: https://<AMP-Server-IP>/visualrf/rfid.xml You should see the following XML output: <visualrf:rfids version=1> <rfid battery-level=0 chirp-interval= radio-mac=00:14:7E:00:4C:E0 vendor=> <radio phy=g xmit-dbm=10.0/> <discovering-radio ap=SC-MB-03-AP10 dBm=-91 id=811 index=1 timestamp=2008-10-21T12:23:30-04:00/> <discovering-radio ap=SC-MB-03-AP06 dBm=-81 id=769 index=1 timestamp=2008-10-21T12:23:31-04:00/> <discovering-radio ap=SC-MB-01-AP06 dBm=-63 id=708 index=1 timestamp=2008-10-21T12:23:31-04:00/> <discovering-radio ap=SC-MB-02-AP04 dBm=-88 id=806 index=1 timestamp=2008-10-21T12:22:34-04:00/> </rfid> <rfid battery-level=0 chirp-interval= radio-mac=00:14:7E:00:4B:5C vendor=> <radio phy=g xmit-dbm=10.0/> <discovering-radio ap=SC-MB-03-AP06 dBm=-74 id=769 index=1 timestamp=2008-10-21T12:23:20-04:00/> <discovering-radio ap=SC-MB-01-AP06 dBm=-58 id=708 index=1 timestamp=2008-10-21T12:23:20-04:00/> <discovering-radio ap=SC-MB-03-AP02 dBm=-91 id=734 index=1 timestamp=2008-10-21T12:23:20-04:00/> </rfid> <rfid battery-level=0 chirp-interval= radio-mac=00:14:7E:00:4D:06 vendor=> <radio phy=g xmit-dbm=10.0/> <discovering-radio ap=SC-SB-GR-AP04 dBm=-91 id=837 index=1 timestamp=2008-10-21T12:21:08-04:00/> <discovering-radio ap=SC-MB-03-AP06 dBm=-79 id=769 index=1 timestamp=2008-10-21T12:22:08-04:00/> <discovering-radio ap=SC-MB-01-AP06 dBm=-59 id=708 index=1 timestamp=2008-10-21T12:23:08-04:00/> <discovering-radio ap=SC-MB-02-AP04 dBm=-90 id=806 index=1 timestamp=2008-10-21T12:22:08-04:00/> </rfid> </visualrf:rfids> Wi-Fi Tag Setup Guidelines l Ensure that the tags can be heard by at least three (3) access points from any given location. The recommended value is is 4 APs. l Ensure that the tags chirp on all regulatory channels. AirWave 7.7 | Best Practices Guide Appendix D Increasing Location Accuracy | 49
  • 50. 50 | Appendix D Increasing Location Accuracy AirWave 7.7 | Best Practices Guide