We have discussed SNMP before and how it is not the right choice in most use cases. Despite the issues, lack of performance improvements of the protocol, and its growing list of alternatives, SNMP is leaving us not just yet. There are various reasons for this that go beyond the scope of this article. Suffice to say, SNMP is well-established and present on many networks to this day. Support from vendors is not dropping anytime soon either, forcing administrators to face configuring SNMP sooner or later (or rather, willingly or not).

Luckily, setting up SNMP on Linux is not a daunting task. Most of it consists of configuring SNMP, the daemon part, and learning a handful of commands, the tools part. Neither takes too long.

SNMP monitoring on Linux

The reference implementation for SNMP monitoring on Linux is the package net-snmp. Dating back to 1992, net-snmp is available for all major Linux distributions. It supports all the versions of the SNMP protocol, with version 3 being the recommended one. It is actively developed, with multiple commits every month for many years.

The package is usually composed of two separate components: the tools to utilize the protocol, and the daemon to install it on a Linux host and to configure and monitor it. On Ubuntu and other Debian-based distributions, the tools are called snmp and the daemon snmpd. On Red Hat, the tools are in the net-snmp-utils package and the daemon in net-snmp. In other distributions, both components may be in the same package, generally simply net-snmp.

The daemon allows the local host to be monitored by an external host through SNMP, while tools do the revers. Depending on your necessities for SNMP monitoring on Linux, it may be required to install both.

Alternatively to use a CLI tool, you can try Checkmk Trial to monitor your Linux Servers with deep insights, further than can be obtained through SNMP alone.

A word on SNMP versions

A short digression on the different versions of the protocol is necessary to configure SNMP on Linux. The original version of the SNMP protocol was v1, developed through the 1980s. It was later superseded by v2 that mainly offered an increased security and authentication mechanisms. v2 has two flavors, v2c and v2u. v2c offers a community-based security model, while v2u operates on a user-based model (as specified in RFC1910).

SNMP v2u never really took off, but part of its features were used to develop v3. v2c is much more common and what we actually refer to when using “v2” throughout this article.

v3 is the latest version of the SNMP protocol, whose main difference is the added encryption support, with its pros and cons.

What is snmpd?

snmpd on Linux is the daemon part of net-snmp. When installed, it creates an SNMP host that can accept requests from another host and respond to them, issue notifications (TRAPs and INFORMs in SNMP parlance), and perform some self-monitoring tasks. The SNMP protocol allows for basic configuration of hosts and snmpd is needed to exploit these capabilities.

What are the tools for SNMP monitoring on Linux?

With snmpd being the daemon, the bulk of operations through SNMP are done with a series of tools in the snmp (Ubuntu/Debian) or net-snmp-utils package (Red Hat). These are the core of the SNMP implementation and what an administrator would routinely use to monitor a network with.

Let’s have a look at how they work and what they are for.


snmptranslate performs a translation of OID into the corresponding MIB name:

 # snmptranslate .

Or the opposite, from a MIB to have the numeric OID:

 # snmptranslate **-On** SNMPv2-MIB::sysUpTime.0


snmpget retrieves data from an SNMP host. It makes a simple request that consists of three elements:

  1. where to retrieve information
  2. the administrative information associated with the request
  3. what information is required:

# snmpget -v 2c -c demopublic test.net-snmp.org SNMPv2-MIB::sysUpTime.0 SNMPv2-MIB::sysUpTime.0 = Timeticks: (586731977) 67 days, 21:48:39.77


The other main operation of the SNMP protocol for retrieving information is GETNEXT, implemented by the snmpgetnext tool. It retrieves similar types of information as snmpget, but from the next OID. It is useful to walk through a series of SNMP hosts and progressively get information from each device. Its syntax is identical to snmpget:

# snmpgetnext -v 2c -c demopublic test.net-snmp.org sysUpTime
SNMPv2-MIB::sysUpTime.0 = Timeticks: (586978184) 67 days, 22:29:41.84


As a helper to walk a network, instead of launching snmpgetnext for each SNMP host, snmpwalk can be used to do it automatically:

Snmpwalk command example


snmptable returns the content of an SNMP table, displaying it one row at a time:

snmptable command example


The SET operation of the SNMP protocol is used to modify information of an SNMP host, update its configuration, or control its behavior. It is implemented in the snmpset tool.

One of many possible examples is how to set a random string to be returned when queried:

$ snmpset -v 1 -c demopublic test.net-snmp.org ucdDemoPublicString.0 s "hi there!"

$ snmpget -v 1 -c demopublic test.net-snmp.org ucdDemoPublicString.0
UCD-DEMO-MIB::ucdDemoPublicString.0 = "hi there!"


The GETBULK operation available from SNMP v2 onward is implemented in the snmpbulkget tool. It is used to query a network of SNMP hosts rather than a single one.

$ snmpbulkget -v2c -Cn1 -Cr5 -Os -c public zeus system ifTable

It will retrieve the variable system.sysDescr.0 and the first 5 objects of the ifTable.

To retrieve multiple variables with a single command, snmpbulkwalk is a tool that allows you to run all the variables under a system:

$ snmpbulkwalk -v2c -Os -c public zeus system


TRAPs are generally sent by SNMP agents to signal abnormal conditions to a management station (in our case, a Linux server). To actually generate TRAPs yourself, the snmptrap tool is available. For v2/v3 the syntax is:

$ snmptrap -v 2c -c public host "" UCD-NOTIFICATION-TEST-MIB::demoNotif \
   SNMPv2-MIB::sysLocation.0 s "Just here"

Substitute 2c with v3 when communicating with an SNMP v3 agent.

How to configure SNMP on Linux

We have seen what is available in net-snmp to use SNMP for monitoring Linux servers. Now, we need to take a look at how to configure SNMP on Linux.

snmpd configuration usually resides in /etc/snmp/snmpd.conf for v1 and v2 of the SNMP protocol. If v3 is going to be used, as recommended, additional configuration is located at /var/lib/net-snmp/snmpd.conf. This file does not save changes while the daemon is running, so the daemon needs to be stopped before modifying the file.

Both files come heavily commented to facilitate configuring SNMP on Linux. snmpd.conf has a wealth of options and is not easy to configure, on Linux or elsewhere. However, for most necessities, just a few edits are required to get it working. Commands to simplify configuring SNMP on Linux exist to ease network and system administrators’ work.

Before you start to configure SNMP on Linux, open its port on the firewall. snmpd uses by default UDP port 161. With iptables, open it with:

$ iptables -A INPUT -s <ip addr> -p udp -m udp --dport 161 -j ACCEPT
$ iptables -A OUTPUT -p udp -m udp --sport 161 -j ACCEPT

For firewalls, the command is:

$ firewall-cmd --permanent --add-port=161/udp

This is for running snmpd on a host and allowing it to be queried. If you only want to monitor an external host, it is sufficient to ensure that the host is reachable.

Configure SNMP on Linux (v1 and v2)

The first two versions of the protocol provide simple authentication using a community string. It is a shared secret that is passed in clear text or hashed over the network, in a plainly unsafe way. This string has to be set up before communicating between SNMP hosts and devices.

The directive rocommunity or rwcommunity in the snmpd.conf file declare this string:

community [source [OID]]

While community is the used string, source is an IP address or subnet, and OID is an SNMP tree to provide access to. That’s basically all that is needed to communicate through SNMP between hosts.

It is recommended to add a location and contact info to the snmpd.conf file in order to inform other nodes on the network of where this SNMP host is located and who is responsible for it. Add a couple of lines after community:

syslocation Somewhere (In the World)
syscontact Admin <admin@somewhere.com>

Restart the snmpd daemon with systemctl restart snmpd and the Linux SNMP host is ready to answer SNMP requests.

Configure SNMP on Linux (v3)

Configuring snmpd on Linux with the latest version of the protocol is slightly more complex than with the previous ones. To start, the configuration files are now two: not just /etc/snmp/snmpd.conf, but also /var/lib/net-snmp/snmpd.conf. Luckily, the net-snmp package comes with a command helper, net-snmp-create-v3-user, to configure the user under which the SNMP Linux server will run.

Make sure to stop the daemon and create the SNMP user with:

$ net-snmp-create-v3-user
Enter a SNMPv3 user name to create:
Enter authentication pass-phrase:
Enter encryption pass-phrase:
  [press return to reuse the authentication pass-phrase]

  adding the following line to /var/lib/net-snmp/snmpd.conf:
     createUser admin MD5 "yourpassphraseofchoice" DES
  adding the following line to /etc/snmp/snmpd.conf:
     rwuser admin 

The final rwuser directive has a similar format to the community above:

  user [noauth|auth|priv] [OID]

user is a username and OID is the tree to provide access to. By default, in v3 the snmpd daemon allows only authenticated requests (auth), while the noauth allows any and the priv option enforces encryption. The strings can be combined. Our recommended option for maximum security is authpriv that specifies that requests must be authenticated and replies encrypted.

To improve the not-so-high default level of security of snmpd, a few options to the net-snmp-create-v3-user can be added:

  • -a SHA: uses the more modern SHA hashing algorithm instead of MD5.
  • -x AES: uses AES encryption instead of the deprecated DES.

Both options should be set as they switch the communication and authentication steps to more secure protocols. Unfortunately, neither is up to modern standards and SNMP is not a choice for a modern organization that wants to monitor hosts and devices in a secure, private, and efficient setting.

Configuring SNMP on Linux isn’t hard…but is it worth it?

SNMP configuration is indeed not the hardest one out there. Yet, it is still another piece of software to handle, in the case of snmpd, or to master, in the case of the various tools coming with net-snmp. And who monitors the monitor? Especially when it is installed on devices from a vendor. It is another risk of failure that can be avoided. Especially when supporting a probably soon-to-be-fully-outdated protocol.

With alternatives aplenty and major vendors moving on from SNMP, it seems unnecessary to go through the trouble of setting it up alongside modern monitoring tools. We definitely do not recommend using it when it can be avoided.

But often it is not a decision that can be made: whether because the infrastructure is already existing or because a few hosts can only support SNMP, sometimes we are forced to use SNMP. For a little while longer, it will definitely stay with us. And luckily, from a Linux host point of view, configuring it is definitely not complicated.

SNMP has plenty of learning materials to help the clueless administrator get started in configuring a SNMP Linux host. This article included.