§5.7.1–5.7.2The Network Management Framework · SNMP and the MIB

Network layer Kurose & Ross pp. 425–432 · ~21 min read

  • network management
  • managing server
  • managed device
  • network management agent
  • snmp
  • mib
  • trap

Where you are

  • Application layer
  • Transport layer
  • Network layer you are here
  • Link layer
  • Physical layer

Network management is one server, many devices with agents inside them, and a protocol between. SNMP (Simple Network Management Protocol) is the old and widely used protocol that reads numbers out of devices and receives their alarms.

Words you will meet

  • Managing server — the machine an operator uses to watch and change the network, in the network operations centre ( NOC (Network Operations Centre) ).

  • Managed device — anything on the network being managed: a router, a host, a modem, a thermometer.

  • Agent — the small program inside a managed device that takes orders.

  • SNMP — the protocol between them, in use since the late 1980s.

  • MIB — Management Information Base: the collection of values a device exposes.

  • SMI — the language MIB objects are defined in.

  • Trap — an unsolicited message from an agent, reporting an event.

  • PDU (Protocol Data Unit) — the generic name for one protocol message. SNMPv3 has seven kinds.

Why this matters

Section 5.5 showed a logically centralized controller managing a network. That is new. The problem is old.

A network is hundreds or thousands of interacting pieces of hardware and software, and somebody has to keep it running. The tools for that predate SDN (Software-Defined Networking) by decades and are still everywhere.

This section is the framework and the old protocol. Section 5.7.3 is the new one, and it exists because a committee wrote down in 2002 exactly what the old one could not do.

What network management is

The book quotes a definition it admits is a long run-on sentence, and it is worth reading slowly.

Network management includes the deployment, integration, and coordination of the hardware, software, and human elements to monitor, test, poll, configure, analyze, evaluate, and control the network and element resources to meet the real-time, operational performance, and Quality of Service requirements at a reasonable cost.

In plain words

Three things in that definition are easy to skim past.

“Human elements.” People are part of the system being coordinated, not outside it.

Seven verbs. Monitor, test, poll, configure, analyze, evaluate, control. Only two of them change anything; five are about finding out.

“At a reasonable cost.” Network management is an economic activity, not only a technical one.

The framework

Figure 5.20 — the five components of network management
1 · the managing server, with humans in the loopstep 1 of 5
Network managers (humans)Managing serverconfiguration andoperational data store

An application running in a centralized network management station in the network operations centre. It controls the collection, processing, analysis and dispatching of network management information and commands. A network may have several of them.

Everything an operator does passes through this shape: a person, a server, a protocol, an agent, and the data the agent guards.

Read all steps as text
  1. 1 · the managing server, with humans in the loopAn application running in a centralized network management station in the network operations centre. It controls the collection, processing, analysis and dispatching of network management information and commands. A network may have several of them.
  2. 2 · the managed devicesA managed device is any piece of network equipment, including its software, on the managed network: a host, router, switch, middlebox, modem, thermometer or anything else attached. Each has many manageable components and configuration parameters for them.
  3. 3 · the data each device holdsThree kinds. CONFIGURATION data is what the manager explicitly set — an assigned IP address, an interface speed. OPERATIONAL data is what the device learned while running, such as its list of immediate OSPF neighbours. STATISTICS are counts updated as it operates: dropped packets on an interface, or the cooling fan speed.
  4. 4 · an agent inside every deviceA software process running in the managed device that communicates with the managing server and takes local actions under its command and control. The book says it is similar to the routing control agent of Figure 5.2 — the same shape of idea, one section apart.
  5. 5 · and the protocol between themIt lets the managing server query the status of devices and act on them through their agents, and lets agents report exceptional events such as a component failure. Note carefully: the protocol does not manage the network. It provides capabilities that human network managers use to manage it. The book calls that a subtle but important distinction.

The protocol does not manage the network

The book makes a point of this and calls it subtle but important.

A network management protocol provides capabilities. It lets a server ask a device a question, tell a device to change something, and lets a device report an event. That is all it does.

The managing is done by people, using those capabilities. Nothing in SNMP (Simple Network Management Protocol) knows what a healthy network looks like or what should be done about a failure.

Three ways operators actually work

The three ways operators actually manage a network
CLItype commands at the deviceSNMP / MIBquery and set object valuesNETCONF / YANGsection 5.7.3
What you do
Used mostly for
How many devices at a time
Where it struggles

Cells marked ⓘ have a reason behind them — click to read it.

All three are in use today, and the book presents them in the order they appeared. Click any cell for the detail.

The middle column is this section’s subject and the right column is the next one’s. Note the row about how many devices at a time: CLI (Command Line Interface) and SNMP both manage devices individually, and that limitation is most of the reason the third column exists.

SNMP and the MIB

SNMP version 3 is an application-layer protocol that carries network-management control and information messages between a managing server and an agent acting on its behalf.

It is used in two ways.

Request-response. The server sends a request, the agent receives it, performs some action, and sends a reply. Typically the request queries or modifies MIB object values on the managed device.

Traps. An agent sends an unsolicited message to notify the server of an exceptional situation. A link interface going up or down is the book’s example. Such a situation has changed MIB object values.

Table 5.2 — the seven SNMPv3 PDU types
PDU typeSender → receiverDescription

Cells marked ⓘ have an explanation — click to read it.

Read the middle column first. Six of the seven have a fixed direction, and the exception is the one that answers everything else.

Figure 5.21 — the SNMP PDU format
Get / set PDUPDU type (0–3)Request IdError Status (0–5)Error IndexNameValueNameValueTrap PDUPDU type (4)EnterpriseAgent AddrTrap Type (0–7)Specific codeTime stampNameValue

Click any box to read what that part of the message is for.

Every field, as text
  • PDU type (0–3) — which of the request or response messages this is (example: 0)
  • Request Id — ties a response back to its request (example: 4711)
  • Error Status (0–5) — did it work (example: noError)
  • Error Index — which variable went wrong
  • Name — the MIB object asked about (example: ipSystemStatsInDelivers)
  • Value — its value (example: 1 048 213)
  • Name
  • Value
  • PDU type (4) — this one is a trap (example: 4)
  • Enterprise — whose device this is
  • Agent Addr — which device is reporting
  • Trap Type (0–7) — which well-known event (example: linkDown)
  • Specific code — a vendor’s own refinement
  • Time stamp — when it happened
  • Name
  • Value

The book draws the fields as boxes without bit widths, and so does this: SNMP values are encoded with a length in front of them, so no field has a fixed size. Click any box.

SNMP in its two modes

The most common usage. The server asks, the agent performs some action, the agent replies.

message 2 of 2
Managing serverin the network operations centreTimeAgent, in a routerguards the MIBTimerequest Id matches — nothing was lostGetRequest · id=4711 · ipSystemStatsInDeliversResponse · id=4711 · 1 048 213

Click any arrow to see what that message says and why it is sent.

The request Id is the only thing tying a response to its request. That one field is doing the job TCP would otherwise have done.

Read this diagram as text
  1. Managing server sends GetRequest · id=4711 · ipSystemStatsInDelivers to Agent, in a router. A request to retrieve one MIB object value. The MIB objects being asked about are named in the variable binding part of the PDU — the Name and Value boxes in Figure 5.21.
  2. Agent, in a router sends Response · id=4711 · 1 048 213 to Managing server. The agent responds with a Response PDU containing the object identifiers and their associated values. Its request Id is copied from the request, which is how the server pairs them up.

Lifelines, left to right: Managing server (server), Agent, in a router (router).

SNMP rides on an unreliable transport, and nothing repairs a loss

An SNMP PDU (Protocol Data Unit) can be carried over many transport protocols, but it is typically carried in the payload of a UDP (User Datagram Protocol) datagram. RFC (Request For Comments) 3417 calls UDP “the preferred transport mapping”.

UDP is unreliable, so there is no guarantee that a request or its response arrives. The request Id field is what makes this survivable. The server numbers its requests and the agent copies that number into its response, so the server can notice that something never came back.

What happens next is deliberately unspecified. The standard mandates no retransmission procedure, and does not even say whether to retransmit. It only requires that the managing server “needs to act responsibly in respect to the frequency and duration of retransmissions”.

Security arrived late, again

SNMP has evolved through three versions, and its designers describe SNMPv3 as “SNMPv2 with additional security and administration capabilities”.

The consequence of the earlier gap is concrete. Because there was not adequate security, SNMP was used primarily for monitoring rather than controlSetRequest was rarely used in SNMPv1. A protocol that can read but is not trusted to write is half a protocol.

The book draws a general lesson here, and chapter 8 returns to it. Security turns out to be of critical concern. Its importance is realised a bit late, and it is then “added on”.

The Management Information Base

A managed device’s operational state, and to some extent its configuration data, are represented as objects gathered into a MIB for that device.

An object might be a counter. The book’s examples are the number of IP (Internet Protocol) datagrams a router discarded because of header errors, and the number of carrier sense errors on an Ethernet interface card. It might instead be descriptive information, such as the software version running on a DNS (Domain Name System) server. It might be status information, such as whether a device is functioning correctly. Or it might be protocol-specific, such as a routing path to a destination.

Related objects are gathered into MIB modules. There are over 400 defined in RFCs, and many more device- and vendor-specific ones. RFC 4293 defines the module for IP (Internet Protocol) and ICMP (Internet Control Message Protocol) , RFC 4022 the one for TCP (Transmission Control Protocol) , and RFC 4113 the one for UDP.

MIB objects themselves are specified in a data description language called SMI , Structure of Management Information — a name the book notes gives no hint of its function. A formal definition language is used so that the syntax and semantics of management data are unambiguous.

One real MIB object

The book says reading MIB RFCs is dry, and then says looking at one is good for you anyway. Here is ipSystemStatsInDelivers, from RFC 4293.

ipSystemStatsInDelivers OBJECT-TYPE
     SYNTAX Counter32
     MAX-ACCESS read-only
     STATUS current
     DESCRIPTION
        "The total number of datagrams successfully de-
        livered to IP user-protocols (including ICMP).

           When tracking interface statistics, the coun-
           ter of the interface to which these datagrams
           were addressed is incremented. This interface
           might not be the same as the input interface
           for some of the datagrams.

          Discontinuities in the value of this counter can
          occur at re-initialization of the management
          system, and at other times as indicated by the
          value of ipSystemStatsDiscontinuityTime."
  ::= { ipSystemStatsEntry 18 }

In plain words

Six lines of definition, and every one of them earns its place.

Counter32 is one of the basic data types defined in SMI. It is a 32-bit counter, so a reader knows it wraps.

read-only says this object can never be the target of a SetRequest.

STATUS current says the definition is still in force, rather than deprecated.

The description does two things a bare name cannot. It says what is counted — datagrams delivered to an upper-layer protocol, including ICMP — and it warns that the count can jump when the management system restarts. A counter that can jump is a counter you must not subtract naively.

::= { ipSystemStatsEntry 18 } places the object in the naming tree, so it has a globally unique identifier and not just a name.

Everyday picture

A building with a caretaker in every room.

The caretakers do not decide anything. Each one keeps a clipboard of numbers about their own room: temperature, how many times the door opened, whether the lamp works. They answer when the office calls to ask for a figure.

If something dramatic happens, a caretaker phones the office without waiting to be asked. That call is a trap.

Where the picture stops. A caretaker would tell you what the numbers mean. An agent will not: it hands over a counter, and every judgement about whether that counter is bad news belongs to the person at the managing server.

Check yourself

Check yourself

0 of 7 answered
  1. 1.The book calls one distinction about the network management protocol "subtle, but important". What is it?

  2. 2.A device reports its list of immediate OSPF neighbours. Which of the three kinds of data is that?

  3. 3.What did the Internet Architecture Board's 2002 network-management workshop conclude about SNMP and MIBs?

  4. 4.Which SNMPv3 PDU type can be sent by an agent without having been asked for anything?

  5. 5.predictA managing server sends a GetRequest with request Id 4713 over UDP, and it is lost. What does the standard require the server to do?

  6. 6.The MIB object ipSystemStatsInDelivers is declared MAX-ACCESS read-only. What follows from that?

  7. 7.Why was SetRequest rarely used in SNMPv1?

What to remember

  • Five components: a managing server, managed devices, the data those devices hold, an agent inside each device, and a protocol between server and agents.
  • The protocol does not manage the network. It provides capabilities; people manage.
  • SNMP is used two ways: request-response to read or write MIB values, and unsolicited traps to report events. It typically rides on UDP, and the standard leaves retransmission entirely to the server’s judgement.