Set up your own SNMP lab

SNMP monitoring can use free software, an always-on computer or VM, and a little setup time. This guide is an orientation and lab checklist, not a replacement for the current installer documentation. Use a spare switch or isolated lab, and obtain the network owner’s approval before changing production settings.

A practical starting point is LibreNMS on a small Ubuntu machine. It is purpose-built for network equipment and automatically creates useful switch-port, traffic, temperature and hardware graphs. Its current documentation supports Linux, Docker and virtual-machine installations. (docs.librenms.org)

What the system looks like

Managed switches and AV devices
          │
          │ SNMP polling — UDP 161
          ▼
   LibreNMS monitoring server
          ▲
          │ Traps — UDP 162
          │ Syslog — UDP/TCP 514

The monitoring server is the SNMP manager. Each switch or compatible AV device runs an SNMP agent.

The basic process is:

1. Install the monitoring server.
2. Enable SNMP on each device.
3. Give the monitoring server the SNMP credentials.
4. Select what matters.
5. Configure useful alerts.
6. Let it collect history continuously.

My recommended free starter setup

Hardware

Use one of these:

• Spare mini PC running Ubuntu
• Small VM on an existing server
• Inexpensive dedicated mini PC
• Docker host that is already operating continuously

A MacBook can run it for experimentation, but monitoring stops whenever the laptop sleeps or leaves the network. The collector should ultimately be an always-on appliance.

For a small AV system, this does not require a monster server. A modest machine with 4–8 GB of RAM and an SSD is plenty for an initial deployment.

Software

My first choice would be:

• LibreNMS: Best fit for switches, interfaces, optics, PoE and network-oriented monitoring.
• Zabbix: Also free and extremely capable, but more general-purpose and more manually configured.
• PRTG: A commercial alternative. Check its current license and sensor limits before choosing it; individual measurements can consume separate sensors.

LibreNMS is probably the sweet spot for what you’re trying to learn and what BMT could eventually use.

Install and validate LibreNMS first

Follow the current official LibreNMS installation guide for a supported operating system, required services and scheduled polling. Complete its validation checks and confirm the web interface and poller work before adding a switch. Size the host for your polling interval, device count and retention; the figures below are a pilot starting point, not a guarantee.

Step 1: Place the monitoring server correctly

Give the server:

• Static IP or DHCP reservation
• DNS entry
• Correct gateway
• NTP
• Access to the AV management VLANs
• Regular backup of its configuration and database

For example:

• LibreNMS: 10.20.10.20
• Management VLAN: VLAN 10
• Ruckus switch: 10.20.10.5
• Q-SYS Core: 10.20.10.30

The server does not need to sit on every VLAN. It needs routed and firewall-controlled access to the management addresses it will poll.

Do not expose UDP 161 or 162 directly to the internet. For multiple customer sites, use a secure VPN, an on-site poller or another protected architecture.

Step 2: Enable SNMP on the switch

On each device, enable its SNMP agent.

Where supported, use:

• SNMPv3
• Security level: authPriv
• Authentication: a mutually supported SHA-2 option where available; verify exact algorithm names and firmware support
• Privacy/encryption: AES
• Read-only access
• Source restriction to the monitoring server’s IP

Conceptually, the switch configuration contains:

SNMP version:       v3
Username:           bmt-monitor
Authentication:     Supported SHA-2 option; verify both ends
Privacy:            AES
Access:             Read-only
Permitted manager:  10.20.10.20
Contact:            info@blackmountain.tech
Location:           Main AV Rack

The exact commands vary significantly by manufacturer and firmware. LibreNMS publishes examples using SNMPv3 groups, SHA authentication and AES privacy for supported platforms. (docs.librenms.org) For Ruckus ICX, I would generate the exact configuration from the specific model and FastIron version. This is one of those situations where copying generic Cisco commands into a Ruckus switch earns you an educational error message.

If the product only supports SNMPv2c

Some AV products only offer v1 or v2c. In that case:

• Create a long, unique community string.
• Make it read-only.
• Restrict access to the LibreNMS IP with an ACL.
• Keep it entirely inside the management network.
• Never use public or private.
• Document that SNMPv3 is unsupported.

SNMPv2c is acceptable as a constrained legacy accommodation. It should not be transmitted across an untrusted network because the community string is not encrypted.

Step 3: Add the device to LibreNMS

In LibreNMS, add:

• Device IP or DNS name
• SNMP version
• SNMPv3 username
• Authentication protocol and secret
• Privacy protocol and secret
• SNMP port—normally UDP 161

LibreNMS then queries the device’s standard and vendor MIBs and discovers whatever that platform exposes:

• Interfaces
• Port names
• Traffic counters
• Errors and discards
• CPU and memory
• Temperature
• Fans and power supplies
• VLAN information
• PoE measurements
• Optical DOM readings
• Device uptime

Exactly what appears depends on the device’s SNMP implementation. LibreNMS cannot interrogate a DSP’s feelings if the manufacturer only exposes uptime and a model number.

Step 4: Clean up the port descriptions

This is surprisingly important.

Configure switch interface descriptions such as:

AV101-DISPLAY-DECODER-01
AV201-QSYS-CORE
IDF2-UPLINK-FIBER-A
LOBBY-PTZ-CAMERA-01

LibreNMS can display those descriptions, which makes the monitoring screen correspond to the BMT drawings.

Without good descriptions, you get a beautiful graph proving that “Port 37” has a problem. Splendid. Nobody knows what Port 37 serves.

I would make the following fields consistent across drawings, switch configuration and monitoring:

• Device ID
• Hostname
• IP address
• Switch and port
• VLAN
• Physical location
• Functional description

Step 5: Start with a small monitoring set

Do not alert on every available number. Begin with:

Every managed switch

• Device availability
• Uptime/reboot
• Temperature
• CPU and memory
• Fan and power-supply faults
• Total PoE usage and remaining budget

Every uplink

• Link state
• Negotiated speed
• Inbound/outbound traffic
• Errors
• Discards
• DOM receive and transmit levels
• Frequent link transitions

Critical AV endpoint ports

• Link state
• Traffic
• Errors and discards
• PoE draw and faults
• Port flapping

A good first alert set might be:

• Device unreachable for three consecutive polls
• Uplink goes down
• Switch restarts
• Interface errors increase rapidly
• Uplink utilization remains over 80%
• Optical receive level crosses the SFP’s warning threshold
• PoE device is denied power
• Switch temperature exceeds the manufacturer’s recommended threshold

Set the alert delay deliberately for your configured polling interval. Three consecutive five-minute polls can mean roughly 15 minutes, not three missed packets. LibreNMS documents one-minute polling as a separate configuration choice; tune polling and alert timing together.

Step 6: Add traps and syslog later

Polling works without traps. Start there.

Once basic polling is reliable, first configure and validate the collector using the LibreNMS SNMP trap-handler guide, including the supported receiver/handler services. Then configure the devices to send SNMP traps to that collector on UDP 162. Traps can report events immediately between polling intervals.

Then configure and test a syslog collector before forwarding device logs to it. LibreNMS supports integration through tools such as rsyslog or syslog-ng, commonly receiving messages on port 514. (docs.librenms.org) Together:

• Polling: What is the device’s condition?
• Trap: Something just changed.
• Syslog: Here is the device’s explanation of what happened.

What does “free” really mean?

The real work is maintaining it:

• Update the operating system.
• Update LibreNMS.
• Back up the database.
• Protect the credentials.
• Review alerts.
• Avoid collecting years of useless five-minute graphs from every unused switch port.

A manageable first pilot

Build a first pilot like this:

1. Install LibreNMS on a local Ubuntu VM or spare mini PC.
2. Add one Ruckus ICX switch using SNMPv3.
3. Monitor the switch health and only five ports:
   • Core uplink
   • One fiber access-switch uplink
   • One AVoIP encoder
   • One decoder
   • One PoE camera or touch panel
4. Run it for one week.
5. Examine normal traffic, errors, discards, DOM levels and PoE behavior.
6. Disconnect one test endpoint and confirm that the monitoring evidence makes sense.
7. Review the evidence and tune alerts before expanding the pilot.

That small pilot will teach you more than importing 600 ports and staring at a dashboard that looks like the bridge of the Enterprise.