# SNMP

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/snmp

## Quick definition

SNMP (Simple Network Management Protocol) is a standard way for network devices like routers, switches, and printers to share status information with a central management system. It allows network administrators to monitor performance, detect problems, and sometimes reconfigure devices from a single console. Think of it as a universal health-reporting system for network equipment.

## Simple meaning

Imagine you manage a large apartment building with hundreds of apartments. Each apartment has a small display board outside its door showing the apartment number, the current temperature, whether the lights are on, and if the water is running. This board makes it easy for you to walk down the hallway and quickly see the condition of each apartment without having to knock on every door. SNMP works much the same way for a computer network. 

 Each device on the network, such as a router, switch, server, or printer, has a small agent that constantly keeps track of information like its name, how busy its processor is, how much memory is free, the speed of its network connections, and whether any alarms have been triggered. The agent stores this information in a special organized database called a MIB (Management Information Base). 

 The central management system, often called the NMS (Network Management Station), periodically asks each device how it is doing. It does this by sending SNMP messages, such as a "Get" message to read the device's data or a "Trap" message that the device itself sends when something goes wrong, like a fan failing or a cable being disconnected. The NMS collects all this data from every device and displays it on a dashboard, giving the network administrator a bird's-eye view of the entire network's health. 

 In short, SNMP is like a universal language that lets network equipment talk to a central console about their status, helping administrators spot and fix problems before users even notice them.

## Technical definition

SNMP is an application-layer protocol defined by the Internet Engineering Task Force (IETF) in RFC 1157 and subsequent RFCs (such as RFC 3410–3418 for SNMPv3). It operates over UDP, most commonly using ports 161 (for queries and responses) and 162 (for trap notifications). The protocol is part of the TCP/IP suite and is used for collecting and organizing information about managed devices on IP networks, and for modifying that information to change device behavior. 

 The SNMP architecture consists of three key components: the managed device, the agent (software running on the managed device), and the Network Management Station (NMS). The NMS runs the management software that sends requests and receives responses. The agent maintains a local database of variables known as the Management Information Base (MIB). MIBs are structured hierarchically, similar to a file system, with each variable assigned a unique Object Identifier (OID). OIDs are written as a sequence of numbers (e.g., 1.3.6.1.2.1.1.5.0 for the device's system name). 

 There are three major versions of SNMP. SNMPv1 is the original, simple, and insecure version that uses community strings (passwords sent in cleartext) for authentication. SNMPv2c introduced improved error handling, the GetBulk operation (for retrieving large tables in one request), and informational requests, but still suffered from weak security. SNMPv3, the current standard, added strong security mechanisms, including message integrity, authentication (using SHA or MD5), and encryption (using DES or AES). 

 The protocol defines several key operations. The NMS can use GetRequest to read a single variable, GetNextRequest to walk through a MIB tree, and GetBulkRequest (v2c and v3) to retrieve large amounts of data efficiently. The SetRequest operation allows the NMS to modify variables on the device, enabling remote configuration. The agent can send unsolicited messages known as Traps (v1) or InformRequests (v2c and v3) to alert the NMS of abnormal conditions. The primary difference between a Trap and an Inform is that InformRequests require an acknowledgment from the NMS, providing guaranteed delivery. 

 In real IT implementation, SNMP is used by monitoring platforms such as Nagios, Zabbix, SolarWinds, and PRTG. These tools regularly poll devices for key metrics like CPU load, memory usage, interface bandwidth, and error counters. SNMP is also central to configuration management and fault detection in large enterprise networks. However, because SNMPv1 and v2c send community strings in cleartext, they should never be used over an untrusted network; SNMPv3 is strongly recommended for any production environment requiring security. 

 A common misconfiguration is leaving the default read-only community string as "public" and the read-write community string as "private." This exposes the network to potential reconfiguration and information leakage. Network professionals must always change these defaults and restrict SNMP access to specific NMS IP addresses using access control lists (ACLs).

## Real-life example

Think about the role of a school attendance office. At the start of every period, teachers send a list of absent students to the office. The attendance officer collects these lists, enters them into a computer, and can then see at a glance which students are missing, where they are, and whether a pattern is developing, like many students from one classroom being absent. The officer can also send a message back to a teacher to confirm the absence or ask for more information. 

 Now, imagine if all the students were network devices. The teachers are like the SNMP agents running on each device. The attendance office is the Network Management Station (NMS). The attendance officer does not call every teacher every minute; instead, the teachers send a report only when something changes, like a student being marked absent. In network terms, this is the SNMP Trap. 

 In this analogy, the teacher has a whiteboard that lists each student's name and whether they are present. This whiteboard is like the MIB (Management Information Base). The teacher's attendance log contains a distinct identifier for each student, just like each variable in the MIB has a unique OID. 

 The school principal (the network administrator) can ask the attendance office for a specific report, such as the total absences for the week. The attendance office sends a request to all teachers (GetRequest), the teachers respond with the count (GetResponse), and the office compiles the information. The principal can also use a SetRequest to update a student's attendance record, for example, changing an unexcused absence to excused. In the same way, an NMS can use SNMP SetRequest to change a device's configuration, such as disabling a port on a switch. 

 Just as the attendance system helps the school run smoothly and quickly identify issues, SNMP gives network administrators a real-time view of every device on the network, allowing them to respond to problems before they spread.

## Why it matters

In any modern IT environment, the network is the backbone connecting everything: file servers, email, cloud applications, printers, and critical business systems. If any device on the network fails or becomes slow, it can disrupt a whole department or even the entire organization. SNMP is the essential tool that gives administrators visibility into this complexity. Without SNMP, network monitoring would rely on manually logging into each device separately, a time-consuming and error-prone process that does not scale beyond a handful of devices. 

 SNMP matters because it enables proactive problem detection. Instead of waiting for a user to complain that the internet is slow, the NMS can show a gradual increase in errors on a specific switch port, alerting the administrator to replace a failing cable before it causes an outage. It also tracks historical performance, helping plan capacity upgrades. If the average CPU usage on a core router is 90% during peak hours, the administrator knows it is time to upgrade hardware, not after a crash. 

 For security, SNMP can be configured to send a Trap when an unauthorized device is connected to a switch port or when a firewall detects unusual traffic. Some management systems can even use SNMP Set commands to automatically disable a compromised port. This automated response reduces the window of vulnerability. 

 Finally, SNMP is deeply embedded in standard IT certification exams (CompTIA A+, Network+, and Cisco CCNA). Understanding SNMP is not just a theoretical concept; it is a practical, hands-on skill. Many job postings for network administrators require experience with SNMP-based monitoring tools. Mastery of SNMP directly translates to real-world job functions: configuring community strings, interpreting OIDs, troubleshooting traps that do not arrive, and securing SNMPv3. 

SNMP matters because it is the foundation of network visibility, proactive maintenance, and infrastructure scalability. It is a protocol that every IT professional must know to keep networks healthy and to pass industry-standard certification exams.

## Why it matters in exams

SNMP appears in multiple major certification exams, each with a slightly different focus. In CompTIA A+ (220-1101), SNMP is covered in the networking domain as a fundamental protocol used for network management and monitoring. Questions are usually conceptual, asking about the purpose of SNMP, the function of the MIB, or the difference between SNMPv2 and SNMPv3. A+ candidates should know that SNMP uses port 161 and that traps use port 162. Expect true/false questions, multiple-choice on protocol functions, and scenario-based questions where the learner must choose the correct method to monitor network devices. 

 In CompTIA Network+ (N10-008), SNMP is a heavier topic, appearing in the network operations domain. The exam expects a deeper understanding of SNMP versions, security implications, and practical usage. Candidates must know the differences between SNMPv1, v2c, and v3, the concept of community strings, and the importance of using SNMPv3 in modern networks. Performance-based questions might ask the learner to configure SNMP settings on a simulated device or to interpret an MIB tree to find the correct OID for a specific metric. Troubleshooting questions are common: for example, a scenario where monitoring software cannot communicate with a device, and the candidate has to identify that the community string is wrong or that a firewall is blocking UDP port 161. 

 For Cisco CCNA (200-301), SNMP is part of the network management, automation, and security topics. The CCNA curriculum emphasizes SNMPv3 security features, including authentication and encryption. The exam includes configuration questions where the candidate must enable SNMP on a Cisco IOS device, set up a read-only or read-write community, and restrict access to a specific NMS host. There are also questions about SNMP traps and the use of SNMP in conjunction with syslog and NetFlow for comprehensive network monitoring. CCNA candidates often face tricky questions that test the ability to differentiate between GET, SET, GET-NEXT, and TRAP operations. Another common CCNA exam trap is confusing SNMPv3 authentication methods: MD5 vs. SHA and DES vs. AES. 

 Across all three exams, authors focus on security. You can be nearly certain that a question will ask which SNMP version should be used in a production environment for security reasons (answer: SNMPv3). Another frequent topic is the port numbers: UDP 161 for polling and UDP 162 for traps. The phrase "community string" is high-yield; you must know that it acts as a password, that "public" is the default read-only community, and that "private" is the default read-write community, and that both should be changed immediately. 

 The type of questions ranges from simple recall to complex troubleshooting scenarios. For example, a Network+ question might ask: "A network administrator is setting up SNMP management for 200 switches. Which SNMP operation should be used to retrieve the entire interface table with a single request?" The answer is GetBulkRequest, available in SNMPv2c and SNMPv3. Another scenario: "A security audit recommends that all SNMP traffic be encrypted. Which version should be used?" SNMPv3. These patterns are predictable, and with the right preparation, SNMP questions become an easy point scorer.

## How it appears in exam questions

SNMP questions in certification exams typically fall into a few distinct patterns: conceptual knowledge, protocol operations, security configuration, and troubleshooting. 

 Conceptual questions are straightforward. You might see: "Which network protocol allows a network management station to collect information from network devices?" The answer is SNMP. Or: "Which port does SNMP use by default for sending traps?" The answer is UDP 162. These questions test recall and are the easiest to answer if you have memorized the essentials. 

 Protocol operation questions are more demanding. For instance: "An NMS needs to retrieve the sysName OID from a router. Which SNMP message type should the NMS send?" The answer is GetRequest. A more complex version: "A network admin needs to update the SNMP read-only community string on 50 switches. Which operation should be used?" The answer is SetRequest, but only if the admin has configured read-write access. These questions test knowledge of the specific function of each SNMP operation. 

 Security configuration questions are common. Example: "A company policy requires that all network management traffic be authenticated and encrypted. Which version of SNMP should be implemented?" The answer is SNMPv3. Another: "An engineer configures SNMP on a switch with the command 'snmp-server community MyPass RW'. What is the effect?" The answer is that it sets a read-write community string of 'MyPass', allowing an NMS to both read and configure the switch. The exam might then ask about the security risk of sending this string in cleartext. 

 Troubleshooting scenarios are the most challenging. A typical Network+ question: "A monitoring system reports that it cannot reach the SNMP agent on a router. The network engineer verifies that the router is up and reachable via ping. What is the most likely cause?" Options might include a firewall blocking UDP 161, an incorrect community string, or the SNMP agent not running. The correct answer is often that the community string configured on the NMS does not match the one on the router. 

 Another troubleshooting pattern involves traps. For example: "A syslog server receives critical logs from a switch, but the SNMP NMS never receives trap messages from the same switch. What could be the issue?" The answer might be that the trap destination IP address is misconfigured on the switch, or that UDP 162 is being blocked by a firewall. 

 Configurational drag-and-drop or multiple-select questions also appear. In CCNA, you might be asked to select the correct order of commands to configure SNMP on a router: first enable SNMP, then set the community string, then specify the trap destination, then optionally add ACL restrictions. These questions require not just knowledge of commands but also procedural logic. 

 In Network+ performance-based questions, you might be given a simulated command-line interface and asked to verify the SNMP status or change a community string. Being fluent in the 'show snmp' or 'snmp-server' syntax is useful. 

 Finally, watch out for questions that mix SNMP with other protocols. For example: "Which of the following uses UDP port 161?" Choices might include SNMP, syslog, DNS, and TFTP. SNMP uses 161. Another: "A network admin uses SNMP for monitoring and syslog for logging. What is the main advantage of syslog over SNMP traps?" The answer is that syslog provides more detailed log messages, while SNMP traps are structured and can be processed automatically. Understanding these nuances helps you eliminate wrong answers. 

SNMP questions test your ability to recall numbers, understand operations, apply security principles, and think through connectivity issues. The best preparation is to practice reading simple MIBs, configuring SNMP on a simulator, and understanding the security implications of each version.

## Example scenario

You are a junior network administrator at a medium-sized company with 30 switches and 5 routers spread across three floors. The company uses a central monitoring tool called MonitorMaster that sends you an email alert whenever the core switch goes down. Today, the CEO walks into your office and says the internet has been slow for the past hour. 

 You open MonitorMaster and see that the only alert is a yellow warning for Core_Switch_1: the CPU load is at 85%, which is above the 75% threshold you set. You click on the warning and MonitorMaster shows you a line graph of the CPU usage over the last 60 minutes. It went from 30% at 9 AM to 85% at 10 AM. 

 How does MonitorMaster get this data? It uses SNMP. The agent running on Core_Switch_1 maintains a MIB that includes an OID for CPU load. MonitorMaster (the NMS) sends a GetRequest to that OID every 5 minutes. The agent returns the current CPU percentage in a GetResponse. MonitorMaster stores each response, builds the graph, and compares it against your threshold. 

 To fix the issue, you decide to check what is using the CPU. You know that the switch's MIB also has an OID for the top processes, but you need to use SNMPv2c's GetBulkRequest to retrieve the entire table quickly. Your MonitorMaster software supports that. Within seconds, you see that a single workstation on port 12 is sending a massive number of broadcast packets, flooding the switch. 

 You use SNMP again-this time a SetRequest to disable port 12. The agent on the switch receives the SetRequest with the correct read-write community string, and it immediately shuts down the port. The CPU on Core_Switch_1 drops to 25%. The internet speed returns to normal. 

 Later, you want to make sure that you are notified if it happens again. You configure the switch to send an SNMP Trap to MonitorMaster whenever the CPU exceeds 75%. You also change the SNMP community strings from the default 'public' and 'private' to secure strings like 'AdminRO2024' and 'AdminRW2024', and you restrict SNMP access to only the IP address of MonitorMaster. 

 This scenario shows how SNMP is used in real operations: monitoring, data collection, remote control, and proactive alerting. The same skills and concepts are tested in A+, Network+, and CCNA exams.

## Common mistakes

- **Mistake:** Confusing SNMP port numbers, thinking SNMP uses TCP instead of UDP
  - Why it is wrong: SNMP uses UDP for speed and low overhead; TCP would add unnecessary connection establishment and acknowledgment delays for lightweight management traffic. Memorizing that SNMP uses UDP 161 and 162 is essential for exams and real troubleshooting.
  - Fix: Remember: SNMP polls use UDP 161, and SNMP traps use UDP 162. Think 'UDP for speed, ports 161 and 162'.
- **Mistake:** Leaving the default SNMP community string as 'public' or 'private' in a production network
  - Why it is wrong: Default community strings are well-known, easily guessed, and allow any device that can reach the managed device to read or even write its configuration. This is a major security vulnerability.
  - Fix: Always change the read-only community string from 'public' to a complex string, and the read-write community string from 'private' to a different complex string. Use SNMPv3 if possible.
- **Mistake:** Thinking SNMPv3 is less secure than SNMPv2c
  - Why it is wrong: SNMPv3 provides authentication, integrity, and encryption, while SNMPv1 and v2c send community strings in cleartext. SNMPv3 is the only recommended version for production networks requiring security.
  - Fix: Remember: v1 and v2c have no security (cleartext community strings); v3 has full security (authentication and encryption). Always choose v3 for secure environments.
- **Mistake:** Confusing the roles of the NMS (manager) and the agent
  - Why it is wrong: Some test-takers reverse them, thinking the managed device is the manager and the central system is the agent. This leads to incorrect answers on questions about who sends GetRequests versus who sends Traps.
  - Fix: The NMS (manager) sends GetRequests and SetRequests. The agent (on the device) sends Trap messages. Think: 'Manager asks, agent answers.'
- **Mistake:** Believing that SNMP Traps are always reliable and that no Trap means no problem
  - Why it is wrong: Traps are sent as unacknowledged UDP messages (in SNMPv1 and v2c). If the packet is lost, the NMS never knows. Informs (acknowledged) in v2c and v3 solve this, but many implementations still use Traps.
  - Fix: Use Informs (acknowledged) when guaranteed delivery is important, or implement a polling strategy to verify device status. Do not rely solely on traps.
- **Mistake:** Assuming all devices support the same set of MIB OIDs
  - Why it is wrong: Different vendors and models implement different subsets of standard and private MIBs. A standard OID might not exist on a particular device, causing an error response.
  - Fix: Before writing monitoring scripts, verify which MIBs the device supports. Use MIB browsers to browse the device's MIB tree, or consult the vendor documentation.

## Exam trap

{"trap":"The question says: 'A network administrator wants to collect configuration information from a router using the most secure method. Which version of SNMP should be implemented?' Some learners answer 'SNMPv2c' because they think it is newer than v1 and offers 'community strings' as a form of security.","why_learners_choose_it":"They see 'community strings' listed in v2c documentation and think that passwords are secure enough. They may confuse 'community string' with a proper password that offers encryption or authentication.","how_to_avoid_it":"Understand that community strings in SNMPv1 and v2c are sent in cleartext over the network. SNMPv2c does not add encryption or strong authentication; it only improves error handling and bulk data retrieval. The only version that provides authentication, integrity, and encryption is SNMPv3. Memorize this: v3 = security, v1 and v2c = no security."}

## Commonly confused with

- **SNMP vs Syslog:** Syslog is a protocol for sending log messages (text strings) from devices to a central server. SNMP, on the other hand, is a structured protocol for reading and writing metrics and configuration variables. Syslog messages are human-readable logs, while SNMP data is stored in MIBs with numeric OIDs. Both can be used for monitoring, but SNMP allows remote configuration (Set) and automated data collection, while syslog is primarily event logging. (Example: A switch reports a link-up event: syslog sends a text message 'Interface GigabitEthernet0/1 changed state to up', while SNMP sends a structured Trap with a specific OID indicating the interface status change.)
- **SNMP vs NetFlow:** NetFlow is a protocol for collecting metadata about network traffic flows (who talked to whom, how much data, and for how long). SNMP is used for device health and configuration (CPU, memory, interface errors, etc.). NetFlow answers questions about traffic patterns, while SNMP answers questions about the operational state of the device itself. They are complementary: SNMP tells you if the router is healthy, and NetFlow tells you what traffic is passing through it. (Example: An admin uses SNMP to see that a router's CPU is at 90%, then uses NetFlow to identify which application (e.g., video streaming) is consuming that CPU.)
- **SNMP vs ICMP (Ping):** ICMP is used for basic connectivity checks and error reporting, such as ping and traceroute. SNMP provides far more detailed device statistics and allows configuration changes. Ping tells you if a device is reachable, but it cannot tell you the interface error count, the CPU load, or the number of users logged in. SNMP can also be used to check reachability (by polling a simple OID), but its primary purpose is comprehensive management. (Example: Ping to a switch may succeed, indicating the switch is up, but SNMP polling of the interface errors OID may reveal that the switch is dropping packets due to a failing cable.)
- **SNMP vs RADIUS:** RADIUS is an authentication, authorization, and accounting (AAA) protocol for controlling access to network resources (like VPNs or Wi-Fi). SNMP is for device management, not user authentication. While both operate over UDP, RADIUS uses ports 1812 and 1813, not 161 or 162. They are part of completely different functions: one controls who gets on the network, the other monitors and manages the equipment already on the network. (Example: When a user connects to a corporate Wi-Fi, a RADIUS server checks their username and password, while SNMP monitors the access point's CPU load and signal strength.)

## Step-by-step breakdown

1. **SNMP Agent Initialization** — The SNMP agent software is started on the managed device (e.g., a router, switch, printer). It reads its configuration file, which contains details such as the community strings, the list of allowed NMS IP addresses, and which MIB objects it should support. The agent then opens UDP port 161 to listen for incoming SNMP requests. This step makes the device ready to be managed.
2. **NMS Sends a GetRequest** — The Network Management Station (NMS) constructs a packet containing a GetRequest Protocol Data Unit (PDU). Inside the PDU, the NMS specifies the OID of the variable it wants to read, for example, the system uptime (1.3.6.1.2.1.1.3.0). The NMS knows the IP address of the target device the device's SNMP community string (like a shared password). The packet is sent using UDP to port 161 on the target device.
3. **Agent Processes the Request** — The SNMP agent on the device receives the UDP packet from port 161. It first checks the community string in the packet against its configured read-only or read-write strings. If the community string matches and the IP address of the NMS is allowed (if ACLs are configured), the agent then looks up the requested OID in its local MIB. If the OID exists, the agent fetches the current value (e.g., the number of seconds since the last reboot).
4. **Agent Sends a GetResponse** — The agent constructs a GetResponse PDU containing the same OID and its associated value. This packet is sent back to the NMS using UDP. The source port is usually a random high port, and the destination port is the one the NMS used as its source in the original request. The NMS then interprets the response and stores the value for display or logging.
5. **NMS Uses SetRequest for Configuration** — If the administrator needs to change a setting on the device (such as disabling a port), the NMS sends a SetRequest PDU. This PDU includes the OID of the target variable and the new value. The SetRequest must use a read-write community string. The agent, upon receiving the SetRequest, checks the community string, verifies write access, and then applies the change to the device's running configuration. It then sends a SetResponse confirming the change.
6. **Device Sends an Unsolicited Trap** — When a significant event occurs on the managed device, such as a link going down, a fan failure, or a security violation, the agent can autonomously send a Trap message to the NMS. The Trap PDU contains the sender's IP address, the specific trap OID (which describes the event type), and any associated variables (e.g., the interface number). This message is sent to UDP port 162 on the NMS. The agent does not wait for a request; it is a push notification.
7. **NMS Receives and Processes the Trap** — The NMS listens on UDP port 162 for incoming traps. When it receives a Trap message, it parses the PDU, identifies the device and the event type, and triggers an alerting mechanism, such as sending an email to the admin or creating a ticket in the help desk system. In SNMPv2c and v3, the NMS may send an InformResponse (acknowledgment) back to the agent if the trap was sent as an InformRequest.

## Practical mini-lesson

To use SNMP effectively in a real environment, you must understand three things: how to configure agents, how to set up the NMS, and how to secure the whole system. On Cisco devices, enabling SNMP is done with global configuration commands. For example, 'snmp-server community MyROstring RO' sets a read-only community string named MyROstring. To allow only a specific NMS to query the device, add an access control list: 'access-list 10 permit host 192.168.1.100' followed by 'snmp-server community MyROstring RO 10'. This ensures that only the NMS at 192.168.1.100 can read SNMP data. For SNMPv3, you configure users with authentication and encryption: 'snmp-server group MyGroup v3 priv' and 'snmp-server user MyUser MyGroup v3 auth sha MyAuthKey priv aes 256 MyEncKey'. 

 On the NMS side, typical software like Zabbix or PRTG requires you to add each managed device by its IP address, provide the correct SNMP version and community string (or SNMPv3 credentials), and select the monitoring templates. The NMS then automatically discovers available MIB objects by performing a series of GetNextRequests, walking the MIB tree. This process is called an SNMP walk. The result is a list of all OIDs and their current values on the device. From this list, the administrator picks which metrics to monitor regularly. A common mistake is to poll too many OIDs too frequently, which can overload the managed device's CPU, especially on older routers. A sensible polling interval is 5 minutes for critical metrics and 15-30 minutes for less important ones. 

 What can go wrong? First, mismatched community strings. If the NMS sends 'Public' but the device expects 'MyROstring', the agent will drop the request and send an authentication failure trap (if configured). Second, firewall rules: a stateful firewall between the NMS and the device might not allow UDP 161 responses because it sees the response coming from a different source port than the request's destination. This is called a UDP asymmetric routing issue. Ensure that firewalls are configured to permit established SNMP traffic. Third, MIB compatibility: some devices implement private MIB extensions. If the NMS does not have those MIBs loaded, it cannot interpret the data. Always download and install the correct MIB files from the device vendor. 

 Finally, security is paramount. Never use SNMPv1 or v2c over the internet. Even within a corporate network, consider using SNMPv3 with AES encryption if any sensitive data (like passwords or network topology) is exposed in the MIB. Many organizations create a dedicated management VLAN and restrict SNMP traffic to that VLAN only. This isolates management traffic from user traffic and adds an extra layer of security.

## Memory tip

To remember SNMP ports: 161 is the left pillar of the castle where you ask for info, 162 is the trap door where alerts fall out. And v3 is the armored version.

## FAQ

**Can SNMP run over TCP instead of UDP?**

Technically, yes, but the standard defines SNMP over UDP. Some implementations can use TCP to handle very large messages that exceed UDP's 64KB limit, but this is rare. For exams, remember the standard port numbers: UDP 161 and UDP 162.

**What is the difference between a Trap and an Inform?**

A Trap is an unacknowledged message sent from an agent to an NMS when an event occurs. An Inform is the same kind of notification, but the NMS sends back an acknowledgment. Inform guarantees delivery, but uses more network resources. SNMPv1 only supports Traps; SNMPv2c and v3 support both.

**Is SNMP still relevant with modern cloud monitoring?**

Yes, absolutely. Even cloud-managed devices (like Meraki or cloud-based firewalls) often expose SNMP for deeper monitoring. Cloud monitoring tools also use SNMP to pull data from on-premises devices. SNMP remains the standard for network device monitoring.

**What is the default polling interval for SNMP?**

There is no mandatory default; it depends on the NMS software. Common intervals are every 5 minutes for critical metrics and every 15-30 minutes for less critical ones. Polling too often can overload devices with slow CPUs.

**What does 'SNMP community string' mean?**

It is a simple password (in v1 and v2c) that matches the device's configuration. It is sent in cleartext. 'Public' is the default read-only community, and 'Private' is the default read-write community. Always change these to strong, unique strings.

**What is a MIB?**

MIB stands for Management Information Base. It is a hierarchical database of variables that an SNMP agent maintains. Each variable has a unique OID (like 1.3.6.1.2.1.1.5.0 for system name). The NMS uses the MIB to know what data is available on a device.

**Why would I use SNMPv2c instead of v3?**

Some legacy devices only support SNMPv2c. v2c also adds GetBulkRequest, which is useful for retrieving large tables efficiently. However, if security is a concern, use v3. Only use v2c in a trusted, isolated network segment.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/snmp