SNMP (Simple Network Management Protocol) provides a framework for remote monitoring and management of network devices. Managers query agents on devices for metrics (CPU, memory, interface statistics) via GET/SET operations. MIBs (Management Information Bases) define the structure of managed data. SNMPv3 adds authentication and encryption.
Install and configure Net-SNMP on Linux. Query MIB objects using snmpget and snmpwalk. Configure SNMP traps (alerts) and monitor them. Set up SNMPv3 with authentication and encryption. Use an SNMP management tool (Zabbix, Nagios) for visualization.
SNMP is not real-time; it uses pull-based polling (except traps). GET operations can fail or time out; retries are essential. MIBs are large and complex; finding the right OID requires documentation or tools like MIB browsers.
From your work with network management concepts and UDP, you know that monitoring a network requires collecting data from many devices — routers, switches, servers, printers — and that UDP provides a lightweight, connectionless transport. SNMP (Simple Network Management Protocol) ties these together: it is the standard protocol for remotely querying and configuring network devices, and it runs over UDP because management traffic needs to be low-overhead and tolerant of occasional lost messages.
SNMP uses a manager-agent architecture. The manager is your monitoring station — the software (like Nagios, Zabbix, or Cacti) that collects and displays network health. Each managed device runs an agent, a small software process that exposes the device's status data. The manager sends requests to agents, and agents respond with data. There are a few core operations: GET retrieves a single value (e.g., the current CPU utilization), GETNEXT walks through a table of values sequentially, GETBULK (introduced in SNMPv2) retrieves many values at once for efficiency, and SET modifies a configuration parameter on the device. In the reverse direction, agents can send unsolicited traps (or informs in SNMPv2/v3) to notify the manager when something important happens — a link going down, a temperature threshold being exceeded, or a login failure.
All the data that an agent can expose is organized in a Management Information Base (MIB). A MIB is essentially a hierarchical tree of variables, each identified by a unique Object Identifier (OID) — a dotted-number address like 1.3.6.1.2.1.1.3.0 (which happens to be system uptime). MIBs are defined in a formal language called SMI (Structure of Management Information), and vendors publish MIB files for their equipment. When you run `snmpwalk` against a device, you are traversing this tree, reading each OID's current value. The challenge in practice is finding the right OID for the metric you want — MIB browsers and vendor documentation are essential tools.
Security evolved significantly across SNMP versions. SNMPv1 and SNMPv2c use community strings — essentially plaintext passwords ("public" for read, "private" for read-write) sent with every request. This is alarmingly insecure: anyone who can sniff the network traffic can read or even modify device configurations. SNMPv3 addressed this by adding proper authentication (verifying who is sending the request using HMAC-based protocols) and encryption (protecting the message contents with DES or AES). For any production network, SNMPv3 with authentication and encryption is essential — leaving devices accessible via SNMPv2c community strings is one of the most common and dangerous misconfigurations in network management.