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 having devices — usually sensors, servers and network architecture devices — share information about themselves with other devices on the same network running different software on different hardware.

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.

What are the Different Versions of SNMP?

The current version of SNMP is version 3, but versions 1 and 2 preceded it. Understanding SNMP v3 requires jumping back in time to version 1 and version 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 was essentially a pre-shared key on the device that you're managing. That community value gave whomever had access permission to read all of the sensors on there. You could even read/write all of the sensors on there without any kind of encryption or authentication mechanism in place.

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. But 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 that's listed within the MIB hierarchy. To help explain the OID and MIB, imagine that you're an inventor. And imagine further that you 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 maybe 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 their own object identifier (OID). And in SNMP, that's 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 a moment and think with network devices that 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 and 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. For example, PRTG. The monitoring system uses the MIB to understand what your device is, what its sensors are, and what sorts of data are coming off of it. It's also monitoring all the other devices on the network.

How is an MIB Organized?

Management Information Bases are organized hierarchically. Before we can explain how to configure SNMP v3 on a device, we need to make sure we 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 they 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, that's followed by major sub-branches, then sub-sub-branches, and all the way down to 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 access it. Nevertheless, we'll use their MIB.

We'll start off 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'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.

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 who connects to a device on that interface because they want to be able to see the statistics of how much traffic is being sent. You can create a view which restricts it down 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 does the work of defining the type of access: read-only or read/write. The SNMP Group 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 gets added to SNMP Groups to limit what accesses and views they have. While associating the User to the Group, the username is defined, the password, as well as the level of encryption and authentication.

How to Configure an SNMPv3 View

To explain how to configure SNMP, we're going to be configuring SNMP 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. And to start with 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 just 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 would 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; it's going to require those looking to access it to authenticate and have encryption; anyone on it will have read-only access; they'll have 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 "CBTNUGGETS":

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 to 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 interface for your monitoring system, you'll want to have the IP address of the device you're adding. Most monitoring systems will have an SNMP Device Settings area where you'll enter the credentials.

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

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.

This post is a tiny taste of the training CBT Nuggets can offer you on SNMP. SNMP familiarity is key to taking and passing your CCNA as well as simply crucial for a network administrator dealing with monitoring network devices.