LibreNMS-Based Network Monitoring, Management,
and Deployment Guide

As modern enterprise and campus networks evolve toward cloudification and automation, network environment heterogeneity has become increasingly prominent. The Asteria Campus OpenWiFi Controller  establishes a unified management framework encompassing both native and third-party infrastructure through deep integration with LibreNMS, an open-source network monitoring engine. This white paper delineates the Distributed Polling Architecture utilized by this controller and LibreNMS, providing an in-depth analysis of its underlying mechanics across automated discovery, device fingerprinting, localized data polling, and centralized cloud visualization. Together, these capabilities deliver a standardized solution for unified operations and maintenance (O&M) within heterogeneous network environments.

Architected upon the open-source OpenWiFi framework, the OpenWiFi controller natively supports unified configuration and monitoring for wireless Access Points (APs) compliant with the ucentral-client specification, as well as Asterfusion native network devices. However, production network environments typically contain diverse third-party hardware infrastructure, including egress security gateways, core switches, and application servers.

This multi-vendor coexistence presents several inherent operational bottlenecks:

• Decoupling of Control and Monitoring Planes: O&M personnel are forced to constantly context-switch between cloud management consoles, vendor-proprietary Network Management Systems (NMS), and server monitoring platforms, significantly increasing the Mean Time to Repair (MTTR).
• Data Silos and Failed Alert Correlation: Semantic discrepancies exist across metrics collected by disparate systems. Lacking unified event correlation rules, these systems are prone to triggering alert storms or failing to identify critical latent faults.

To resolve the challenge of onboarding non-ucentral-client devices, the OpenWiFi controller integrates the LibreNMS monitoring engine deep within its control plane lower tier, leveraging standardized protocols to achieve unified monitoring and cross-platform O&M collaboration for heterogeneous network assets across the enterprise.

LibreNMS is a full-featured, auto-discovery network monitoring platform built on PHP, MySQL, and SNMP. Its extensive device support and built-in MIB library constitute its core advantages among open-source monitoring tools. Field-tested across numerous enterprise-grade networks worldwide, LibreNMS serves as an ideal choice for managing complex multi-vendor network environments.

• Automated Subnet Scanning and Device Discovery

The LibreNMS engine employs an asynchronous combination of ICMP and SNMP discovery mechanisms to achieve automated discovery of heterogeneous devices. Administrators simply specify a target subnet or IP range, and the system initiates parallel scans. For active host nodes, the engine attempts to establish sessions using pre-configured SNMP v1/v2c/v3 credentials, eliminating manual node-by-node entry and credential configuration, thereby boosting deployment efficiency in large-scale network environments.

• Multi-Vendor Compatibility and Automated Metric Extraction

Protocol-layer vendor compatibility and automated metric extraction leverage a built-in system fingerprint database and an extensive MIB mapping table. The monitoring engine automatically parses the SNMP sysObjectID. Based on the retrieved OIDs, the system automatically matches devices to their respective vendors (e.g., Cisco, Juniper, Huawei, Ruijie, etc.) and operating system types. Upon successful matching, the engine automatically parses both standard and proprietary MIB nodes to extract key performance metrics (such as CPU utilization, memory allocation, interface throughput, and optical transceiver Rx/Tx power), eliminating tedious manual configuration required for mapping OIDs across different vendor devices.

• Event-Driven Alert Handling Mechanism

Supporting customizable alert events and threshold configurations, the engine continuously compares newly polled data against active alerting rules. When a metric breaches a threshold condition, an event agent constructs a standardized alert payload and dispatches it independently to administrator inboxes via an integrated SMTP component, preventing alert delivery from depending excessively on the upper-tier management plane.

To accommodate diverse deployment scenarios—ranging from on-premise to cloud environments and support multi-tenant, multi-site controller architectures, the OpenWiFi controller adopts a lightweight integration architecture based on distributed polling.

The LibreNMS Core Management Agent (Gateway Agent) is packaged as a lightweight plugin inside the OpenWiFi controller system image and deployed in public clouds or centralized data centers. The Control Center provides a unified Web visualization portal; however, it does not directly perform high-frequency SNMP data polling, nor does it persistently store raw interface performance metrics or Round Robin Database (RRD) chart files. When operations personnel request the monitoring status of a specific site via the Web UI, the Control Center of the OpenWiFi controller uses an API proxy mapping to issue an on-demand request (On-demand Request) to the corresponding local network’s Edge Poller node, thereby completing the retrieval and rendering of real-time data. This approach significantly reduces the computational and I/O load on the centralized controller.

The librenms-poller is an autonomous edge collection node deployed within an enterprise intranet or branch offices. It performs periodic polling on third-party devices via SNMP v2c/v3 (UDP 161) or ICMP protocols locally, writing time-series data directly into the local RRDCached caching service and RRD files. Localized data storage drastically reduces the WAN bandwidth consumption associated with transmitting raw monitoring data. When the management channel between the edge node and the cloud-based ACC controller is disrupted due to network fluctuations, the Edge Poller continues to operate autonomously using its local database and RRD files, ensuring that monitoring data remains continuously recorded without interruption. This distributed deployment and centralized management model ensures that in multi-branch scenarios, the polling load on each node is fully borne by its local compute resources, thereby resolving the CPU and disk I/O bottlenecks typically encountered with centralized network management platforms in large-scale networks.

The librenms-poller node features a built-in standalone alert evaluation engine. Upon receiving alert rules from the ACC controller, the node continuously evaluates real-time data against active rules during its local polling cycle. Once an alert threshold is triggered, the Edge Poller node can establish an encrypted connection directly with a public SMTP mail server without relying on the cloud controller for relay, automatically sending alert email notifications to the specified administrator inbox.

Within the OpenWiFi controller management interface for a designated site, the system automatically generates site-specific credentials, including the server address (SERVER_ADDR), authentication identifier (AUTH_ID), and security key (AUTH_KEY). When executing the local snmp-poller deployment, these parameters are injected into the edge node configuration. The node then registers with the Control Center over an encrypted TCP channel, completing the logical site binding.

Once binding is established, administrators can initiate subnet discovery tasks directly from the controller Cloud Console. Upon completion of the scan by the Edge Poller, device inventories and status metadata are synchronized to the controller UI.

Clicking on a specific device prompts the Control Center to issue snmp_monitor API calls to the Edge Poller, dynamically fetching real-time time-series charts (CPU, memory, traffic throughput).

The platform allows administrators to build custom dashboards using global metric widgets, including device availability heatmaps, Top-N interface traffic distributions, and high-latency node maps.

In the alert configuration module, conditional expressions (e.g., interface down, CPU utilization threshold breach) can be flexibly defined and mapped to designated email transport groups, realizing precise event distribution and collaborative incident response across heterogeneous network assets.