skip to content

SNMP

Managers poll MIB objects over UDP with Get and GetBulk, agents push traps and informs, and v3 adds per-user auth and encryption. Network gear still speaks it, so monitoring interviews reach it.

on this pageshow

explore

questions

page 1 of 2

In SNMP, what do the manager and the agent each do, and which UDP ports carry requests and notifications?

level: juniorimportance: must knowfreq 55%

answer

  1. two roles, traffic in two directions
  2. who asks and who answers
  3. RFC 3411's five application types
  4. requests inbound, notifications outbound
  5. which side listens on which port

basics

~20 s

An SNMP manager sends requests to agents and receives their notifications; the agent on each managed device answers from its managed objects and sends notifications on events. Requests go to the agent on UDP 161, notifications to the manager on UDP 162.

solid answer

~40 s

An SNMP **agent** runs on every managed device: it answers `GetRequest`, `GetNextRequest`, `GetBulkRequest` and `SetRequest` messages against the objects its MIB view exposes, and it originates notifications when something happens on the device. The **manager** (the management station) sends those requests and receives the notifications. RFC 3411 describes both as SNMP entities made of applications: a manager holds a *command generator* and a *notification receiver*, an agent a *command responder* and a *notification originator*, and a *proxy forwarder* relays messages between entities. Over UDP the agent listens on **161** and the manager listens for notifications on **162** (RFC 3417 §3.2, RFC 1157 §4); responses return to whatever source port the manager used. One entity can hold both sets of applications - RFC 3411 calls it a mid-level manager or dual-role entity.

go deeper

for a junior

Recall the two roles and the two ports: the manager asks and listens on 162 for notifications; the agent answers on 161 and can also speak first when something happens.

for a middle

Explain RFC 3411's applications - command generator, command responder, notification originator, notification receiver, proxy forwarder - and map each to the traditional manager and agent, including dual-role entities.

for a senior

Translate the roles into firewall rules and failure modes: which flows each direction needs, what breaks when only 161 is open, and why 161 and 162 are suggested defaults rather than constants.

for a principal

Use the application model to place mid-level managers and proxies in a large estate, weighing summarisation and isolation against extra hops, extra state and another component to secure.

## The two traditional roles SNMP (the Simple Network Management Protocol) splits network management between two kinds of participant: - The **agent** lives on each **managed device** - a switch, router, server or printer. It has access to the device's **management instrumentation**: interface states, counters, configuration values. It answers questions about them and reports events. - The **manager** (also called a **management station**) is the system the operator runs. It asks agents for values, occasionally changes one with a `SetRequest`, and collects the events agents report. The values themselves are **managed objects**, named by OBJECT IDENTIFIERs and defined in MIB modules. The agent never hands out everything it knows: each request is answered from a **MIB view**, the subset of objects that this particular request may see. ## What RFC 3411 actually defines The SNMPv3 architecture (RFC 3411, part of Internet Standard 62) stops talking about "managers" and "agents" as boxes. It defines an **SNMP entity** as an SNMP engine plus one or more **applications**, and names five application types: | Application | What it does | Traditionally part of | |---|---|---| | `command generator` | monitors and manipulates management data by sending requests | manager | | `command responder` | provides access to management data by answering requests | agent | | `notification originator` | initiates asynchronous messages | agent | | `notification receiver` | processes asynchronous messages | manager | | `proxy forwarder` | forwards messages between entities | proxy agent | In RFC 3411's words, an entity with command generator and/or notification receiver applications "has traditionally been called an SNMP manager", and one with command responder and/or notification originator applications "an SNMP agent". The decomposition matters because real systems mix them. ## Ports, and which way the traffic flows The preferred transport mapping is **SNMP over UDP** (RFC 3417 §3), one message per datagram. Two well-known ports appear: 1. **Requests**: the manager sends `GetRequest`, `GetNextRequest`, `GetBulkRequest` or `SetRequest` from an ephemeral source port to the agent's **UDP 161**. 2. **Responses**: the agent's `Response` returns to that ephemeral port. RFC 1157 §4.1 states the rule for SNMPv1: the response is sent *from* the transport address the request was sent *to* - so it leaves from 161. 3. **Notifications**: when something happens - an interface about to go down, a restart - the agent's notification originator sends a trap or inform to the manager's **UDP 162**. RFC 3417 §3.2 words both as suggestions: it is "suggested" that command responders listen on 161 and notification receivers on 162. They are well-known defaults, not protocol constants; an operator may move either, at the price of reconfiguring every manager or every agent's notification target to match. Other transport mappings use other ports: SNMP over TLS and DTLS (RFC 6353) registers **10161** for requests and **10162** for notifications. RFC 3417 also sets a floor on message size: an entity using the UDP mapping must accept messages up to **484 octets**, and RFC 3417 recommends accepting up to 1472. ## Entities that are both Because roles are applications, one entity can hold several: - A **mid-level manager** (RFC 3411's "dual-role entity") runs command generator and notification receiver applications toward the devices below it, and command responder and notification originator applications toward a manager above it - useful for summarising a region before a central station sees it. - A **proxy forwarder** relays requests and notifications to another engine by context, without interpreting the objects inside them (RFC 3413 §1.5); it is how a modern manager can reach a device speaking an older SNMP version. - An **extensible agent** (AgentX, RFC 2741) splits one agent into a master agent and subagents internally, while still looking like one agent to the manager. ## Mistakes worth avoiding - Swapping the ports: 161 is where the *agent* listens; 162 is where the *manager* listens. - Thinking the agent only answers. The notification originator lets it speak first, which is exactly how a manager hears about an event between polls. - Assuming one box is one role. A monitoring server that forwards events upward, or a gateway translating versions, holds both kinds of application. - Opening only 161 on a firewall between the two and then wondering why no notifications arrive.

  • Which UDP flows must a firewall between an SNMP manager and its switches allow?
    Manager ephemeral port to each agent's UDP 161 for requests, plus the agent's response from 161 back to that ephemeral port, which a stateful firewall matches to the request. Agent to the manager's UDP 162 for notifications, and if agents send informs, the manager's acknowledgement back to the agent. SNMP over TLS or DTLS (RFC 6353) uses 10161 and 10162 instead.
  • Are UDP 161 and 162 mandatory in SNMP?
    No. RFC 3417 §3.2 only "suggests" that command responders listen on 161 and notification receivers on 162. They are the well-known defaults every implementation assumes, so moving one means reconfiguring every manager that polls, or every agent's notification target, to match.

saying these in an interview costs you the question

  • The manager listens on UDP 161 and agents send their data to it.
  • Traps are sent to the agent's UDP port 161.
  • An SNMP agent only ever answers; it can never send anything first.
  • One system is either a manager or an agent, never both.
  • SNMP needs a TCP connection between manager and agent for every poll.
open as a page

In SNMP, what is an object identifier, and how does the numeric OID 1.3.6.1.2.1.1.3.0 map to a named MIB object?

level: juniorimportance: must knowfreq 45%

basics

~10 s

An OID is a path of numbered arcs through a global registration tree. 1.3.6.1.2.1.1.3.0 reads iso.org.dod.internet.mgmt.mib-2.system.sysUpTime plus .0, the single instance of that scalar; a MIB module supplies the name, type and meaning.

open as a page

What do the SNMP GetRequest, GetNextRequest, GetBulkRequest and SetRequest PDUs each ask an agent to do, and what comes back?

level: juniorimportance: must knowfreq 42%

basics

~20 s

GetRequest reads exactly the named instances; GetNextRequest returns each name's successor in OID order; GetBulkRequest returns many successors at once; SetRequest writes values all or nothing. Each is answered by a Response-PDU with the same request-id, an error-status and an error-index.

open as a page

Why are SNMPv1 and SNMPv2c community strings considered insecure, and what does SNMPv3 put in their place?

level: juniorimportance: must knowfreq 58%

basics

~20 s

An SNMPv1 or SNMPv2c community string is a shared password sent unencrypted in every message, so one captured packet lets anyone reuse it, and nothing protects integrity or freshness. SNMPv3 replaces it with per-user authentication, optional encryption and view-based access control.

open as a page

How do you compute a link's utilisation from SNMP IF-MIB octet counters polled twice, and which speed object do you divide by?

level: middleimportance: must knowfreq 42%

basics

~10 s

Difference two readings of ifHCInOctets (or ifHCOutOctets), multiply by 8, divide by the seconds between the polls, then divide by the interface speed, ifHighSpeed x 1,000,000 bit/s. Each direction is computed separately.

open as a page

In SNMP, what is the difference between a Trap and an InformRequest, and what does the sending agent learn from each?

level: middleimportance: must knowfreq 40%

basics

~20 s

An SNMP Trap is fire-and-forget: the agent sends it once and learns nothing. An InformRequest is confirmed: the receiver answers with a Response-PDU, and the agent retransmits on timeout until a retry count runs out.

open as a page

What do SNMPv3's three security levels - noAuthNoPriv, authNoPriv and authPriv - each protect, and why is there no privacy-only level?

level: middleimportance: must knowfreq 40%

basics

~20 s

noAuthNoPriv names a user but proves nothing; authNoPriv adds an HMAC proving the user, integrity and freshness; authPriv also encrypts the scoped PDU. RFC 3412 forbids privacy without authentication: unauthenticated ciphertext could be altered or replayed undetected.

open as a page

Monitoring 300 campus switches with SNMP, why poll on a five-minute loop and also take link-down notifications, and what does each one miss?

level: seniorimportance: must knowfreq 35%

basics

~20 s

SNMP polling gives complete, regular data and proves each agent still answers, but sees a failure up to one interval late and misses flaps between polls. Notifications arrive within seconds but only on events and can be lost, so estates use both.

open as a page

Why does a 32-bit SNMP ifInOctets counter fail on a 10 Gb/s link, and what does RFC 2863 require instead?

level: seniorimportance: must knowfreq 35%

basics

~20 s

A Counter32 octet counter wraps after 2^32 octets, about 3.4 seconds at 10 Gb/s, so a poller cannot count the wraps between polls. RFC 2863 requires 64-bit ifHCInOctets above 20 Mb/s, and 64-bit packet counters from 650 Mb/s.

open as a page

An SNMP poller times out walking a 40,000-row table on a core router with chained GetNextRequests; how does GetBulkRequest fix it, and how do you size max-repetitions?

level: seniorimportance: must knowfreq 32%

basics

~20 s

Chained GetNext pays a round trip and a full message-processing pass per row. GetBulkRequest returns up to max-repetitions rows per exchange; size that value so each reply fits the manager's maximum message size and one unfragmented datagram, and keep it small under stress.

open as a page

An audit finds the SNMP community 'public' answering on 400 devices; how do you plan the move from SNMPv1 and SNMPv2c communities to SNMPv3?

level: seniorimportance: must knowfreq 30%

basics

~20 s

Contain first: remove read-write communities, replace and source-restrict the read ones. Then add SNMPv3 users at authPriv beside the communities, move pollers and notification receivers device group by group, watch for leftover community traffic, and finally delete the communities.

open as a page

In SNMP's IF-MIB, what does ifAdminStatus up with ifOperStatus down say about an interface, and how is that different from both being down?

level: juniorimportance: should knowfreq 38%

basics

~20 s

ifAdminStatus is the desired state and ifOperStatus the actual one. Admin up with oper down means the interface should work but cannot, so RFC 2863 presumes a fault; both down means it was disabled on purpose, with no fault implied.

open as a page

In SNMPv3, what does the User-based Security Model check on each message, and what does the View-based Access Control Model decide afterwards?

level: juniorimportance: should knowfreq 30%

basics

~20 s

The User-based Security Model (RFC 3414) establishes which user sent an SNMPv3 message and protects it with authentication, a replay window and optional encryption. The View-based Access Control Model (RFC 3415) then decides which objects that user may read, write or receive.

open as a page

An SNMP agent answers noSuchObject for an object its device's MIB module defines; how can the agent's MIB view explain that?

level: middleimportance: should knowfreq 18%

basics

~20 s

An SNMP agent answers each request only from the MIB view selected for that requester. An object outside the view is treated exactly like one that does not exist, so a Get gets noSuchObject or noSuchInstance and a walk skips it.

open as a page

In SNMP's IF-MIB, how do ifOutDiscards and ifOutErrors differ, and what does a rising discard count on a moderately loaded uplink suggest?

level: middleimportance: should knowfreq 22%

basics

~20 s

ifOutDiscards counts outbound packets dropped although no error was detected, for example to free buffer space; ifOutErrors counts packets that could not be sent because of errors. Rising discards at moderate average utilisation usually mean bursts overflowing the output buffer.

open as a page

In an SNMP MIB, why does a scalar's instance end in .0 while a table column's ends in index values, and how are they encoded?

level: middleimportance: should knowfreq 25%

basics

~20 s

SMIv2 names a scalar's single instance by appending .0; a table column has one instance per row, so its suffix is the row's INDEX values: an integer as one sub-identifier, a variable-length string as its length then one sub-identifier per octet.

open as a page

In an SMIv2 MIB module, what does each clause of the OBJECT-TYPE macro declare, and how do textual conventions refine its SYNTAX?

level: middleimportance: should knowfreq 22%

basics

~20 s

OBJECT-TYPE registers an object's OID and declares its SYNTAX, MAX-ACCESS, STATUS and DESCRIPTION, plus optional UNITS, REFERENCE, INDEX or AUGMENTS, and DEFVAL. A textual convention is a named sub-type of a base type that adds meaning and a display hint, never a new wire type.

open as a page

In an SNMP Response-PDU, what do error-status and error-index tell the manager, and how do SNMPv2 exceptions such as noSuchInstance differ?

level: middleimportance: should knowfreq 20%

basics

~20 s

A non-zero error-status says the whole request failed, and error-index names the failing binding, counting from one. SNMPv2 exceptions instead mark one binding (noSuchObject, noSuchInstance, endOfMibView) while error-status stays noError and the other values are returned.

open as a page

How does an SNMP manager walk a MIB table with GetNextRequest, and how does it know the table has ended?

level: middleimportance: should knowfreq 30%

basics

~20 s

The manager sends GetNextRequest with a column's OID, gets the first instance after it, and keeps sending back the name it received. The column has ended when a returned name leaves the column's OID prefix, or the agent returns endOfMibView.

open as a page

How does an SNMPv1 Trap-PDU identify an event compared with an SNMPv2-Trap-PDU, and where does each carry the event's time and source?

level: middleimportance: should knowfreq 22%

basics

~20 s

A v1 Trap-PDU names the event in fixed fields: enterprise, agent-addr, generic-trap 0-6, specific-trap and time-stamp. An SNMPv2-Trap-PDU has none of these; its first two varbinds, sysUpTime.0 and snmpTrapOID.0, carry the time and the event's identity.

open as a page

What did community-based SNMPv2c add over SNMPv1, and what did it leave unchanged?

level: middleimportance: should knowfreq 38%

basics

~10 s

SNMPv2c added GetBulkRequest, InformRequest, the SNMPv2-Trap format, Counter64 and per-variable exceptions with richer error codes. It kept SNMPv1's message wrapper and cleartext community string, changing only the version field from 0 to 1.

open as a page

Is SNMPv3 a new protocol or SNMPv2 with security added, and what actually changes in an SNMPv3 message?

level: middleimportance: should knowfreq 24%

basics

~20 s

SNMPv3 keeps SNMPv2's PDUs and operations from RFC 3416 and replaces the message around them: msgVersion 3, a header with message ID, maximum size, flags and security model, security-model parameters, and a scoped PDU naming a context, optionally encrypted.

open as a page

An SNMPv3 manager must monitor a few legacy switches that speak only SNMPv1; what does an SNMP proxy forwarder do, and where should it sit?

level: seniorimportance: should knowfreq 12%

basics

~20 s

An SNMP proxy forwarder (RFC 3413) relays requests and notifications to another SNMP engine by context, without interpreting the objects; under RFC 3584 it also translates versions. Place it next to the SNMPv1 switches, because its downstream leg still carries a cleartext community.

open as a page

An SNMP utilisation graph for a 10 Gb/s uplink drops to zero or spikes absurdly after a line card swap; how does IF-MIB let a poller detect counter discontinuities?

level: seniorimportance: should knowfreq 20%

basics

~20 s

IF-MIB counters can restart at agent re-initialisation and at times marked by ifCounterDiscontinuityTime. A poller must discard any delta where sysUpTime went backwards or ifCounterDiscontinuityTime changed between polls, instead of treating the drop as a wrap.

open as a page

An SNMP walk of a device's vendor subtree prints only numeric OIDs under 1.3.6.1.4.1.32473; how do you resolve them to named objects and decode their instances?

level: seniorimportance: should knowfreq 28%

basics

~20 s

Identify the organisation from the IANA enterprise number, use sysObjectID and sysDescr to pick the matching module revision, load it with every module it imports, then match each OID's longest registered prefix and decode the remainder as .0 or INDEX values.

open as a page

An SNMP agent sends a core link-down as an InformRequest while its collector restarts for 100 seconds; with the SNMP-TARGET-MIB default timeout and retry count, is it delivered?

level: seniorimportance: should knowfreq 14%

basics

~20 s

Not with a fixed wait: the defaults are a 15-second timeout (1500 hundredths) and 3 retries, so four sends at 0, 15, 30 and 45 s, abandoned at 60 s, 40 s before the collector returns.

open as a page

How does SNMPv3's USM turn one user's password into a different key on every agent, and what does that key localisation protect against?

level: seniorimportance: should knowfreq 20%

basics

~20 s

USM repeats the password to 1,048,576 octets and hashes it into a key, then hashes that key, the authoritative engine's snmpEngineID and the key again. Each agent stores only its localized result, so a stolen key opens no agent with a different engine ID.

open as a page

How do SNMPv3's snmpEngineBoots, snmpEngineTime and 150-second time window reject replayed messages, and which replays do they still let through?

level: seniorimportance: should knowfreq 15%

basics

~20 s

Each authenticated SNMPv3 message carries the authoritative engine's snmpEngineBoots and snmpEngineTime under the HMAC. A message with stale boots, or time more than 150 seconds off, is rejected - but a copy replayed inside that window is still accepted.

open as a page

A poller using SNMPv1 against a multilingual SNMP agent never receives the 64-bit interface counters, and its walks skip them; what explains this?

level: seniorimportance: should knowfreq 18%

basics

~20 s

Counter64 cannot be encoded in an SNMPv1 message, so RFC 3584 makes a multilingual agent treat Counter64 instances as out of view for v1 requests: a Get returns noSuchName and a GetNext skips them. Polling with SNMPv2c or, better, SNMPv3 fixes it.

open as a page

How would you design SNMP notification delivery for thousands of devices so that a collector outage cannot silently hide a core link-down?

level: principalimportance: should knowfreq 18%

basics

~20 s

Assume notifications will be lost and design to detect and repair: informs for critical events, two receivers in separate failure domains, receivers that deduplicate and store before acknowledging, and a reconciliation poll that catches what was missed.

open as a page

showing 1–30 of 35