How to Configure SNMPv3 and How It Works

Quick Definition: Simple Network Management Protocol (SNMP) is an internet protocol that network devices can use to communicate with one another and share information. 

SNMP is one of the best resources available for collecting and organizing information about devices across an entire network and then modifying device behavior according to the results of that data.

That's because SNMP is particularly good for devices—usually sensors, servers, and network architecture devices—to share information about themselves with other devices on the same network running different software on different hardware. This post will explore what SNMP is, how it works, how to configure it, and new features in SNMPv3. 

An Overview of SNMP [VIDEO]

In this video, Jeremy Cioara covers configuring SNMPv3 on Cisco routers. You get a quick history of SNMP followed by a crash course in version 3’s additions: Views, Groups, and Users. Jeremy creates a new View, Group, and User, then configures them and connects a device.

The current version of SNMP is version 3, but versions 1 and 2 preceded it. Understanding SNMP v3 requires revisiting versions 1 and 2.

What, you might ask, was SNMP v1's main achievement? Existing at all. SNMP v1 was the first open standard for network management to be adopted. People at the time thought it was great — and it really is simple to monitor devices with it.

For the most part, SNMP v2 was little more than a feature pack upgrade to version 1. With SNMP version 2, SNMP was made more efficient, better at management, and had more monitoring capabilities. Its downside was that it lacked any kind of authentication or encryption mechanism.

The one thing it did have in that regard was community value. A community value is essentially a pre-shared key on the device that you're managing. That community value gave whoever had access permission to read all the sensors there. You could even read/write all of the sensors on there without any encryption or authentication mechanism.

For those of you who are security-minded, you'll know that's not a great arrangement. It's not ideal to only have two options, particularly those: not giving a user any access at all, or giving them full read/write access. And that's where SNMP version 3 improved on its predecessors.

Version 3 took a long time to get adopted. It represents a significant departure from the previous versions and you do have to implement it on all kinds of devices. But the capability to do authentication and encryption was pivotal — and that's what we'll be talking about later in this post.

What is the Object Identifier and Management Information Base (OID/MIB)?

Object Identifiers and Management Information Bases (OID/MIB) are pivotal to understanding SNMP. An Object Identifier (OID) is the identifier that SNMP devices use to manage each entity within a network. One object on a network can produce a lot of data, much of it unrelated to other data from the same device. 

However, by identifying the source of any given data stream as a discrete object, SNMP enables network devices to monitor system status, availability, performance information, and more.

The Management Information Base (MIB) is the database that manages and stores all of those objects. The OID names and points to an object listed within the MIB hierarchy. To help explain the OID and MIB, imagine that you're an inventor and built a network-enabled coffee pot.

Being the good inventor that you are, you realize that the key to a good network-enabled coffee pot is sensors that can be monitored with SNMP. For instance, maybe you want to be able to tell if it's in a brewing cycle or not.

That way, you could have a monitoring system set up on your computer that tells you when your coffee is done brewing. Maybe you also configure a monitor for the temperature, so you know how hot the coffee is. Or, you want to install a toggle that indicates if somebody brewed caf or decaf. Or maybe a sensor to indicate how full the coffee pot is. That way, you'll never be the one who gets the dregs of the pot.

Each of these sensors and data flows can be assigned its own object identifier (OID), which in SNMP is a numeric string. An example might be "1.3.6.1.2.1.2.2.1.1." They're formatted like that because the MIB is like a catalog. You go to different sections of the catalog to find the right thing for the job. You categorize the sensors so that the similar jobs are all grouped together.

Let's leave our coffee machine behind for a moment and think about the network devices we'll be monitoring. Usually, you have sections like the interface — how many packets came in that interface, how many errors that interface has had, is that interface up or down. These are just a few possibilities — there are whole libraries of different OIDs created to monitor different aspects of different devices on different networks.

What you, the inventor, do is take all of the OIDs for your coffee maker, combine them all together, and get it turned into a Management Information Base (MIB). 

Just having an MIB isn't enough, though. You also need a monitoring system, such as PRTG. The monitoring system uses the MIB to understand your device, its sensors, and the data coming off of it. It also monitors all the other devices on the network.

How is a Management Information Base (MIB) Organized?

Management Information Bases (MIBs) are organized hierarchically. Before we can explain how to configure SNMP v3 on a device, we need to understand how an MIB is organized.

The International Standards Organization (ISO) initiated a tree structure—an organizational hierarchy—that MIBs follow. The ISO initiated it because it realized that with people making coffee makers, routers, switches, and servers, without an organizational structure that defines how to find all that data, it'd be random chaos.

An OID inside its MIB first specifies major branches of sensors, followed by major sub-branches, then sub-sub-branches, and finally, individual data streams.

Cisco has a robust MIB, which we'll use to explain this. Accessing their SNMP Object Navigator used to be as simple as a Google search, but now you need an account to do so. Nevertheless, we'll use their MIB.

We'll start by searching Cisco's SNMP Object Navigator for "ifindex." This will show us the entry for interface indexes on Cisco devices. We learn from their documentation that the OID for their interface index is "1.3.6.1.2.1.2.2.1.1." On the same page, we can see what that number signifies: the whole tree of how it's categorized inside the MIB.

On their page for "ifindex", Cisco has listed how it categorized the interface index: "iso(1) -> org(3) -> dod(6) -> internet(1) -> mgmt(2) -> mib(1) -> interfaces(2)", all the way down to "ifTable(2) -> ifEntry (1) -> ifindex (1)". Each category and sub-category are listed with their respective number. With each subsequent number and category, you're becoming increasingly specific about which category a specific sensor index belongs in.

Knowing how to find the OID within an MIB is an important part of configuring devices with SNMP, as is knowing that either the case-sensitive name (e.g., "ifIndex") can be used as well as its OID number (e.g., "1.3.6.1.2.1.2.2.1.1").

What are Traps in SNMP? 

Traps are asynchronous notifications that SNMP agents send to the SNMP manager when specific events happen. Think of these like push notifications on your phone. Essentially, the SNMP is letting you know that some event you decided was important has occurred. These events can be anything from a critical system error to a significant change in system status.

Traps play a crucial role in network monitoring and management by allowing the SNMP manager to receive real-time notifications about events or conditions. SNMPv3 traps provide secure communication between agents and managers, ensuring notifications are reliable and tamper-proof.

When configuring SNMPv3, you'll define which traps the SNMP agent should generate and send to the manager. This involves specifying the type of events or conditions that trigger a trap and the destination (i.e., the IP address of the SNMP manager).  

What's New in SNMP v3?

Three new elements were introduced with SNMP v3: SNMP View, SNMP Group, and SNMP User. These new elements work together to provide authentication and encryption to every interaction with devices on a network and help make sure no one is reading, writing, or accessing data they shouldn't be.

Additionally, SNMPv3 introduced the concept of inform notifications, which are similar to traps, but provide a confirmation mechanism. With informs, the SNMP manager acknowledges receipt of the notification, providing greater reliability in communication between the agent and the manager.

What is the SNMP View?

The SNMP View defines what you're able to see on a Cisco device. Using SNMP gives someone a lot of access to network devices. If you know what you're doing, you can even pull device passwords. An SNMP View can secure your network management by restricting that.

So, you might create a View that says, "I want people to only see the interfaces of this device." Or, "I want people to only see the statistics of that interface." You could even go further and say, "I want people to only see the statistics of one, specific interface of the device."

That last View would be helpful if we imagined a partner company that connects to a device on that interface because they want to see the statistics of how much traffic is being sent. You can create a view that restricts it to just that. In that case, the partner company gets the data they need but doesn't have full read/write access to the entire device.

What is the SNMP Group?

An SNMP View must be associated with an SNMP Group. The SNMP Group defines the type of access: read-only or read/write. It also specifies what kind of security is enabled during the interaction with the device in question.

What is the SNMP User?

An SNMP Group is then associated with an SNMP User. An SNMP User is added to SNMP Groups to limit their accesses and views. While associating the User to the Group, the username, password, and level of encryption and authentication are defined.

How to Configure an SNMPv3 View

To explain how to configure SNMP, we're going to configure it on a Cisco router. That's not the only thing that SNMP can be configured on, but it's a good template, and Cisco has an excellent MIB. To start configuring SNMP v3, we'll begin with configuring an SNMP View. SNMP Views restrict what people have access to on the network device.

The following command would give users access to all data related to the interface index on our router:

snmp-server view ALL-ACCESS 1.3.6.1.2.1.2.2.1.1 included

That's the command in its entirety, but let's break it down piece by piece.

We start by instructing the SNMP server to create a new SNMP View:

snmp-server view

We'll want to name the view "ALL-ACCESS":

snmp-server view ALL-ACCESS

Next is to instruct how much the View can have access to. For our demonstration, let's give users of this View access to the interface index and below:

snmp-server view ALL-ACCESS 1.3.6.1.2.1.2.2.1.1 included

Remember: directly copying and pasting the OID from the MIB is one way to add it. Equally valid is to type the OID name. But be warned: it's very case-sensitive. "ifindex" wouldn't work where "ifIndex" is expected.

This command would do the same as our previous one:

snmp-server view ALL-ACCESS ifIndex included

But now that we think of it, that's a pretty lame sensor, isn't it? We named it "all-access", but as it stands, this only allows people to see the interface index and anything that's below it in the hierarchy. If we really wanted to create an all-access View, this would be more appropriate:

snmp-server view ALL-ACCESS iso included

Now, this is an all-access View. Since the MIB is structured so that everything below "iso" is, in fact, every possible sensor, this View encompasses the entirety of the device.

You probably shouldn't give every View access to everything below the iso, which is why we also walked through the interface index configuration. If you wanted to further restrict it to one interface, you would head back to your MIB, work out which interface index you wanted to give access to, and drill down from there. Because it's a hierarchy, you can be increasingly specific about what sensors your users will have access to.

Let's also create a different View, one that isn't so permissive. We'll create one for people to monitor the interface. If you find the Interface entry in the OID tree, you'll see that it allows someone to monitor all the interfaces, all the indexes, and everything below that:

snmp-server view INT-ACCESS ifEntry included

So now we've created two accesses for people: ALL-ACCESS, which gives people total access, and then INT-ACCESS, which gives people interface access.

How to Configure an SNMP Group

Now that we've created the View, the Group will be created and associated with that View with the following command. Just like in creating our View, to explain how to configure an SNMP Group, we'll start with the complete line of code and then break it down section-by-section:

snmp-server group GROUP1 v3 priv read ALL-ACCESS

Our command starts easily enough by instructing the server what we're doing:

snmp-server group

Then we name the Group. Let's go with "GROUP1":

snmp-server group GROUP1

The next addition defines what kind of security model we'll be using. Do you want to use v1, v2 or v3? Obviously, we want to use SNMPv3:

snmp-server group GROUP1 v3

Now, big question: what sort of authentication/encryption? There are three options. First, no authentication or encryption (noauth). Second, authentication only but no encryption (auth). Third, authentication and encryption (priv). Obviously, "priv" is probably what most people are going to want if they're using SNMPv3:

snmp-server group GROUP1 v3 priv

On to that we add that we want GROUP1 to have read access:

snmp-server group GROUP1 v3 priv read

At this point, we specify what View we want associated with this Group. Let's say ALL-ACCESS (and we also start to see how we're putting these puzzle pieces together):

snmp-server group GROUP1 v3 priv read ALL-ACCESS

With that line of code, you've created a Group. You created GROUP1. It's going to use SNMPv3, require those looking to access it to authenticate and have encryption, and allow anyone on it to have read-only access to ALL sensors on this device.

How to Configure an SNMP User

The last step is to configure an SNMP User. We'll follow the same steps as we did before: we'll look at the final line of code and then explain it one part at a time:

snmp-server user CBTNUGGETS GROUP1 v3 auth sha NinjaSNMP priv des56 asdfasdf

The command starts with the command to begin the process of creating a new user:

snmp-server user

For simplicity, our username is "CBT NUGGETS":

snmp-server user CBTNUGGETS

This is one of the key parts. Which Group is this User going to belong to? Well, "GROUP1" of course:

snmp-server user CBTNUGGETS GROUP1

Next, we specify what version of the security model this user will be using. We'll want to make sure we match the group:

snmp-server user CBTNUGGETS GROUP1 v3

After that, we tell it what authentication mode. We're going to use SHA. We use this because our passwords are going to get hashed, not sent in cleartext:

snmp-server user CBTNUGGETS GROUP1 v3 auth sha

What should our password be? How about "NinjaSNMP":

snmp-server user CBTNUGGETS GROUP1 v3 auth sha NinjaSNMP

What kind of encryption parameters do you want to use for this user? It's important to know what your OS supports, from DES56 to 3DES or AES. Your monitoring system has to support the level of encryption you specify:

snmp-server user CBTNUGGETS GROUP1 v3 auth sha NinjaSNMP priv des56

Last, what is the shared secret. That is, what is it that generates those encryption keys. Keep in mind that you do have to remember it, and it should be more complex – in real life – than "asdfasdf". But for our purposes:

snmp-server user CBTNUGGETS GROUP1 v3 auth sha NinjaSNMP priv des56 asdfasdf

We now have our first SNMPv3 user. This device is ready to be monitored with SNMPv3.

How to Add a Device to a Monitoring System Using SNMPv3

Now that you've configured an SNMPv3 View, Group, and User, and associated them with one another, the only thing left is to add the device to your monitoring system. There are different monitoring systems, but the important thing is bringing the information you wrote in the configuration steps into the system.

Once in your monitoring system's interface, you'll want to have the IP address of the device you're adding. Most monitoring systems have an SNMP Device Settings area where you'll enter the credentials.

In the SNMP Device Settings area, make sure your security model version is accurate. Toggle SHA authentication and specify what usernames and passwords are allowed. The encryption type and data encryption key must match.

Wrapping Up

The steps for configuring an SNMP View, SNMP Group, and SNMP User can be complicated, but the underlying commands are easy enough. The most important concepts you could learn are the hierarchy of an MIB and the relationship a View has to a Group and its assigned Users.

Want to grow your career as a Network Administrator? Consider our Network+ training.