Wireless AP Monitoring Enhancements

This is a pretty old post, but a lot of it is still relevant. The current state of Wireless monitoring needs to be reviewed and reinvented (IMHO).

The list of requests above, a new one, and my adds:

• Make Machine Type of access point, the actual Machine Type and not the Machine Type of the Wireless Controller.
  • This still has not been addressed
• Make Access points manageable objects without license penalty which can be individually added to a Network Atlas Map. Not just adding an Access point as an ICMP node without advanced information such as clients, RSSI, etc.
  • This is being somewhat addressed with the Heatmaps. I believe Heatmaps could also be improved, but all those requests are in various FRs already.
• Create custom properties for each access point so I can enter custom details about the Access Point like location information.
  • At least in Cisco-land, there is a description field in the controller for each AP, can this info be pulled in without creating a custom field? Although, custom fields on APs could also be very helpful for so many other reasons.
• Access point visibility on switches.
  • Unless the device is actually a monitored element in NPM, you can't get the connection info...this request is directly related to "Make Access points manageable objects" above
• Create Dependency where access point has a Parent of the switch to which it is attached. (courtesy of cbaser)
  • Also related to "Make Access points manageable objects" above since only a monitored element can be included in a dependency setup
• Similar to the DNS redundancy configuration in IPAM, can we add "redundant" WLCs? This way when an AP moves from 1 controller to another, it can be gray on 1 WLC and green on the other without deleting APs and data, then creating a new AP on the secondary WLC.

Another reason to reinvent is because various vendor controllers do things differently. Wireless could probably be it's very own Orion module because of all the various ways vendors are doing thing. Even within vendors, there are differences (traditional Cisco vs Meraki).

Just my 5 cents on this, but every opinion matters and can only help the cause, right?

D

This is a pretty old post, but a lot of it is still relevant. The current state of Wireless monitoring needs to be reviewed and reinvented (IMHO).

The list of requests above, a new one, and my adds:

• Make Machine Type of access point, the actual Machine Type and not the Machine Type of the Wireless Controller.
  • This still has not been addressed
• Make Access points manageable objects without license penalty which can be individually added to a Network Atlas Map. Not just adding an Access point as an ICMP node without advanced information such as clients, RSSI, etc.
  • This is being somewhat addressed with the Heatmaps. I believe Heatmaps could also be improved, but all those requests are in various FRs already.
• Create custom properties for each access point so I can enter custom details about the Access Point like location information.
  • At least in Cisco-land, there is a description field in the controller for each AP, can this info be pulled in without creating a custom field? Although, custom fields on APs could also be very helpful for so many other reasons.
• Access point visibility on switches.
  • Unless the device is actually a monitored element in NPM, you can't get the connection info...this request is directly related to "Make Access points manageable objects" above
• Create Dependency where access point has a Parent of the switch to which it is attached. (courtesy of cbaser)
  • Also related to "Make Access points manageable objects" above since only a monitored element can be included in a dependency setup
• Similar to the DNS redundancy configuration in IPAM, can we add "redundant" WLCs? This way when an AP moves from 1 controller to another, it can be gray on 1 WLC and green on the other without deleting APs and data, then creating a new AP on the secondary WLC.

Another reason to reinvent is because various vendor controllers do things differently. Wireless could probably be it's very own Orion module because of all the various ways vendors are doing thing. Even within vendors, there are differences (traditional Cisco vs Meraki).

Just my 5 cents on this, but every opinion matters and can only help the cause, right?

D