FreeBSD bsnmpd Monitoring Operations: Load MIB Modules and Verify Metrics

FreeBSD includes bsnmpd, a small and extensible SNMP agent. The base daemon provides core protocol behavior and uses loadable modules to expose additional MIBs. That modular boundary explains why an agent can be running while a monitoring system sees only a subset of expected counters.

Operate bsnmpd as a telemetry endpoint, not as an application health check. SNMP can report system, interface, bridge, and host-resource state through configured MIB modules. It cannot prove that a database transaction succeeds, a remote user can authenticate, or an application meets its latency objective. Pair agent counters with service-level probes.

Inspect the default configuration and modules

The default configuration is /etc/snmpd.config. Inspect it before editing, identify enabled module paths, and note the rc service state:

grep -v '^[[:space:]]*#' /etc/snmpd.config
sysrc bsnmpd_enable
service bsnmpd status
find /usr/lib -maxdepth 1 -type f -name 'snmp_*.so' -print

Review the configuration locally before sharing command output: it may contain community names, credentials, or other deployment-specific access details. Redact secrets from tickets and logs.

The daemon manual documents configuration sections, MIB assignments, variables, and includes. A configuration error during initialization can prevent the daemon from starting; a module load failure can prevent that module’s configuration from being applied. Keep the original file, make a focused change, and inspect startup output or system logs after reload.

FreeBSD’s Handbook demonstrates loading the bridge module for bridge and spanning-tree monitoring by enabling the bridge module path in /etc/snmpd.config. The core MIB-II module and host-resources module are separate module choices. Confirm that the module library exists in the installed system and that its MIB is intended for the metric being collected.

The format is specific to bsnmpd. Do not copy a Net-SNMP snmpd.conf stanza into /etc/snmpd.config. Net-SNMP is a different agent with a different configuration language, module model, and default MIB set.

Enable the service deliberately

The Handbook documents enabling bsnmpd through rc.conf and starting it with the service framework:

sysrc bsnmpd_enable="YES"
service bsnmpd start
service bsnmpd status

An enabled rc variable represents boot policy, not proof that the agent is listening or returning expected objects. Verify the listener with sockstat and query from an approved monitoring client. Review the local service script and agent configuration for the exact transport and access-control behavior before exposing a listener beyond a management network.

Make configuration changes in /etc/snmpd.config, not in a generated or package-managed path. bsnmpd reads the configuration during initialization, when a module is loaded, and after SIGHUP according to its manual. A reload is not necessarily equivalent to a process restart for every change. Check that the target change takes effect by issuing a query for the relevant OID.

Scope the MIB set to the monitoring need

Begin with one module and one expected metric family. For basic interface monitoring, enable the documented MIB-II support and verify interface index, administrative status, operational status, octet counters, and error counters from the client. Interface indexes can change across reboots or device changes; monitoring should map stable interface descriptions and names rather than relying on an index alone.

For a bridge, use the FreeBSD Handbook’s documented bridge module:

begemotSnmpdModulePath."bridge" = "/usr/lib/snmp_bridge.so"

This line is a module-path setting in the native bsnmpd configuration format. Confirm that the library exists and that the bridge device is present before expecting bridge MIB data. Then query the bridge-specific objects from a client that has the relevant MIB definitions or uses numeric OIDs.

Document the expected polling contract for each module. An interface collector may need only a few counter OIDs, while a bridge collector may need spanning-tree state and per-port attributes. Polling every available object at a high frequency can add load and create unnecessary network traffic. Start with a small walk in a lab, measure response time and payload size, then select only required OIDs in the production template.

Counter semantics also need an explicit interpretation. Octet counters accumulate and can wrap or reset when an interface or agent restarts; they are not rates by themselves. The collector derives rates from two samples and should handle discontinuities and interface replacement. Compare deltas over the same period with local interface counters before diagnosing an apparent traffic spike or drop.

Host-resource modules may expose processes, storage, or system resources depending on the module and current implementation. Do not assume that every Net-SNMP HOST-RESOURCES-MIB object has an identical bsnmpd equivalent. Compare the actual OID tree and values to the poller’s expectations, and document unsupported objects rather than fabricating metrics.

Load only modules required by the monitoring design. More modules mean more MIB surface, more configuration, and more failure modes. For each module, record the library path, MIB name, expected OIDs, module dependencies, and which polling template consumes the data.

Test from the monitoring path

Check the daemon’s listener and logs on the host, then query from the same network path used by the collector:

sockstat -46 -l | grep ':161'
service bsnmpd status

Use an SNMP client installed on the management host to query a known system OID and the specific module OID. Protect credentials and avoid placing secrets in shell history. Verify the source address and transport version used by the collector. A local query can succeed while a remote poll is blocked by routing, a firewall, or an access list.

Compare returned values to local commands at the same time. For example, compare interface octet deltas with netstat or ifconfig counters over the same interval, and compare uptime with the host’s local uptime. Counter width, reset behavior, polling interval, interface replacement, and wraparound can affect monitoring calculations.

If the poller reports no such object, first distinguish an unloaded module from an unsupported OID, an incorrect index, or a MIB parsing issue. Walk the relevant subtree from a trusted client and inspect the returned object identifiers. A textual MIB label is a client-side name mapping; the numeric OID is the protocol identifier.

Security and availability boundaries

SNMP configuration affects what remote systems can observe or change. Restrict polling to the intended management network and use the strongest supported authentication and privacy mode required by the deployment. Community-based SNMP versions do not encrypt their community string in transit. Never enable write access just to make a read-only monitoring poll pass.

Treat the bridge module as potentially configuration-capable, not telemetry-only: its private BEGEMOT-BRIDGE-MIB includes SET objects that can create or destroy bridge interfaces and alter bridge-member state. If it is loaded, explicitly constrain who can issue SET requests and which OIDs each identity can access. For bsnmpd, snmp_vacm is the view-based access-control module; its manual warns that without it, all configured v1/v2c communities and v3 USM users are granted access. For SNMPv3 USM processing, load and configure snmp_usm as documented. Verify the active module and access policy on the target release before exposing the agent; a protocol-version label alone does not establish authentication, privacy, or least privilege.

The exact bsnmpd modules and protocol support are release-sensitive. Check the installed manual pages for SNMPv3 user-based security, access control, and notification module behavior before relying on a particular feature. Avoid putting secrets into a shared configuration file with broad read permissions; verify owner and mode after change.

Agent health is not machine health. If bsnmpd is unavailable, the host may still serve applications. If bsnmpd responds, the host may still have failing services. Alert separately on agent reachability, host counters, and application transactions so a single SNMP signal does not mask a real service outage.

Define ownership for any custom module or local MIB extension. Record the OID namespace, module library, build revision, package or base-system dependency, and expected restart behavior. A module that is copied manually into /usr/lib can disappear or become ABI-incompatible during an OS update. Prefer supported packages or a controlled source build with a rollback artifact, and test module loading after every supported release upgrade.

Keep monitoring configuration versioned with the host’s deployment profile. A MIB tree imported by a monitoring server may be a different revision from the agent module. If labels or object definitions change, update the collector and dashboard with an explicit migration rather than silently reusing a numeric OID for a new metric. Store a known-good query transcript with agent version and module set to speed future diagnosis.

Common failure cases

If the service will not start after a module change, inspect the exact module path, syntax, symbol dependencies, and logs. Revert only the last change and reload or restart according to the service procedure. Do not uncomment every module in the sample file as a troubleshooting step.

If local polling works but remote polling fails, inspect the listener address, packet path, firewall, and configured access controls. Avoid broadening the listener to all interfaces until the intended policy is understood. If the agent responds but the poller shows empty graphs, check the MIB subtree, interface index mapping, counter units, and sampling interval.

If a metric disappears after a hardware change, update discovery and labels rather than mapping a new interface index onto the old interface name. Preserve old metric history with an explicit migration record. A counter reset can appear as negative traffic or an enormous rate if the collector does not account for discontinuities.

Acceptance criteria

A monitoring integration is ready when only the required modules are loaded, the rc service starts after reboot, the approved client can query representative OIDs through the production path, local counters agree with SNMP deltas within expected timing, and alerts distinguish agent loss from application health.

bsnmpd supplies a modular SNMP endpoint. Reliable monitoring still depends on correct MIB selection, stable labels, controlled access, and independent service-level acceptance checks.

Related:

Sources: