This chapter covers Simple Network Management Protocol (SNMP), focusing on Management Information Bases (MIBs), Object Identifiers (OIDs), and traps—the core mechanisms that enable network monitoring and alerting. Understanding these components is critical for the N10-009 exam, as approximately 10-15% of questions in the Network Operations domain test SNMP concepts, including trap types, OID hierarchy, and MIB structure. You will learn how SNMP agents and managers communicate, how OIDs uniquely identify managed objects, how MIBs provide a structured database of these objects, and how traps enable event-driven notifications for proactive network management.
Jump to a section
Think of a hospital patient monitoring system where each patient (network device) has sensors (MIB) that measure vital signs like heart rate, blood pressure, and oxygen saturation. Each measurement is identified by a unique code, like a medical record number (OID). The central nurse's station (NMS) periodically checks each patient's vitals by requesting specific OIDs (polling). If a patient's heart rate spikes dangerously, the bedside monitor can immediately alert the nurse via an alarm (trap) without waiting for the next check. The nurse can also manually query a specific sensor (get) or adjust a medication drip rate (set). The hospital's monitoring system uses a standard protocol (SNMP) to communicate with monitors from different manufacturers, and each monitor has a standardized set of sensor codes (MIB) so the nurse station knows what each code means. Without this system, nurses would have to walk to each patient room and read vitals manually, which is inefficient and misses emergencies. Similarly, SNMP with MIBs and traps allows network administrators to monitor thousands of devices efficiently and respond to critical events in real time.
What is SNMP and Why It Exists
SNMP (Simple Network Management Protocol) is an application-layer protocol defined in RFC 1157 (SNMPv1), RFC 1901-1908 (SNMPv2c), and RFC 3411-3418 (SNMPv3). It enables network administrators to monitor and manage network devices such as routers, switches, servers, printers, and UPS units from a central management station (NMS). Without SNMP, administrators would need to physically access each device or use device-specific protocols, which is impractical at scale. SNMP provides a standardized way to collect performance data, detect faults, and remotely configure devices.
How SNMP Works: The Manager-Agent Model
SNMP uses a client-server model where the NMS (Network Management Station) acts as the manager, and managed devices run SNMP agents. The manager sends requests to agents, and agents respond with data. There are three core operations: - GET: Manager requests the value of a specific OID from an agent. - GETNEXT: Manager retrieves the next OID in the MIB tree (used for walking the tree). - SET: Manager modifies the value of a writable OID on the agent. - TRAP: Agent sends an unsolicited notification to the manager when a predefined event occurs. - INFORM: Like a trap, but the manager acknowledges receipt (used in SNMPv2c and v3).
MIBs: The Management Information Base
A MIB (Management Information Base) is a virtual database that defines the managed objects on a device. Each MIB is a text file written in ASN.1 (Abstract Syntax Notation One) that describes the structure of the data. The MIB organizes objects in a hierarchical tree, similar to a file system. Each object has a unique OID (Object Identifier) that represents its location in the tree.
Standard MIBs are defined by IETF RFCs (e.g., RFC 1213 for MIB-II) and vendor-specific MIBs are provided by device manufacturers. Common MIBs include: - MIB-II (RFC 1213): Contains basic TCP/IP stack objects (interfaces, IP, ICMP, TCP, UDP, SNMP). - IF-MIB (RFC 2863): Interface statistics (bandwidth, errors, status). - RMON MIB (RFC 2819): Remote monitoring statistics. - CISCO-SYSLOG-MIB: Syslog trap generation. - HOST-RESOURCES-MIB (RFC 2790): System resources (CPU, disk, memory).
OIDs: Object Identifiers
An OID is a sequence of integers separated by dots that uniquely identifies a managed object in the MIB tree. The OID tree is administered by IANA, with the root being: - 0: ITU-T - 1: ISO - 1.3: ISO-identified organization - 1.3.6.1: Internet (IETF) - 1.3.6.1.2.1: MIB-II (mgmt) - 1.3.6.1.4.1: Private enterprises (vendors)
For example, the OID for system description is 1.3.6.1.2.1.1.1.0 (iso.org.dod.internet.mgmt.mib-2.system.sysDescr.0). The trailing .0 indicates a scalar object instance. Tabular objects use a different instance identifier (e.g., ifIndex.1 for the first interface).
Traps: Event-Driven Notifications
Traps are unsolicited messages sent from an SNMP agent to the NMS when a specific event occurs, such as a link going down, high CPU utilization, or authentication failure. Traps enable proactive monitoring without polling. Standard trap types defined in SNMPv1 (RFC 1157): - coldStart (0): Agent is reinitializing; configuration may change. - warmStart (1): Agent is reinitializing; configuration unchanged. - linkDown (2): A network interface has gone down. - linkUp (3): A network interface has come up. - authenticationFailure (4): An SNMP request was received with an invalid community string. - egpNeighborLoss (5): An EGP neighbor has gone down. - enterpriseSpecific (6): Vendor-specific trap defined in the enterprise MIB.
In SNMPv2c, traps are replaced by SNMPv2-Trap PDUs, which have a different format and include additional fields like sysUpTime and snmpTrapOID. The NMS must have the corresponding MIB file to interpret enterprise-specific traps.
SNMP Versions and Security
SNMPv1: Uses community strings (plaintext) for authentication. Read-only (public) and read-write (private) communities. No encryption. Not recommended for production.
SNMPv2c: Enhanced protocol but still uses community strings. Introduced INFORM for acknowledged notifications.
SNMPv3: Provides authentication (MD5, SHA) and encryption (DES, AES) via User-Based Security Model (USM). Also supports message integrity and access control via View-Based Access Control Model (VACM). SNMPv3 is the recommended version for secure environments.
Configuration and Verification Commands
On Cisco IOS, SNMP configuration involves:
! Enable SNMP agent
snmp-server community public RO
snmp-server community private RW
! Define trap destination
snmp-server host 192.168.1.100 version 2c public
! Enable traps for specific events
snmp-server enable traps snmp linkdown linkup
snmp-server enable traps config
! Set SNMP location and contact
snmp-server location "Data Center A"
snmp-server contact "admin@example.com"Verification commands:
show snmp
show snmp community
show snmp host
show snmp mib
show snmp statisticsTo test traps, use tools like snmptrap on Linux or Wireshark to capture SNMP traffic.
MIB Compilation and OID Resolution
NMS software (e.g., SolarWinds, PRTG, Zabbix) includes a MIB compiler that loads MIB files and maps OIDs to human-readable names. Without the correct MIB, the NMS displays raw OIDs (e.g., .1.3.6.1.4.1.9.9.41.1.2.3.1.1) instead of meaningful descriptions. Administrators must download and compile vendor MIBs for proper monitoring.
SNMP Interaction with Other Technologies
SNMP data is often used by: - Syslog: For logging events; SNMP traps provide real-time alerts while syslog stores historical logs. - NetFlow/sFlow: For traffic analysis; SNMP polls interface counters for utilization. - RMON: Uses SNMP to collect and store statistics remotely. - IP SLA: Can trigger SNMP traps when performance thresholds are exceeded.
Common Pitfalls and Exam Traps
Wrong community string: The most common cause of SNMP failures. Verify read/write access.
ACL blocking: SNMP uses UDP ports 161 (polling) and 162 (traps). Ensure firewall rules allow these.
MIB not loaded: NMS cannot decode enterprise traps without the correct MIB.
Trap destination misconfiguration: The NMS IP and community must match on both agent and manager.
Version mismatch: SNMPv2c traps are not compatible with SNMPv1 managers.
Polling interval too high: May miss transient events; too low causes unnecessary load.
Exam-Relevant Numbers and Defaults
Default SNMP ports: UDP 161 (queries), UDP 162 (traps).
Default community strings: "public" (read-only), "private" (read-write).
SNMPv3 default authentication: MD5 (but SHA recommended).
Standard trap port: 162.
MIB-II OID: 1.3.6.1.2.1.
Private enterprise OID: 1.3.6.1.4.1.
sysDescr OID: 1.3.6.1.2.1.1.1.0.
ifEntry OID: 1.3.6.1.2.1.2.2.1.
Cold start trap OID: 1.3.6.1.6.3.1.1.5.1.
Link down trap OID: 1.3.6.1.6.3.1.1.5.3.
Link up trap OID: 1.3.6.1.6.3.1.1.5.4.
Understanding these fundamentals ensures you can configure, troubleshoot, and explain SNMP on the N10-009 exam.
SNMP Agent Initialization
When a network device boots up, its SNMP agent initializes and loads the MIB objects from the device's running configuration. The agent registers itself with the operating system to listen on UDP port 161 for incoming GET, GETNEXT, and SET requests. It also prepares to send traps to the configured NMS on UDP port 162. The agent checks the SNMP community strings (v1/v2c) or user credentials (v3) that have been configured. At this point, the agent is ready to respond to queries and generate traps based on events like interface status changes or authentication failures. The NMS may also receive a coldStart or warmStart trap to indicate the agent has restarted.
NMS Sends a GET Request
The NMS constructs an SNMP GET request packet containing the target OID (e.g., 1.3.6.1.2.1.1.1.0 for sysDescr), the SNMP version, and the community string (e.g., 'public'). The packet is sent via UDP to the agent's IP address on port 161. The agent receives the packet and first checks the community string. If it matches a configured read-only or read-write community, the agent proceeds. Otherwise, it increments the snmpInBadCommunityNames counter and may send an authenticationFailure trap. The agent then looks up the OID in its MIB tree. If found, it retrieves the current value (e.g., 'Cisco IOS Software, C3560 Software...') and constructs a GET-RESPONSE packet containing the OID and value. If the OID is not supported, the agent returns a 'noSuchName' error. The response is sent back to the NMS on an ephemeral UDP port.
NMS Performs a SNMP Walk
A SNMP walk uses repeated GETNEXT requests to traverse a MIB subtree. Starting from a root OID (e.g., 1.3.6.1.2.1.2.2.1.1 for ifIndex), the NMS sends a GETNEXT request. The agent responds with the next OID in lexicographic order and its value. The NMS then sends a GETNEXT for that returned OID, and so on, until the agent returns an error (endOfMibView) or the NMS detects the OID has left the desired subtree. This process retrieves all objects in a table, such as all interface statistics. The NMS may use multiple parallel requests to speed up the walk. The walk is commonly used to discover device capabilities or to collect bulk data for inventory. However, walking large MIBs (e.g., full MIB-II) can generate significant network traffic and CPU load on the agent.
Agent Sends a Trap
When a monitored event occurs, such as a link going down, the SNMP agent constructs a trap PDU. The trap includes the agent's sysUpTime (time since last reinitialization), the trap OID (e.g., 1.3.6.1.6.3.1.1.5.3 for linkDown), and variable bindings containing specific data (e.g., ifIndex of the down interface). The trap is sent as a UDP packet to the configured NMS IP address on port 162. The agent does not wait for an acknowledgment (unlike INFORM). If the NMS is unreachable, the trap is lost. The agent may queue a limited number of traps (typically 10-20) if the destination is temporarily unreachable, but once the queue is full, new traps are dropped. The NMS receives the trap, checks the community string, and then processes the OID and variable bindings. The NMS must have the corresponding MIB loaded to decode enterprise-specific traps.
NMS Processes and Alerts
Upon receiving a trap, the NMS validates the source IP and community string. It then looks up the trap OID in its MIB database to determine the event type. For standard traps (coldStart, linkDown, etc.), the NMS can immediately generate an alert. For enterprise-specific traps, the NMS uses the variable bindings to extract details (e.g., interface name, error message). The NMS logs the event, updates the device's status in its monitoring dashboard, and triggers notifications (email, SMS, ticket) based on severity. The NMS may also correlate multiple traps from the same device to suppress duplicate alerts. For example, a linkDown trap followed by a linkUp trap within 5 seconds might be ignored as a flapping interface. The NMS typically stores trap history for auditing and troubleshooting.
Enterprise Scenario 1: Data Center Monitoring
A large enterprise monitors 500+ switches and routers across multiple data centers using SNMPv3. Each device is configured with a unique user and SHA/AES encryption. The NMS (SolarWinds) polls interface statistics every 5 minutes using GET requests for ifInOctets and ifOutOctets to calculate bandwidth utilization. Traps are enabled for linkDown, linkUp, and high CPU (enterprise-specific trap at OID 1.3.6.1.4.1.9.9.48.1.1.1.6). When a core switch interface goes down, the trap arrives at the NMS within milliseconds, triggering an alert to the on-call engineer. The NMS also uses SNMP SET to disable a faulty port remotely. At scale, polling 500 devices every 5 minutes generates ~500 GET requests per minute, which is manageable. However, during a major outage (e.g., power failure), hundreds of traps flood the NMS simultaneously. The NMS must be sized to handle burst rates of 10,000+ traps per second, with proper deduplication and throttling to prevent alert fatigue.
Enterprise Scenario 2: Managed Service Provider (MSP)
An MSP monitors thousands of customer devices across different organizations. Each customer has a separate SNMP community string or SNMPv3 user. The NMS uses SNMPv2c for legacy devices and SNMPv3 for newer ones. The MSP configures traps to be sent to a central trap receiver (e.g., Kiwi Syslog Server) that forwards them to the NMS. A common issue is that customers accidentally leave the default 'public' community, exposing devices to unauthorized queries. The MSP locks down SNMP access using ACLs on the customer edge routers. Another challenge is MIB management: each vendor (Cisco, Juniper, HP) has proprietary MIBs. The MSP maintains a central MIB repository that is compiled on the NMS. Without the correct MIB, traps from a new device model appear as unformatted OIDs, making troubleshooting difficult. To avoid this, the MSP automatically downloads and compiles vendor MIBs when onboarding a new device.
Enterprise Scenario 3: Network Performance Baseline
A university network team uses SNMP to collect historical data for capacity planning. They poll 200 access switches every 10 minutes for interface errors (ifInErrors, ifOutErrors) and broadcast traffic. The data is stored in a time-series database (e.g., RRDtool). After three months, they analyze trends to identify under-provisioned uplinks. They also set thresholds: if interface errors exceed 1% of total packets for 15 minutes, the NMS sends a trap to the network engineer. A misconfiguration occurs when the SNMP community string is changed during a security audit but the NMS is not updated. Polling fails silently, and the team notices missing data after a week. They use snmpwalk to test connectivity and discover the mismatch. The fix involves updating the community string on the NMS or reverting the device change. This scenario highlights the importance of monitoring the monitoring system itself.
What the N10-009 Tests on SNMP, MIBs, OIDs, and Traps
The N10-009 exam objectives under Domain 3.0 (Network Operations) include: '3.3 Explain the purpose of organizational processes and procedures for network monitoring and management.' This specifically covers SNMP versions, MIBs, OIDs, and traps. Expect 2-4 questions on this subtopic. The exam focuses on: - SNMP versions: Differences between v1, v2c, v3. Security features of v3 (authentication, encryption). - Community strings: Defaults (public/private), read-only vs. read-write. - OID structure: The hierarchical tree, especially .1.3.6.1.2.1 (MIB-II) and .1.3.6.1.4.1 (private enterprises). - Trap types: coldStart, warmStart, linkDown, linkUp, authenticationFailure, enterpriseSpecific. - Port numbers: UDP 161 for queries, UDP 162 for traps. - MIB: What it is and why it is needed to interpret OIDs.
Common Wrong Answers and Why Candidates Choose Them
'SNMP uses TCP for reliable delivery': Wrong. SNMP uses UDP because it is lightweight and fast. Traps are unacknowledged, so reliability is not guaranteed. Candidates confuse SNMP with syslog (which also uses UDP) or assume TCP because of 'management'. Correct answer: UDP ports 161 and 162.
'Community strings are encrypted in SNMPv2c': Wrong. SNMPv2c still uses plaintext community strings. Only SNMPv3 provides encryption. Candidates see 'v2c' and think 'c' means 'crypto' or 'confidential'. The 'c' stands for 'community-based'.
'Traps are sent to UDP port 161': Wrong. Traps use port 162. Candidates get confused because GET requests use 161. Memorize: Manager listens on 162 for traps; agent listens on 161 for queries.
'MIB is a protocol': Wrong. MIB is a database definition, not a protocol. SNMP is the protocol. Candidates blur the line between the management protocol and the information model.
Specific Numbers and Terms That Appear Verbatim
UDP ports: 161 (SNMP agent), 162 (SNMP trap receiver).
Default communities: 'public' (RO), 'private' (RW).
SNMPv3 security: MD5 or SHA for authentication; DES or AES for encryption.
Trap OIDs: coldStart = .1.3.6.1.6.3.1.1.5.1; linkDown = .1.3.6.1.6.3.1.1.5.3; linkUp = .1.3.6.1.6.3.1.1.5.4.
MIB-II OID prefix: .1.3.6.1.2.1.
Enterprise OID prefix: .1.3.6.1.4.1.
Edge Cases and Exceptions
Inform vs. Trap: SNMPv2c introduced INFORM, which is acknowledged. The exam may ask which provides guaranteed delivery. Answer: INFORM, because the manager sends a response.
SNMPv3 USM: The User-Based Security Model requires a username, authentication passphrase, and privacy passphrase. The exam may test that authentication and privacy are optional but recommended.
MIB compilation: If the NMS does not have the correct MIB, it cannot decode enterprise-specific traps. The exam may present a scenario where traps arrive but are not understood.
ACL blocking: Even with correct SNMP config, if an ACL blocks UDP 161/162, polling/traps fail. This is a common troubleshooting scenario.
How to Eliminate Wrong Answers
If a question mentions 'encrypted SNMP', the answer must be SNMPv3. v1 and v2c do not encrypt.
If a question asks about 'reliable trap delivery', the answer is INFORM (not trap).
If a question asks which port a trap is sent to, it's 162. If it asks for query port, it's 161.
If a question asks about 'MIB', remember it's a database, not a protocol or a device.
For OID questions, remember that private enterprise OIDs start with .1.3.6.1.4.1.
SNMP uses UDP port 161 for queries and port 162 for traps.
Default community strings are 'public' (read-only) and 'private' (read-write).
MIB is a database that defines OIDs; OIDs are hierarchical numeric identifiers.
SNMPv3 is the only version that provides encryption and authentication.
Traps are unacknowledged; INFORM (SNMPv2c/v3) provides acknowledgment.
Enterprise-specific traps require the vendor's MIB to interpret.
The OID prefix for private enterprises is 1.3.6.1.4.1.
These come up on the exam all the time. Here's how to tell them apart.
SNMPv2c
Uses community strings (plaintext) for authentication
No encryption
Supports INFORM (acknowledged traps)
Easier to configure
Less secure; suitable for lab or isolated networks
SNMPv3
Uses USM (User-Based Security Model) with username and passwords
Provides encryption (DES, AES) and authentication (MD5, SHA)
Supports INFORM and traps
More complex to configure
Required for production environments with security requirements
Mistake
SNMP uses TCP for reliable communication.
Correct
SNMP uses UDP (ports 161 and 162). It sacrifices reliability for low overhead. SNMPv2c INFORM provides acknowledgment but still uses UDP.
Mistake
SNMPv2c provides encryption.
Correct
SNMPv2c uses community strings in plaintext. Only SNMPv3 offers encryption (DES, AES) and authentication (MD5, SHA).
Mistake
Traps are sent to the same port as SNMP queries.
Correct
Queries (GET, SET) use UDP port 161 on the agent. Traps are sent to UDP port 162 on the NMS.
Mistake
MIB is the same as SNMP.
Correct
MIB (Management Information Base) is a structured database that defines managed objects. SNMP is the protocol used to access those objects.
Mistake
All SNMP traps are standard and require no MIB.
Correct
Only generic traps (coldStart, linkDown, etc.) are standard. Enterprise-specific traps (OID 1.3.6.1.4.1.*) require the vendor's MIB to decode.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A trap is an unacknowledged notification sent from an agent to the NMS. The NMS does not send a response, so the agent does not know if the trap was received. An inform (available in SNMPv2c and v3) is an acknowledged notification: the NMS sends a response back to the agent, confirming receipt. If the agent does not receive the acknowledgment, it may retransmit the inform. Therefore, informs provide reliable delivery but generate more network traffic. On the exam, remember that traps are fire-and-forget, while informs are confirmed.
SNMPv3 is the only version that provides security features: authentication (MD5 or SHA) to verify the sender's identity, encryption (DES or AES) to protect data in transit, and message integrity to ensure data hasn't been tampered with. SNMPv1 and v2c send community strings and data in plaintext, making them vulnerable to eavesdropping. For the N10-009 exam, always choose SNMPv3 when a question requires security.
SNMP agents listen on UDP port 161 for incoming GET, GETNEXT, and SET requests. SNMP managers (NMS) listen on UDP port 162 for incoming traps and informs. When the NMS sends a query, it uses a random ephemeral source port and sends to the agent's port 161. When an agent sends a trap, it uses a random source port and sends to the manager's port 162. Memorize: 161 = queries, 162 = traps.
A Management Information Base (MIB) is a text file written in ASN.1 that defines the structure of managed objects on a device. It maps human-readable names (e.g., sysDescr) to numeric OIDs (e.g., 1.3.6.1.2.1.1.1). Without the correct MIB, an NMS cannot interpret SNMP data—it will display raw OIDs instead of meaningful descriptions. For the exam, remember that MIBs are loaded into the NMS, not the agent, to decode responses and traps.
SNMPv1 defines six generic traps: coldStart (0), warmStart (1), linkDown (2), linkUp (3), authenticationFailure (4), and egpNeighborLoss (5). The seventh type is enterpriseSpecific (6), which is used for vendor-defined events. In SNMPv2c, traps are identified by OIDs (e.g., coldStart = 1.3.6.1.6.3.1.1.5.1). For the exam, know the names and OIDs of the most common traps: coldStart, warmStart, linkDown, linkUp, and authenticationFailure.
First, verify connectivity: use `ping` to ensure the device is reachable. Then test SNMP using `snmpget` or `snmptest` from the NMS. Common issues: wrong community string (check case and spelling), ACL blocking UDP 161/162, wrong SNMP version (v1 vs v2c vs v3), or the agent is not enabled. On Cisco devices, use `show snmp` to verify configuration and `show snmp statistics` to see error counters. Also check that the NMS IP is listed in the `snmp-server host` command.
The OID for sysDescr (system description) is 1.3.6.1.2.1.1.1.0. This is a scalar object, so the instance is .0. It is part of the system group in MIB-II. On the exam, you may be asked to identify OIDs for common objects like sysName (1.3.6.1.2.1.1.5.0), sysLocation (1.3.6.1.2.1.1.6.0), or sysContact (1.3.6.1.2.1.1.4.0).
You've just covered SNMP MIBs, OIDs, and Traps — now see how well it sticks with free N10-009 practice questions. Full explanations included, no account needed.
Done with this chapter?