What SNMP does in network operations

Why this matters

The graphs on a network operations centre's wall screens, showing interface traffic, CPU load and which links are down, are almost always fed by SNMP. A monitoring server asks every router and switch for its counters every few minutes, and the devices tell the server straight away when something important happens, such as a link going down. A help-desk analyst moving into networking reads those graphs and alerts on day one, and a network technician is the person who configures the devices so the monitoring works.

Without SNMP, or with it set up badly, problems are found by users instead of by the team. A link that has been flapping all night shows up as a complaint at 9 a.m. And because the older versions of SNMP send their only password in clear text, a careless configuration can let anyone on the network read, or even change, device settings. Knowing what each SNMP version protects, and which ports and messages it uses, is basic operational hygiene.

The lesson

How SNMP supports day-to-day operations

The Simple Network Management Protocol (SNMP) lets a central system read values from network devices, change some of them, and receive notifications from them. It has three parts.

• The SNMP manager is the monitoring system, often called the NMS (network management station). It polls devices, stores the results, draws graphs and raises alerts.
• The SNMP agent is software on each managed device: a router, switch, wireless controller or server. It answers the manager's requests and sends notifications.
• The MIB (management information base) is how the agent organises the values it can expose.

In operations, SNMP is used for:

• Performance monitoring: interface traffic, errors and discards, CPU and memory, polled on a schedule and graphed over time.
• Fault monitoring: notifications when links, power supplies or neighbours fail.
• Capacity planning: months of traffic history show which links will need upgrading.
• Inventory: device names, models, uptime and interface lists, read from every device.

Controllers use SNMP too, as one of their southbound protocols (lesson 26), and some features send SNMP notifications directly, such as storm control's storm-control action trap and port security's restrict mode (lesson 23).

MIBs and OIDs

Every value an agent exposes is an object in a MIB, and every object is named by an OID (object identifier): a dotted string of numbers from a worldwide tree. Standard MIBs, such as IF-MIB for interfaces and SNMPv2-MIB for system details, mean every vendor's device answers the same OID with the same kind of value. Vendors add their own private MIBs for features of their own.

A few objects you will meet:

The manager names an OID in its request, and the agent returns the value. A manager does not read a YAML inventory, a syslog buffer or a routing table directly; it reads objects in the MIB.

SNMP messages

SNMP has a small set of message types, called PDUs (protocol data units).

• Get: the manager reads one or more specific objects.
• GetNext: reads the next object in the tree, which lets a manager walk a table one row at a time.
• GetBulk: reads many objects in one request. Added in SNMPv2c, it makes retrieving large tables, such as every interface's counters, much faster.
• Set: the manager writes a new value to a read-write object. Changing an interface's description through SNMP means a set to that interface's ifAlias. A set needs read-write access; ifDescr cannot be set at all, because it is read-only.
• Response: the agent's reply to a get, getnext, getbulk or set.
• Trap: an unsolicited notification from agent to manager, for example "link down". It is never acknowledged, so the agent cannot tell whether it arrived.
• Inform: also an unsolicited notification, but the manager must acknowledge it. If no acknowledgement arrives, the agent resends it. Use informs when a device must know the event was received.

Polling and notifications complement each other. Polling every five minutes might miss a link that failed for 30 seconds; a trap or inform reports it the moment it happens. Notifications can be lost or suppressed; polling catches the state anyway.

Ports and transport

SNMP runs over UDP.

• The agent listens on UDP port 161 for get, getnext, getbulk and set requests. This is where the manager sends its polls.
• The manager listens on UDP port 162 for traps and informs.

Do not confuse these with UDP 514, which is syslog (lesson 29). SNMP polling is not TCP, in any version you need to know.

Versions and security

A community string is a shared password, set as read-only (RO) or read-write (RW). In SNMPv1 and SNMPv2c it travels in clear text in every message. Anyone who captures the traffic can read the string and reuse it, and if it is a read-write string they can change the device's configuration. There is no encryption in SNMPv2c at all, so a capture shows the whole payload. An ACL on the agent limits which addresses may use the community, which helps, but it does not hide the string or encrypt anything.

SNMPv3 replaces communities with named users and offers three security levels:

• noAuthNoPriv: matches users by name only. No authentication, no encryption.
• authNoPriv: authenticates each message with an HMAC, so the receiver knows who sent it and that it was not altered, but the payload travels in clear text.
• authPriv: authenticates with an HMAC and encrypts the payload, for example with AES. This is the level to choose when policy says SNMP must authenticate every user and encrypt every message.

Configuring an IOS XE agent

SNMPv2c, read-only, limited by an ACL to the monitoring server at 10.20.0.15, with link traps:

R1(config)#access-list 10 permit host 10.20.0.15
R1(config)#snmp-server community Mon1tor-RO-Ex RO 10
R1(config)#snmp-server location Leeds branch, rack 2
R1(config)#snmp-server contact noc@example.com
R1(config)#snmp-server host 10.20.0.15 version 2c Mon1tor-RO-Ex
R1(config)#snmp-server enable traps snmp linkdown linkup

SNMPv3 at authPriv, with informs instead of traps:

R1(config)#snmp-server view NOC-VIEW iso included
R1(config)#snmp-server group NOC-GROUP v3 priv read NOC-VIEW
R1(config)#snmp-server user nms-poller NOC-GROUP v3 auth sha Auth-Ex4mple-Pw priv aes 128 Priv-Ex4mple-Pw
R1(config)#snmp-server host 10.20.0.15 informs version 3 priv nms-poller
R1(config)#snmp-server enable traps snmp linkdown linkup

The keyword priv on the group means authPriv. Using auth there would mean authNoPriv, and noauth would mean noAuthNoPriv. The view limits which part of the MIB tree the group can read. The passwords shown are examples only. Note that SNMPv3 users do not appear in show running-config; check them with show snmp user:

R1#show snmp user

User name: nms-poller
Engine ID: 800000090300AABBCC000100
storage-type: nonvolatile        active
Authentication Protocol: SHA
Privacy Protocol: AES128
Group-name: NOC-GROUP

To see whether polls and notifications are flowing, show snmp gives the agent's packet counters. A rising "Unknown community name" count is a classic sign that a manager is using the wrong string, or that someone is guessing:

R1#show snmp
Chassis: FDO2213A0BC
Contact: noc@example.com
Location: Leeds branch, rack 2
1873 SNMP packets input
    0 Bad SNMP version errors
    14 Unknown community name
    0 Illegal operation for community name supplied
    0 Encoding errors
    5402 Number of requested variables
    0 Number of altered variables
    1859 Get-request PDUs
    0 Get-next PDUs
    0 Set-request PDUs
1859 SNMP packets output
    0 Too big errors (Maximum packet size 1500)
    0 No such name errors
    0 Bad values errors
    0 General errors
    1859 Response PDUs
    0 Trap PDUs

Good practice on any agent follows from what you have read so far:

• Prefer SNMPv3 at authPriv. If v2c must stay for an old tool, make the community read-only, make it long and random, and restrict it with an ACL.
• Do not configure a read-write community unless a tool really needs to make changes. A read-write v2c string is a clear-text password to the device.
• Treat community strings and SNMPv3 passwords as credentials: keep them out of tickets, chat and AI prompts (lesson 25).

Worked example: one poll, decoded

From the monitoring server, an engineer reads R1's uptime with the open-source net-snmp tools, using the SNMPv3 user above:

nms$ snmpget -v3 -l authPriv -u nms-poller -a SHA -A 'Auth-Ex4mple-Pw' -x AES -X 'Priv-Ex4mple-Pw' 10.20.0.1 1.3.6.1.2.1.1.3.0
SNMPv2-MIB::sysUpTime.0 = Timeticks: (81234500) 9 days, 9:39:05.00

Step by step:

1. The manager sends a get to UDP 161 on 10.20.0.1, naming OID 1.3.6.1.2.1.1.3.0 (sysUpTime; the final .0 means the single instance).
2. The message is authenticated with SHA and encrypted with AES, because the level is authPriv. A capture would show neither the OID nor the value.
3. The agent sends a response containing 81,234,500 timeticks, which are hundredths of a second.
4. 81,234,500 / 100 = 812,345 seconds. 9 days is 777,600 seconds, leaving 34,745. That is 9 hours (32,400), leaving 2,345, which is 39 minutes and 5 seconds. So the agent has been up for 9 days, 9:39:05, as the tool prints.

If the same poll used SNMPv2c, step 2 would change: the community string and the whole payload would be readable by anyone capturing the traffic.

What the exam is really asking

• Ports. Agent listens on UDP 161 for polls; manager listens on UDP 162 for traps and informs. Not TCP. UDP 514 is syslog.
• Trap vs inform. Both are unsolicited. Only an inform is acknowledged and resent if lost. "The switch must know the server received it" means inform.
• Get vs set. Reading is get (or getnext or getbulk); writing, such as changing ifAlias, is set and needs read-write access.
• MIB and OID. The agent organises values as MIB objects, each named by an OID.
• v2c weaknesses. A clear-text community string and no encryption. GetBulk arrived in v2c; HMAC user authentication and AES encryption arrived in v3.
• v3 levels. noAuthNoPriv: neither. authNoPriv: authentication only. authPriv: authentication and encryption.