Additional Commands and Features

Access Point

The Wifi Collector handles AP migrations in two ways (can be set using the flag UPDATE_UNAVAILABLE_APS).

1. Update all the unavailable Access Points - UPDATE_UNAVAILABLE_APS = true.
   • All the access points are pinned to their WLC specific device group. So if during a poll, the WLC does not poll an Access Point device, all the indicators for that Access Point device will be set to zero (including its availability and WLC tracking id), its WLC name in Metadata and description will be set to unknown. No values will be plotted in the next polls till the Access Point data is received from the WLC or another WLC.
   • A policy has been created named Unavailable AP devices (Unavailable APs set to zero) which is not enabled by default. It raises an alert whenever availability of an Access Point device goes to zero in the past TIME_SINCE_AP_UNAVAILABLE seconds.
   • This policy does not handle Access Point migrations from one WLC to another. For example, if the Access Point migrates from WLC 1 to WLC 2 and if WLC 1 is polled first, the zero value for Access Point will be plotted and then, when it runs for WLC 2, the availability will become 100% again but the alert will still be generated.
2. Do not update the Access Points - UPDATE_UNAVAILABLE_APS = false
   • The access point will not be updated if they are not polled from the WLC. Only the values for the Access Points received from the WLC will be updated.
   • A policy has been created named Unavailable AP devices (Time since newest data point) which is not enabled by default. It raises an alert when the Access Point device's availability indicator does not receive any data for the past TIME_SINCE_AP_UNAVAILABLE seconds.

NOTE: Both the unavailable AP Policies get created the first time collector is installed and then they are not updated by the collector, the user needs to manually change these policies if required. Also, these policies are not enabled by default; user must enable them.

Self-Monitoring Device
WiFi Selfmon: Polling duration is more than polling cycle

• During the collector installation, a policy WiFi Selfmon: Polling duration is more than polling cycle is created for a WiFi Selfmon device's indicator. By default, it is disabled. If enabled, it creates an alert for the respective object if the newly created indicator, container_run_time, exceeds the base limit of 300 seconds.
• To generate this alert, please ensure that SELF_MONITORING environment variable in cisco.env | aruba.env files is set to true.

Controller
WiFi Controller: APs skipped due to error

• Collector skips APs when name or MAC address is not valid. The count of skipped APs is displayed as an indicator ap_skipped under the Wifi Controller device.
• A policy Wifi Controller: APs skipped due to error triggers a Critical alert when the count of skipped APs becomes > 0 for more than past 1 minute. It clears an alert when the count becomes 0 for the past 1 minute. By default, the policy remains disabled.

You may remove all the deprecated Objects that were used prior to Wifi 2.3.0 release.

The user can change the following variables in /opt/WLCCollector/configuration/<vendor>.env before running the cleanup script.

Execute the steps below to perform the cleanup.

1. Manually run the cleanup script.

   $ /opt/WLCCollector/wlccmd.sh v6.7.0-build.12 task delete_depreciated_objects <vendor> &>> /var/log/wifi-wlc/delete_depreciated_objects.log
   

2. Inspect the log file, /var/log/wifi-wlc/delete_depreciated_objects.log.
3. Confirm the list of objects to be deleted in /opt/WLCCollector/configuration/depreciated_objects.json.
4. When ready to delete the Objects, using a text editor of your choice, edit /opt/WLCCollector/configuration/<vendor>.env file and add the following variables to it.

   DEL_DEP_OBJECTS=true
   DEP_DEL_FILE=depredicated_objects.json
   

5. Run the following script.

   $ /opt/WLCCollector/wlccmd.sh v6.7.0-build.12 task delete_depreciated_objects <vendor> &>> /var/log/wifi-wlc/delete_depreciated_objects.log
   

6. Inspect /var/log/wifi-wlc/delete_depreciated_objects.log to confirm the Objects have been deleted.
7. Using a text editor of your choice, edit /opt/WLCCollector/configuration/<vendor>.env and remove the following variables from it.

   DEL_DEP_OBJECTS=true
   DEP_DEL_FILE=depredicated_objects.json
   

8. Rediscover the affected WLCs in SevOne NMS to trigger an immediate removal of the deleted Objects.

INFO: wlccmd.sh script will run and remove the deprecated Objects of the current peer's devices only. And current peer will be identified by SEVONE_API_HOST in vendor.env file.

NOTE: wlccmd.sh script is vendor specific. It will collect deprecated Objects for that particular vendor. The Wifi 2.3.x collector should have run at least once before running this script.

Using the text editor of your choice, edit /opt/WLCCollector/configuration/disable_config.json configuration file to cleanup inactive Wifi Station license(s).

INFO: Cleanup of inactive Wifi Station license(s) is optional but highly recommended. This allows the customer to conserve Object licenses consumed by transient workstations that are discovered but either disappear or remain inactive for a long time. For example, Wifi Stations belonging to guest(s) visiting a campus.

{"SevOne": 168, "SevOne-guest": 48}

This specifies the time related to SSID (SevOne, SevOne-guest) in hours, for deleting inactive objects.

The user can change the following variables in /opt/WLCCollector/configuration/cisco.env before running the cleanup script.

$ /opt/WLCCollector/wlccmd.sh v6.7.0-build.12 task disable_objects cisco &>> /var/log/wifi-wlc/disable_objects.log

This script will run and remove inactive station's Objects of the current peer's devices only. And current peer will be identified by SEVONE_API_HOST in vendor.env file.

You may automate the process to run periodically by adding a following new cron task in wifi-cron-delete-stations file according to the lowest time. In the format example above, 48 (hours) means cleanup in every two days.

$ /etc/cron.d/wifi-cron-delete-stations

0 0 */2 * * root [[ $(cat /SevOne.masterslave.master) -ne '0' ]] && /opt/WLCCollector/wlccmd.sh v6.7.0-build.12 task disable_objects cisco &>> /var/log/wifi-wlc/disable_objects.log

The script is not vendor specific, it will collect unused station objects for both the vendors.

The user can change the following variables in /opt/WLCCollector/configuration/<cisco | aruba>.env before running the cleanup script.

Cleanup of AP audit logs is optional but highly recommended. Otherwise, it may create an overload on SevOne NMS when there are too many logs over a long period of time.

Now, you may manually run the cleanup script.

$ /opt/WLCCollector/wlccmd.sh
v6.7.0-build.12 task delete_audit_logs <cisco | aruba> &>>
/var/log/wifi-wlc/delete_audit_logs_<cisco | aruba>.log

This script will run and remove audit logs of the current peer's devices only. Also, the current peer will be identified by SEVONE_API_HOST in vendor.env file.

$ /etc/cron.d/wifi-cron-delete-audit-logs

0 0 */2 * * root [[ $(cat /SevOne.masterslave.master) -ne '0' ]] && /opt/WLCCollector/wlccmd.sh v6.7.0-build.12 task delete_audit_logs cisco &>> /var/log/wifi-wlc/delete_audit_logs_<cisco | aruba>.log

The steps in this section apply to new installation from scratch only. The devices must be discovered prior to the installation.

1. Ensure that the WLC devices have already been created and discovered. If not, create the devices and discover those devices.
2. From SevOne NMS appliance, go to Devices > Device Manager to show all the devices.
3. Click on Add device to create a new device or select an existing device in the list and click on to edit the device.
4. Enter the values in the following fields for the device being added/edited.
   1. Name (device name)
   2. IP Address

   Please refrain from using \ , / , <</b>, >, | in WLC device names.

5. In the SNMP section, SNMP Capable must be enabled and enter the values in the following fields.
   1. Port
   2. Read Community String (for SNMP v2)
   3. Username (for SNMP v3)
   4. Password (for SNMP v3)
   5. Authentication Type (for SNMP v3)
   6. Encryption Type (for SNMP v3)
   7. Encryption Key (for SNMP v3)
6. Click the SNMP dropdown and choose Deferred Data.
7. Allow scripts to import data must be enabled for all devices to collect WLC data.
8. Device(s) are now ready to be pinned to vendor specific device groups. Click the Devices menu, select Grouping and choose Device Groups . Pin or unpin devices as desired to the vendor specific Device Group . More than one device group can be created for the vendor and the device group can be a nested structure or directly under "All Device Groups" . This allows you to run more than one container working with the specific devices for the corresponding group. For example, click on WLC Aruba . Under Membership , click on Pin Devices . Pin Devices screen will pop-up. Choose Aruba WLC device . Click on Pin to Group . You have now pinned Aruba WLC device to group WLC Aruba.

   The user can also use a nested device group structure like the following which also helps the collector run in multi container mode. In the below example the user has put all the WLCs under All Device Groups - > DG1 - > WLCs . There are two device groups under this hierarchy one for each vendor (Aruba and Cisco). Here all the WLCs for Aruba would be pinned under Aruba device group and the collector would run in single container mode collecting data for all Aruba WLCs in one container, while for Cisco the WLCs are stored under two device groups (NYC and Boston) for which the collector will run in multi container mode spinning up two containers one each for NYC and Boston.

   • Please use alphanumeric characters , underscores , period , dashes (i.e. a-zA-Z0-9\_.-), and space only while creating Device Group names.
   • If a device group named Wifi exists under All Device Groups before the installation, please delete / rename the device group to allow the collector to create the device group for its internal purposes.
   • Moving WLCs around in device groups used for polling data does not affect the data collection.
   • To stop showing the same Access Points (APs) under the Discovery Queue , please take care of the following points.
     • You MUST not create duplicate WLCs in the collector polling group.
     • If the same AP is reported by multiple WLCs, you MUST remove it from all except one of the WLCs.
   • Aruba IAP devices must be pinned in a separate device group than the Aruba Enterprise devices.

   When a new WLC is being added to SevOne NMS, pin the device to the appropriate Device Group. It will be considered in the next collector run.

Perform the following steps to pin wifi stations on SevOne NMS.

1. From SevOne NMS appliance, click the Devices menu, select Grouping , and then select Object Groups .
2. Ensure that the Wifi Station Monitor object group is available in the list of Object Groups under the Wifi class.
3. To pin stations to the Wifi Station Monitor object group, click Pin Objects to display the Pin Objects pop-up.
   1. Click the Device drop-down and look for devices named WiFi Stations - mfg:<manufacturer name> in the list of available devices.
   2. Select any manufacturer device to display its objects.
   3. Select one or more objects related to the manufacturer device selected in order to pin them to the object group.
   4. Click Pin to Group to pin the objects selected to the object group.
4. You have now pinned objects selected to the object group Wifi Station Monitor.

The table contains the list of all environment files and the environment variables it stores.

Please ensure that the values for the environment variables are not in quotes.
Also, the format for defining these environment variables must be <variable name>=<value>. There must be no spaces.
Initially, the cisco.env | aruba.env files may not contain all the environment variables. User must add the environment variables in the respective files required for their deployment setup.

To start the collector, execute the following commands.

1. Change directory to the path where the tar file was extracted.

   $ cd <path where tar was extracted>
   

2. Run the following command where <vendor name> can be cisco or aruba.

   $ ./install.sh run --vendor <vendor name>
   

To stop the collector, remove or comment out the crons from /etc/cron.d/wifi-cron-<vendor name> where <vendor name> can be cisco or aruba.