Simple Network Management Protocol, or SNMP, is not how we have taught you to configure the gear. Technically, you can configure Cisco equipment with SNMP, but that demands knowledge of a software suite named CiscoWorks, or something that can do the same thing as CiscoWorks, and we don't get into that in the routing and switching world. But CiscoWorks would be qualified as the SNMP manager. That is the NMS software if you will, the Network Management Software and an administrator would be able to log in to that NMS and that device has knowledge of what's going on on all of the equipment that it is attempting to manage. SNMP is its way of getting information to and from and so things such as reporting can be done here. We can get a high-level overview of the health of the equipment, we can get notifications when particular thresholds have been exceeded, and all of this would help the administrator of a large-scale network manage that equipment better. Because what are we used to so far in this course?
We're used to telnetting our secure shelling into gear, doing show commands to configure and troubleshoot. But we would lose the perspective there if that's all we had in an enterprise network. We would miss the forest for the trees because we're focused on just one individual thing and what if you have 500 devices to manage? That active telnetting is like putting on the blinders to the other devices in the network. So this is a really powerful way to enable the admins of an enterprise network.
This is the difference between being proactive and reactive. If we are just relying on the ability to Telnet or SSH in your device and look at our show commands, we really won't know there is a problem until that problem happens. And at that point in time, we have to be reactive, we have to fix the down switch or the down router. Whereas, if we were utilizing SNMP, as an example, well we have the reports that we can gather. We have the statistics that are being collected and if we review those on a constant basis, then we can be proactive. We can see, "Ooh! something is going on that's not too right on this particular device, we might want to look into it a little further." So that is a much better approach when it comes to managing your network, being proactive.
Simple Network Management Protocol comes in a few modern flavors, and you might have heard about some of the horror stories with earlier versions of SNMP. But in fact, the horror stories were often in the implementation of the protocol, not the protocol itself. But there are some things we have to understand about Simple Network Management Protocol. It has a long history, it is not simple as the name suggests, it is quite complex, in fact, and v1 is pretty much not used. It isn't, I haven't seen it in over a decade. But the two versions that we work with are v2c and v3. Now v1 and v2 have the same authentication modality and that is community strings. There are two of these things called community strings; there's the read-only and then the read/write community string. And you can think of this as a clear text, plain text, password. And the read-only community string would allow us to do things like get information that in fact, would be an action that we can do.
|SNMP Version||Security||Bulk Retrieval Mechanism|
|SNMPv1||Plain text authentication with community strings||No|
|SNMPv2c||Plain text authentication with community strings||Yes|
|SNMPv3||Strong authentication, confidentiality, integrity||Yes|
The read/write community string would allow us to do things like set commands that are a type of SNMP communication, and that read/write would allow us to configure the device via the NMS. Now you can see a difference, v1, v2. When you're doing a read action, you can do a get. Now it used to be that we didn't have the ability to do what is called a get next request, v1 didn't have a get bulk, a get bulk didn't exist in v1. And so we had to do get and then get next, get next, get next, get next, get next, and you get the idea. We might have to do that quite a few times. So that's the difference between v1 and v2, not a big one. But we want to do a v3 nowadays, don't we? I mean, if we have the choice and security is our concern, v3 is a better option.
v3 is definitely a better option because we introduced now the ability for strong authentication, strong confidentiality, strong integrity. So now, we're protecting that data that's being transmitted between that SNMP management station, so the NMS and our SNMP agents; our routers and our switches.
Obtaining data from an SNMP agent
We already mentioned that we can do things like graphing. Great, you can do graphing of statistics, counters that are tracked by Simple Network Management Protocol. And you know, we're just still scratching the surface if this is all we're doing with SNMP.
In this example, we're simply looking at the open source tool Cacti and we are monitoring the interface statistics. Now is this normal interface usage, is this bad interface usage?
Well we have to compare these statistics that we're collecting to our baseline under our normal operating conditions. And then once we compare them, we'll truly know whether this is bad or good, and then we can take our appropriate actions. But without this monitoring that we're doing, we wouldn't be able to be proactive. And if we're constantly peeking and our interface is transferring a lot more traffic than the baseline, well what does that mean? Eventually, it's going to fail, eventually, we're having problems with network performance, and we'll have to be reactive at that point. So it's all about being proactive here.
Let me just give you a metric that Cisco would tell you about CPU utilization for example. 70% is the danger zone for CPU utilization on a router. If you were to get to a 100%, things don't behave right, okay, just so we're clear. So we don't want to have sustained anything close to 100% and even 70% is getting up there, but that is the metric that Cisco gives us.
Let's talk about the structure of Simple Network Management Protocol for a moment. Now there is the NMS and then there are the managed devices, which are considered agents. The agent is really running on top of the device itself. Now think of the agent as a hook to the device itself via SNMP, and within that store of data is what is called the MIB, the Management Information Base.
MIB is the Management Information Base and it's a database. And it's a tree structure database, where you have tens of thousands of variables that you are managing. Those variables are stored in a hierarchy, kind of like a folder structure, and you can identify that with what is called an Object Identifier, an OID, an Object Identifier. So these are the breadcrumbs to get to an individual store of a variable inside of the MIB. And so we can, in fact, see a little bit about communication and trying to do a get for one of these OIDs. So if we look down below at the syntax, we can see -v2c, which is still by the way the predominant version, V3 is better as we told you.
[10:52] [cisco@NMS~ ]$ snmpget -v2c -c community 10.250.250.14 .18.104.22.168.22.214.171.124.1.58.0
SNMPv2-SMI::enterprises.126.96.36.199.0~ INTEGER 11
So we have our community string, which is "community" and then the IP address of the managed device running the agent, and then the OID. So we've asked for information pertaining to that specific little tiny piece of the MIB inside of that agent.
How to configure SNMP access
When we are configuring Simple Network Management Protocol, or SNMP, on a managed device, there are few things we have to do. We have to set up things like community strings. We would also want to configure things like contacts and locations. Now also remember that when we set up the access class on our vty lines, we can do the same sort of thing inside of SNMP. And so although, we won't broach that subject, I would want you to understand this is an IP-based management software. And I would want to, specifically, configure the permitted IP addresses that can issue things like SNMP get commands, SNMP set commands, because this is powerful management and we do not want that to get into the hands of any IP address that should be coming from the NMS stations and we should know where those are, those are very predictable, okay. That is going to be coming from a few IP addresses, maybe a subnet on our Network Operations Center, or NOC, teams, LANs, and so that should be well known as well.
R1(config)#snmp-server community Cisco RW
R1(config)#snmp-server location San Jose
R1(config)#snmp-server contact Joe Summer
So explore that on your own, not something that's earth shattering, but something you would be more mindful of. So we would do things like set the read-only and read-write community strings. Here we can see the setting of the read-write community strings and then the contact and location as well.