Wireless network monitoring has been a feature of NetXMS for quite some time. However, significant improvements were long overdue. With the release of NetXMS 5, these enhancements have finally arrived and subsequent patch releases have perfected them. Let's see what's new.
Previous Functionality
Before NetXMS 5, wireless network monitoring worked in a somewhat cumbersome way.
If you had a node that was a wireless controller, separate objects called access points were created by the server under that node to represent wireless access points managed by that controller (similar to interface object logic).
Those objects provided information related to wireless network – radios, connected clients, etc.
However, for nodes representing standalone wireless access point, virtual access point objects were created under node, adding some confusion, because they did not represent actual physical entities.
This setup was inconvenient, especially when dealing with geographically distributed access points managed by a single controller.
You couldn't place them in separate containers; they all were placed under the node object.
Moreover, for simple standalone access points, creating virtual access point objects was redundant and somewhat counterintuitive.
New Approach in NetXMS 5
With NetXMS 5, we have separated wireless controllers and standalone wireless access points into two distinct types of devices.
Wireless Controllers: These devices do not provide wireless access themselves but control multiple access points that do.
Standalone Wireless Access Points: These are self-contained devices, like small boxes that provide wireless access independently.
So now, if you add a node, you have two different capabilities - “wireless access point” and “wireless controller”.
Wireless Access Point
If it's a wireless access point, you just see usual network interfaces, there will be no more access point objects below. This node gets additional views dedicated to wireless functionality.
You can see the radio interfaces on this access point with SSID, and you have a view for wireless stations registered on this access point. It's simple, with no extra objects, and you can work with it as with a normal node.
Wireless Controllers
The situation is more interesting when you have wireless controllers. On the wireless controller, in the capabilities, you see a wireless controller capability and no access point capability.
If you expand it, you just see network interfaces, so no access points. How do we get actual access points managed by the controller? We introduced a new object class called Wireless Domain. Let's create one.
Initially, it's empty, but it will contain access points. You can add one or more wireless controllers to the Wireless Domain, similar to how you add nodes to a cluster.
This helps cover situations when you have, for example, two controllers managing all access points in a specific domain, or maybe you just want to combine all your access points managed by multiple controllers into a single structure.
Then we can add the controller to the domain. The domain will do a configuration poll periodically. When we run a configuration poll, it reads a list of access points managed by the controllers and creates a separate object under the wireless domain for each access point.
If you select the access point, you see it's a separate device with a specific vendor, model, number, etc. You have your radio interfaces and wireless stations registered on this particular access point.
It's a normal freestanding object, so it also has data collection. You can create data collection items on it and bind it to other containers.
You can build your own hierarchy of access points based on geography, model, or whatever structure you want. They still will be here under the wireless domain, and this list will update automatically.
If you connect more access points to your controller, they will appear here on the next configuration poll for the wireless domain.
You can run an individual configuration poll on the access point to reread information about it. You can create instance discovery DCIs and so on.
This simplifies management of the wireless devices in your network and makes it more logical and flexible at the same time.
New Object Class: Collector
We also added a new object class to NetXMS version 5 — it is called Collector.
Sometimes you have your container structure, but you may want to have some aggregated data on that container level.
Before version 5, the option was to create a dummy node without an IP address and configure those aggregation DCIs on that dummy node, which was not that logical or intuitive.
A new container type called Collector has all the properties of the container, plus it has data collection capabilities. You can bind nodes under it, and it will change status, so it works pretty much like a container.
Plus, you have your data collection here, so you can create metrics. Of course, you cannot read SNMP or agent data normally; it will be something like script or internal. But you can still read agents using a different source node.
When you create script DCIs, you have access to all the sub-objects, so you can collect data from sub-objects and present some summary data on the collector level.
With these new features, NetXMS continues to improve its platform and provide valuable tools for effective network management. Read also about the Context Dashboards.