Part 24 – How SNMP Works

How SNMP Works

Table Of Contents
  1. How SNMP Works
  2. Resources

Introduction

Welcome to Part 24 of the Network Fundamentals study notes! If you haven’t already, we recommend watching the video first.

Imagine managing a network with 100 routers, switches, and all the links between them. Everything is running fine — until it isn’t. Calls drop, the internet slows down, and it’s your job to find which of those 100 devices is the culprit. Syslog helps, but what if you had a server that proactively monitors every device’s health and alerts you before problems become crises? That’s what SNMP — Simple Network Management Protocol — is for.

What SNMP Collects

A management server uses SNMP to collect data from the devices it monitors. This can include link speeds, CPU and memory utilisation, temperature, fan speeds, interface error rates, and much more — essentially anything the device is willing to report.

The management server typically does several things with this data: it records it historically (so you can see trends over time), presents it as graphs and charts, provides a dashboard showing overall network health (often with traffic-light style indicators), and sends alerts when something is wrong — or when a problem looks likely. For example, receiving an email that a server has less than 10% disk space remaining lets you fix the problem before anyone’s affected.

Polling and Traps

SNMP works in two complementary ways:

  • Polling – the management server regularly sends SNMP queries (using UDP port 161) to each managed device, asking for current status information. The device responds with its data. Polling is proactive — you can see the state of your network at any moment. The polling interval can be configured, from every few seconds to every few minutes depending on your needs.
  • Traps – rather than waiting to be asked, devices can send an SNMP trap to the management server when a significant event occurs — a fan stops spinning, CPU usage spikes, or an interface goes down. Traps are reactive but fast, notifying the server immediately when something happens.

In practice, you’ll use both — polling for regular health checks and traps for immediate event notification.

MIBs and OIDs

MIB – Management Information Base

A MIB is a hierarchical database that describes everything a device is willing to share about itself via SNMP. The structure is similar to a DNS namespace — starting from a root, branching into increasingly specific nodes. The further down you go, the more specific the information.

Vendors like Cisco publish MIB files that you download and install on your management server. The MIB file tells the server how to interpret the data for that specific product — a printer’s MIB might include toner levels, while a switch’s MIB covers interface statistics.

OID – Object Identifier

At the end of each branch in the MIB hierarchy sits an object — a specific piece of information. Each object has both a name and a numeric path called an OID (Object Identifier). For example, the OID for CPU usage on a Cisco router is a long dotted number representing the path through the hierarchy to that specific value.

In practice, you rarely need to work with OIDs directly. Once a MIB file is installed on the management server, the server handles all the OID mapping for you. OIDs are mostly relevant when you need to query something unusual that isn’t in the standard MIB your server already knows about.

Community Strings

SNMP devices are configured with a community string — a label that acts like a password. When a management server polls a device, it includes the community string in the request. If the string doesn’t match what’s configured on the device, the device ignores the request.

Community strings come in two flavours: read-only (for monitoring) and read-write (which allows the management server to change device configuration). Read-write access is rarely needed and generally not recommended — there are better methods for managing device configuration remotely.

The critical weakness: community strings are sent in plaintext and are not encrypted. This is one of the main reasons SNMPv3 was developed.

SNMP Versions

  • SNMPv1 – the original. Functional, but limited to 32-bit counters (which wrap around on high-traffic interfaces) and uses plaintext community strings.
  • SNMPv2c – adds 64-bit counter support (much better for counting large numbers of packets) but still uses plaintext community strings. Still very widely deployed.
  • SNMPv3 – adds proper username and password authentication and encryption of SNMP messages. Significantly more secure. This is what you should use.

Security Best Practices

  • Use SNMPv3 wherever possible.
  • If using v2c, never use default community strings like “public” or “private” — they’re well-known and attackers try them first.
  • Restrict which IP addresses can poll your devices. Typically this should only be your management server IPs.
  • Disable SNMP write access unless you have a specific, justified need for it.

Basic Cisco Configuration

snmp-server community routers ro
snmp-server host 192.168.1.100 version 2c routers
snmp-server enable traps config

The first line creates a read-only community string called “routers”. The second line specifies which management server is allowed to poll using that string. The third line enables traps for configuration changes — so whenever the router’s config is modified, the management server gets an alert. Many other trap types are available depending on what you want to monitor.

Resources

Test your knowledge with the Introduction to Networking quizzes.