SNMP explained: MIBs, OIDs, traps and SNMPv3

SNMP has two roles. The manager, your monitoring system, asks questions. The agent, on the router or switch, answers them.

Requests go to the agent on UDP port 161. Notifications, the messages a device sends without being asked, go to the manager on UDP port 162. Every message is encoded in ASN.1, and an agent must accept messages of at least 484 octets.

What an agent exposes is described in its MIB, a tree of numbered objects. Each object has an object identifier, an OID, read from the root.

1.3.6.1 is the internet branch. Under it, mib-2, at 1.3.6.1.2.1, holds the standard objects every vendor implements. Enterprises, at 1.3.6.1.4.1, gives each vendor its own branch: Huawei's is 2011. The system group comes first, and its first and third objects, sysDescr and sysUpTime, tell you what the device is and how long it has been running.

The manager has a few verbs. Get reads one object. GetNext reads the object that follows, which is how a whole table is walked. Set writes.

Version 2 added GetBulk, which returns many successors in one response, and that is what makes walking a large interface table fast. Version 1 has no GetBulk. When something is missing, version 1 answers with the error noSuchName, and version 2 with exceptions such as noSuchObject and endOfMibView.

Polling asks. Notifications tell. A trap is sent once and never acknowledged: Cisco calls traps unreliable for exactly that reason. An inform is acknowledged by the manager and resent until it is, at the price of memory on the device while it waits. Version 1 has no informs.

Every version 2 notification starts with the same two values: the device's uptime, and the trap OID that names what happened, an interface going down for example.

Versions 1 and 2c authenticate with a community string, a password sent in clear text in every packet. Cisco and Aruba both say so in their own guides. RFC 3410 calls these versions fundamentally insecure, and compares allowing them to guarding the front door while leaving the back door open.

A read only community still reveals interfaces, addresses and names. A read write community gives away control.

Version 3 replaces communities with users. The user based security model has three levels. noAuthNoPriv: no authentication, no encryption. authNoPriv: messages are signed. authPriv: signed and encrypted. Privacy without authentication does not exist; the RFC forbids that combination.

Authentication started with MD5 and SHA-1, and SHA 256 came with RFC 7860. Encryption started with DES, then AES 128 in RFC 3826. A message outside a 150 second window is refused.

Every agent has an engine ID, and each user's keys are derived from the password and that engine ID, so the same password gives a different key on every device.

The consequence is documented by Cisco and by Juniper: set the engine ID before you create users, because changing it later invalidates every user, and they must all be configured again. On a Cisco stack, a priority change followed by a reload can also break version 3 authentication.

What a user or a community may read is a view. A view includes or excludes subtrees of the MIB, and groups tie users to a read view, a write view and a notify view. Cisco is explicit: anything not included is implicitly denied.

Pair views with an access list on the agent, so only your managers can ask at all. On Juniper, a community with no clients statement accepts everyone, and on Aruba, a community with no access list allows all hosts.

Here is version 3 with authentication and encryption on each vendor. Cisco: a view, a group at the privacy level with an access list, and a user with SHA and AES. Huawei: a group with privacy, and a user with SHA 256 and AES 128.

Aruba: a version 3 user with authentication and privacy, plus one command that turns the old versions off. Juniper: a user under the local engine, mapped to a group by the access control model.

Defaults differ, and they matter. On Cisco the agent is off until you configure it, and a host with no version keyword gets version 1. Aruba ships SNMP disabled, and by default only authPriv users may connect.

Huawei's guide states that version 3 is its default. Juniper's version 3 defaults are no authentication and no privacy until you set them.

Three failures come back again and again. The manager times out: Huawei's checklist is a version mismatch, a wrong community, the manager blocked by the access list, an object outside the view, or a poller timeout shorter than the device needs.

Informs never arrive: without the manager's engine ID and a matching user, they are not sent. And on some Cisco releases, a community made for traps also answers polls, unless an access list restricts it.

NacTrack's SNMP module, in beta, checks every device's reachability every minute, and reads interface counters and health every five minutes, in versions 1, 2c and 3. It receives traps on the appliance and turns them into events.

The availability page shows the fleet, the downtime and the devices down right now. The events page lists every trap and state change, matched to the inventory.