Reference · built on requestConnectorIndustrial & building protocols

SNMP

MIB objects polled and traps received from switches, UPSs, PDUs, and appliances over SNMP (RFC 3411 to 3418).

About

SNMP is the IETF's network management protocol, defined in RFC 3411 through RFC 3418. A managed device runs an SNMP engine that answers GetRequest, GetNextRequest, and GetBulkRequest with values from its MIB, accepts SetRequest, and sends SNMPv2-Trap or InformRequest notifications. It travels over UDP, port 161 for requests and 162 for notifications. SNMPv3 adds the User-based Security Model with HMAC authentication and CBC-DES privacy, and the View-based Access Control Model, which limits the MIB subtrees a group may read, write, or receive.

Through Fibric, a connector polls the objects you name and listens for traps. An operator watches counters, status, and alarms and proposes a SetRequest for your approval.

This is a reference listing. It documents what Fibric would read from SNMP and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Device identity and uptime from the system group: sysDescr, sysObjectID, sysUpTime, sysName, and sysLocation (RFC 3418)
  • Interface state and traffic from the IF-MIB: ifAdminStatus, ifOperStatus, ifHCInOctets, ifHCOutOctets, ifInErrors, and ifOutErrors (RFC 2863)
  • UPS state from the UPS-MIB: upsBatteryStatus, upsEstimatedMinutesRemaining, upsOutputSource, and the upsAlarm table (RFC 1628)
  • Whole tables walked with GetBulkRequest using its non-repeaters and max-repetitions fields
  • Notifications received on UDP port 162: coldStart, warmStart, authenticationFailure, linkUp, linkDown, and vendor traps
  • Error-status values such as tooBig, noAccess, and notWritable, and Report-PDUs, from each response

Proposed actions

  • Target capability: propose a SetRequest on a writable object, such as ifAdminStatus to up or down on one interface
  • Target capability: propose upsShutdownAfterDelay or upsStartupAfterDelay from the upsControl group on a UPS that implements them
  • Target capability: propose setting sysContact or sysLocation so device records match your asset list

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Act on a UPS on battery

    An upsAlarmOnBattery entry in the alarm table, with upsEstimatedMinutesRemaining falling, triggers a proposal: shut down the named hosts in order and notify the person on duty, with the trap time in the receipt.

    With Uptime Response

  • Reduce trap noise to what matters

    Repeated linkDown and linkUp traps from one port are folded into one item with a count. The operator proposes ifAdminStatus down for a port that flaps past your threshold.

    With Alert Noise

  • Cameras that dropped off the network

    sysUpTime and ifOperStatus polled per camera show which ones rebooted or lost link overnight. The operator lists them by sysLocation for the security lead.

    With Camera Health

  • Hold battery reserve ahead of a storm

    upsEstimatedChargeRemaining and upsBatteryStatus across sites are read before a forecast event. The operator flags units below full charge and proposes a test through upsTestId where the UPS implements it.

    With Storm Reserve

Requirements

  • UDP reach to each device on port 161, and a return path to the connector's listener on port 162 for traps
  • An SNMPv3 user, or a v2c community, with a VACM read view that covers the objects you poll
  • A write view for any SetRequest proposal; most objects are read-only and the device answers notWritable otherwise
  • The MIB modules for vendor objects, so OIDs decode to names and units
Authentication
SNMPv3 User-based Security Model credentials: a userName with an authentication key (HMAC-MD5-96 or HMAC-SHA-96) and a privacy key (CBC-DES) at security level noAuthNoPriv, authNoPriv, or authPriv; SNMPv1 and v2c devices use a community name.

Limits

  • Traps are sent over UDP without acknowledgment and can be lost; InformRequest is acknowledged, but not every device sends it
  • A device is only required to accept messages of 484 octets; larger responses come back as tooBig and must be split
  • ifInOctets is a 32-bit counter that wraps, so high-speed links need the 64-bit ifHCInOctets from the ifXTable
  • USM checks timeliness within a 150 second window against the device's snmpEngineBoots and snmpEngineTime; messages outside it are rejected

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request SNMP ↗

Questions and answers

Which SNMP versions does the connector use?
SNMPv3 with the User-based Security Model and the View-based Access Control Model, as defined in RFC 3411 through 3418. Devices that offer only SNMPv1 or v2c communities can be polled, but those messages carry no authentication beyond the community name.
Does a SetRequest change several objects at once?
Yes. RFC 3416 states that each variable assignment in a SetRequest occurs as if simultaneously with respect to the others in the same request. If any assignment fails, the others are undone and the error-status is commitFailed.
How do traps reach the connector?
Devices send SNMPv2-Trap or InformRequest PDUs to a notification receiver, which RFC 3417 suggests listens on UDP port 162. A trap is unacknowledged; an InformRequest is answered with a Response-PDU, so the sender knows it arrived.
Ask about SNMP

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.