Setup guides / LibreNMS
← Back to LabLibreNMS setup guide
ValidatedTested with community edition (image tested Sep 2026)
LibreNMS discovers and polls this device with no manual sensor setup. These steps mirror the M2E validation run.
Router (generic-router-v1)
SNMP v2c · 8 interfaces
- 8 ports discovered
- CPU sensor
- Memory sensor
- Per-port traffic
Run high_cpu → CPU reads ~95% → your alert should fire.
Connection
- Host
- snmp-test.bonguides.com
- Port
- 161
- Version
- SNMP v2c
- Community
- generated per device
The community is generated per device and shown only in your lab — treat it as a throwaway secret and do not reuse it. SNMP v2c is cleartext.
1. Create the device
- In the lab, create a Router (generic-router-v1) and copy its Host, Port, SNMP version and Community.
- Host is snmp-test.bonguides.com, port 161, SNMP v2c. The community is generated per device — treat it as a throwaway secret.
- Expect 8 interfaces (GigabitEthernet0/1–8), plus system uptime, CPU and memory over standard MIBs.
2. Configure LibreNMS
Add the device
Add the device by hostname snmp-test.bonguides.com with SNMP v2c and the generated community (lnms device:add … --v2c --community …). Run discovery then poll.
Expected data
8 ports are discovered; CPU and memory sensors are created automatically; uptime and per-port traffic are stored.
3. Run the fault scenarios
Trigger these from the device page in the lab, then watch LibreNMS react. Each has a recovery action that restores the baseline.
- interface_down — port 1 operational status becomes down.
- high_cpu — the auto-discovered CPU sensor reads ~95%.
- traffic_spike — port 1 in-rate rises sharply (observed ~1.4 → ~97 Mbit/s).
- snmp_down — the device is marked down, then recovers.
Caveats
- LibreNMS stores sysName lower-cased internally (e.g. 'm2f prtg router'); the SNMP value itself keeps its original case. This is a LibreNMS normalisation, not a device issue.