SNMP
SNMP brings IT and network gear into the Niagara picture. UPS units, PDUs, network switches, environmental monitors, and generators often speak SNMP – and when facility and IT infrastructure need to be watched from one place, Software Pile integrates them into the station.
SNMP Integration Work
- MIB parsing and OID mapping into typed Niagara points – including vendor-specific MIBs
- Polling and SNMP trap handling so events arrive as alarms, not just as slow-polled state changes
- SNMPv3 with authentication and encryption where the network security posture requires it
- Data center and critical-infrastructure monitoring: power, cooling, and network health alongside building systems
Where SNMP Fits
SNMP is the bridge to equipment that lives in the IT world but matters to facilities – and increasingly the reverse. We map the OIDs that matter, ignore the noise, and turn device MIBs into points operators can actually use.
Send the device list and MIBs plus your Niagara version. If MIBs are missing, we can often work from the device documentation.
The First Obstacle Is the Approval
The devices worth monitoring over SNMP belong to IT, and IT has opinions about polling them. Read access on production network equipment normally requires a request, agreement on which host may query, credentials issued under their process, and often a change window.
The first technical question that conversation produces is which SNMP version you intend to use. v1 and v2c carry a community string in cleartext, which some networks will not permit on production equipment at all. v3 supports authentication and encryption, and is the version to propose wherever the equipment supports it. Whichever is agreed, the station gets read-only access, a community or user dedicated to it, and a source address IT can filter on. Building all of that into the plan avoids the awkward version of this project, where the station is configured, the points are mapped and nothing responds because a firewall rule was never raised.
Traps Report Events, Polling Reports Presence
Polling gives a predictable cadence and detects a device that has gone silent. If a UPS stops answering, polling notices. Traps are fire-and-forget notifications sent over UDP: fast when they arrive, and capable of being dropped without anyone knowing.
There is a case for using both. Poll for state so you always know what is reachable, and accept traps for events that need immediate attention. Traps also require inbound firewall rules to the station, which returns you to the approval conversation above.
MIBs, OIDs and the Data Types Behind Them
A MIB defines what a device exposes, and the types matter more than they first appear. Gauges hold a current value and can be read directly. Counters only increase and wrap around when they hit their ceiling, so they have to be handled as deltas or a wrap will register as an impossible spike. Enumerated integers carry states that mean nothing until mapped to readable values.
Units are the other gap. A MIB rarely provides them in a form Niagara can consume, so they get set during mapping and documented alongside the point. Vendor MIB quality varies widely, and where the file is missing or wrong, device documentation and careful observation are what you have left.
Monitor What Somebody Will Act On
A large switch exposes an enormous number of objects. Mapping all of them fills the station with points nobody reads and histories nobody queries, while adding poll load to the network IT just approved.
A short list worth starting from: UPS state, load and battery condition, PDU circuit loading, port status on links that carry something critical, environmental probes in rooms that matter, and generator status with fuel level. Each of those has an owner who would act on an alarm, which is the test to apply to every candidate point.
Network Equipment Flaps, and the Console Has to Expect It
Ports go down during maintenance, a UPS on self-test looks briefly alarming, and a switch reboot after a patch window generates events that need no response.
Delays before an alarm is raised, thresholds set from observed behavior instead of a specification sheet, and suppression during known maintenance windows all keep the console meaningful. The other half is ownership. An SNMP alarm with no named recipient in facilities or IT is a point that gets acknowledged and forgotten, so agree the recipient at the same time as the threshold. Building Automation Integration Services covers the wider mapping and naming work these points sit within.
Where the Station Sits on the Network
The station host acts as an SNMP manager for this work. Queries leave the station host for port 161 on each device and the answer comes back to an ephemeral port, while notifications arrive on port 162 at the station. All of it is UDP, so there is no connection state anyone can inspect: a device that is powered off, a rule that silently drops the request, and an ACL on the agent that never matched the source address all look identical from the station. The diagnostic that separates them is a single get issued from the station host itself before any point is mapped, which tells you whether the path exists independently of whether the mapping is right.
Placement decides how much of that path there is to argue about. A station host with an interface on the management VLAN reaches the switches directly; a station on the building network reaching them across a routed boundary depends on rules somebody else maintains and reviews. Address translation anywhere on that path is worth knowing about early for a specific reason: a trap arrives with the translated source address, and a station that identifies the sending device by source address will not match it to the device entry, so the trap is received and discarded.
None of that is a Niagara question. It is an IT decision that belongs before point mapping, not after, and it comes down to a handful of answers that are yes or no rather than design work.
- Which source address the devices will see queries arrive from, and whether translation happens anywhere between the station host and the device subnets
- Whether the station host gets its own interface on the management VLAN or reaches it across a routed boundary someone else maintains
- How many trap destinations each agent supports, since some allow only one or two entries and an existing monitoring system may already hold them
- Whether the device addresses themselves are static or reserved, because a device that changes address stops answering and presents exactly like a failed device
v3 Is a User Model, Not a Password
v3 replaces the community string with a user name, a security level, and two algorithm choices, one for authentication and one for privacy. The levels are noAuthNoPriv, authNoPriv and authPriv, and both ends have to agree on every part of it. Older management cards stop at MD5 and DES; newer equipment offers SHA-256 and AES-128 or better, with support above AES-128 uneven across vendors. A station configured for an algorithm the card does not implement fails in a way that reads like a wrong password, and the usmStats counters on the agent are what actually distinguish an unknown user name from a failed digest from a decryption error.
Each agent also has an authoritative engine ID, and v3 keys are localized against it, meaning the passphrase and the engine ID together produce the key that is used on the wire. Discovery is the exchange in which the manager learns that engine ID and the agent's boot count and uptime before it can send an authenticated request. If the manager's idea of the agent's time drifts outside the window, the agent answers with a report PDU rather than data, which looks like a device that has stopped responding to a mapped point but not to a ping.
The consequence at hardware level catches people out. Engine IDs are commonly derived from something hardware specific such as a MAC address, so a replacement card at the same IP address has a new engine ID and therefore new localized keys, and a like-for-like swap stops v3 polling until rediscovery. Where the manager stores a localized key rather than the passphrase, the entry has to be rebuilt rather than rediscovered.
Table Indexes Move, and the Point Does Not
Most of what is worth polling lives in tables, and a mapped point addresses a row by index, not by name. ifIndex in IF-MIB is the usual case: the standard says values should remain constant between re-initializations, but adding or pulling a module, swapping a transceiver type, or a firmware upgrade can renumber the table. The point keeps requesting the same OID afterward and receives whatever now occupies that row.
The symptom is worse than a fault, because it is not a fault. You get a port that reads up while the link it was supposed to watch is down, and nothing alarms. The check that catches it is to poll a descriptive column for the same index alongside the status column, ifName or ifDescr next to ifOperStatus, so an index shift shows up as a description that no longer matches the point name. On devices that support ifAlias, the interface description configured by the network team is the most stable label available and is worth carrying into the station for exactly this reason.
The same applies to UPS output lines, PDU outlet tables and entity sensor tables. Where a device implements a standard MIB alongside its vendor tree, the standard objects are usually the more durable mapping across a controller swap, while the vendor tree is where the detail lives, so the two often get used together rather than one instead of the other.
Polling Costs the Device Something
Every mapped object is a recurring request against equipment whose main job is forwarding traffic or holding up a load. Forty devices at twenty-five objects each on a ten second interval is a hundred object reads per second, sustained, forever; the same set at sixty seconds is under seventeen. Management CPUs on switches and management cards on UPS units are modest, and agents deprioritize SNMP work when they are busy, so an over-aggressive interval surfaces as intermittent timeouts on a device that is otherwise perfectly healthy.
Request shape matters as much as interval. GETBULK exists only in v2c and v3, so a v1 walk retrieves a table one GETNEXT at a time, and setting max-repetitions high does not remove round trips because the agent returns only as many values as fit in one message. Timeout and retry settings multiply against device count as well: a device that is off, with a five second timeout and three retries, occupies twenty seconds per request before the station gives up on it.
Counter width is the constraint that can decide the version outright. ifInOctets is a 32-bit counter and rolls over in roughly thirty-four seconds on a saturated gigabit link, so no poll interval you would actually run gives you a trustworthy throughput figure from it. The high-capacity equivalents such as ifHCInOctets are 64-bit, and 64-bit counters cannot be carried by the v1 protocol at all. If bandwidth trending on gigabit ports is genuinely part of the requirement, that settles the version question before any security discussion does.
One Console or Two
Sites that ask for SNMP in the station frequently already run a network monitoring system, and the problem that follows is organizational rather than technical. Two consoles now show the same UPS, with different thresholds, different names, different histories and no agreement on which is authoritative. Whoever is on shift believes the one they use daily, which means an alarm can be acknowledged in one system and stay open and unseen in the other.
The direction of the integration is a choice rather than a constraint. SNMP is symmetric enough that a station can poll IT equipment inward and also send notifications outward to an existing monitoring system, which leaves IT's console authoritative for IT gear while facilities still sees what it needs on the console it already watches. Settling first whether the station should report outward rather than duplicate everything inward changes the point count, the poll load and the approval scope more than any other decision on the list.
There is also a case where none of this is the right mechanism. Where the requirement is a single run or fail indication and nothing analog, a dry contact into an input that already exists on a controller does that job with no agent, no credentials and no firewall change. That is not the situation on a point list that includes fuel level, battery condition or circuit loading, since a contact carries one bit and cannot carry a value or a trend. The test is simply whether anything on the list is a number somebody wants to see over time.
Frequently Asked Questions
Is this the same as installing a network monitoring system?
No. A network monitoring system discovers topology, tracks device configuration, and keeps per-interface history at intervals short enough for IT to troubleshoot from, and it is built to be run by network staff. An SNMP integration in the station brings a selected set of objects into the same point space as the mechanical equipment, so they alarm, trend and route through the console operators already use. If what you actually need is utilization graphing on every port of every switch, a monitoring system does that better and the station should not try to become one.
What has to exist on the devices before mapping can start?
The agent has to be enabled, and the version you intend to use has to be available on the firmware that is installed, which is not a given on older management cards. Each device needs an address that will not move, either static or reserved. Time has to be settled too, since trap timestamps and history alignment depend on the station host and the devices agreeing on the clock, and that is easier to fix before commissioning than after. On the Niagara side the SNMP driver is a licensed feature, so it needs to appear in the station license before the driver can be added.
How does the mapping work proceed in practice?
One device of each type gets walked first, because what an agent actually exposes and what its MIB file claims are not always the same, and the walk shows which tables are populated and which are empty. Naming is settled at that point rather than later, since renaming a point after it has been collecting orphans the history attached to the old name. Traps are proved with a real event rather than the device's test-trap button, because a test trap can use a different OID and a different destination entry than the condition you care about. After that, the remaining devices of the same type are repetition.
What if a device only supports v1 or v2c?
Check the vendor release notes before accepting it, because some equipment reaches v3 with a firmware update or a newer management card, and that is usually a smaller conversation than the alternative. Where the hardware genuinely cannot get there, IT commonly wants the polling confined to a management VLAN that the station host has an interface on or a filtered route to, rather than allowing it to cross the general network. Both of those are IT's call rather than ours.
Can the station control the equipment, or only read it?
Read only, as this work is normally scoped. SNMP does define a SET operation and some PDUs expose outlet control through it, but writing requires a separate community or v3 user with write access, and that is a different approval than read access gets. If outlet control or UPS shutdown behavior is actually wanted, treat it as a separate item with its own risk discussion, because a mistyped OID that reads the wrong object is harmless and one that writes is not.
What about firmware updates on the monitored devices?
A major firmware version can move, add or deprecate objects, so points that were correct can start returning null or a different value after an update nobody mentioned to facilities. The habit worth keeping is to re-walk a device after a major version change and spot-check a handful of mapped points against the device's own web interface. It is a short check, and it is the only thing that catches quiet drift, since a point returning a plausible wrong value never faults.