SNMP stands for Simple Network Management Protocol, an application widely used to monitor and manage various entities in the network such as PCs, servers, printers, routers, switches along with UPS, rack PDUs, and more.
SNMP is a simple request-response protocol with two functional entities.
- Manager : This is a piece of software running on a system in the network that queries the managed node for specific management data. It’s popularly known as NMS (Network Management System). Manager centralizes all the collected data and provides ways to visualize the overall health of the network. It enables the network admin with enough information to analyze and troubleshoot problems in the network.
- Agent : Agent is also a piece of software that runs on all the managed entities which collects various data of the machine such as CPU load, memory utilization, disk space, throughput on interfaces etc. Agent runs as a daemon collecting the data that responds to the Manager’s query with the collected data. Agent also notifies the manager asynchronously about specific pre-configured events such as system down state, excessive bandwidth utilization etc. via SNMP Traps.
SNMP and UDP
SNMP uses UDP (User Datagram Protocol) as its transport protocol. UDP was chosen over the Transmission Control Protocol (TCP) because it is connectionless, meaning no end-to-end connection is made between the agent and the NMS when datagrams (packets) are sent back and forth. This aspect of UDP makes it unreliable since there is no acknowledgment of lost datagrams at the protocol level. It’s up to the SNMP application to determine if datagrams are lost and retransmit them if it so desires. This is typically accomplished with a simple timeout. The NMS sends a UDP request to an agent and waits for a response. The length of time the NMS waits depends on how it’s configured. If the timeout is reached and the NMS has not heard back from the agent, it assumes the packet was lost and retransmits the request. The number of times the NMS retransmits packets is also configurable.
The upside to the unreliable nature of UDP is that it requires low overhead, so the impact on the network’s performance is reduced. In a heavily congested and managed network, SNMP over TCP is a bad idea. It’s also worth realizing that TCP isn’t magic and that SNMP is designed for working with networks that are in trouble—if your network never failed, you wouldn’t need to monitor it. When a network is failing, a protocol that tries to get the data through but gives up if it can’t is almost certainly a better design choice than a protocol that floods the network with retransmissions in its attempt to achieve reliability.
Two UDP ports are used by the SNMP depending on the type of conversation.
- SNMP Query : Both the NMS and the Agent communicate on UDP port 161 for all requests and responses.
- SNMP Trap : The NMS listen for traps from the agent on UDP port 162. The agent chooses a random number (above 1023) as the source port.
Note: At least as far as regular information requests are concerned, the unreliable nature of UDP isn’t a real problem. At worst, the management station issues a request and never
receives a response. For traps, the situation is somewhat different. If an agent sends a
trap and the trap never arrives, the NMS has no way of knowing that it was ever sent.
The agent doesn’t even know that it needs to resend the trap because the NMS is not
required to send a response back to the agent acknowledging receipt of the trap.
SNMPv1 and SNMPv2 use the notion of communities to establish trust between managers and agents. An agent is configured with three community names.
- Read-Only (RO) : As the name suggests this community string lets only to read(get) the data and denies any modification.
- Read-Write (RW) : This community string allows both to read(get) and modify(set) the data on the agent.
- Trap : This enables asynchronous notifications to be sent from an agent and received by the NMS. In Windows it is identified as NOTIFY string.
Most vendors ship their equipment with default community strings, typically public as for the RO community string and private for the RW community string. It’s important to change these defaults before the device goes live on the network.
Because community strings are essentially passwords, the same rules should be used in selecting them as that for Linux or Windows user passwords: no dictionary word, pet name etc. An alphanumeric string with mixed upper- and lowercase letters is generally a good idea.