In this Cisco CCNA training tutorial, you’ll learn about SNMP, which is the Simple Network Management Protocol. It’s an open standard for network monitoring and you’ll see it being used on nearly all vendors’ devices, such as routers, switches, servers, and everything else as well. Scroll down for the video and also text tutorial.
SNMP Simple Network Management Protocol Video Tutorial
Krystian Krupinski
I want to let you know that I passed my CCNA. I’m really happy with my achievement and it’s all thanks to you! Your course is by far the best one out there.
The terminology for SNMP. There is an SNMP manager, which is the SNMP server, and it can collect and organize information from an SNMP agent, which is SNMP software, which runs on managed devices such as routers and switches.
That's the official terminology, but in the real world, you won't hear people talking about SNMP manager and SNMP agent. The manager will be called an SNMP server or an NMS system, which stands for Network Management System. The managed device is just an SNMP managed device.
The SNMP manager of a server can pull information from the device with a Get command or the device can push it to the server with a trap.
For example, the manager could query to get traffic statistics from the device or the device could report an HSRP state change. If one of our routers in an HSRP pair went down, the router could push a notification, push a trap to the NMS server about that.
The standard also includes support for modifying agent information from the SNMP manager to change device behavior, but that's not used so commonly. Most often, the NMS server will pull information from the devices or the devices will send a trap to notify the SNMP manager that something happened.
MIB Management Information Base
There is a MIB is used as the database for the information. Data variables on SNMP managed systems such as the state of an interface and the state of OSPF. Those variables are organized into a MIB, the management information base, which has the database of things that you can gather information about on your different devices.
The SNMP manager and agent need to share the MIB so that they know which variables can be reported on. Different types of devices will have different MIBs because the kind of information you would want to gather from a Windows server would be different than the type of information you would gather from a router or a switch.
The diagram below shows the architecture. We've got the SNMP manager, which is our NMS server. In the example, there's a couple of managed devices and they're both running the SNMP agent software. We've got a switch and a router and they've got MIB, which includes variables that are relevant to that type of device.
The SNMP manager understands the MIB as well and the SNMP manager can send queries to the devices to gather information from them. The devices can also send trap notifications to notify the SNMP manager that something happened. Also, you've got that third option where the SNMP manager push and change information on the devices but it is not used commonly.
SNMP Versions
There are three major SNMP versions. The first version was SNMPv1 that uses plain text authentication between the manager and the agent. The authentication is not encrypted, anybody can read it if they're sniffing that traffic. The method that is used for authentication is Community Strings which acts like a password.
SNMPv2c also uses plain text Community Strings for the authentication, the main advantage of SNMPv2c over SNMPv1 is it supports bulk retrieval. Rather than having to send a new message for every piece of information at once to get, it can send a request for multiple pieces of information at the same time, makes it more efficient.
The latest version is SNMPv3. It does support strong authentication and encryption with the use of usernames and passwords. It is the preferred version because it is secure, but it's not supported on all devices. You'll find a lot of devices are still out there today, don't have support for SNMPv3 yet. In that case, you would have to use SNMPv2c if you did want to enable SNMP.
SNMPv2c Community Strings
Talking about the authentication in SNMPv1 and SNMPv2c, it uses community strings rather than the normal username and password that you're used to. The Community String is used to authenticate the SNMP manager and the agents to each other. It acts just like a password and the same Community String value has to be set on both the agent and the manager.
SNMPv2c Configuration Example
There are both read-only and read-write community strings. The read-only community is used by the manager to read information and the read-write community is used if it wants to set information. Here's a configuration example:
This is how we would configure the configuration on our router for SNMPV2. On the top, we see a global config, snmp-server contact , which is my email address. Then the snmp-server location, Flackbox Lab.
That's just purely information knowing it's optional if you want to set that, but your SNMP server is going to be monitoring lots of different devices. So if you've got some descriptive information about the device, that will be sent to the manager.
The next part of the config is our community strings, which are used for authentication. We're configuring both a read-only and a read-write community string. We've got snmp-server community Flackbox1, which we're using as our read-only string, and snmp-server community Flackbox2, which we're going to use as the read-write string.
Then, we need to configure where our SNMP server is. So we see snmp-server host 10.0.0.100 Flackbox1 is where the server is. For communicating with that server when we're sending traps, we're going to use our read-only community string, which was Flackbox1.
We then put in a command to send traps to that server. This is optional. If we did not have the snmp-server enable traps config command, the server would still be able to query this router to pull information from it. But because we're configuring traps, we're also going to push information to the server as well.
There are lots of different types of traps that you can send. You can send information about a change in the OSPF state, a change in the state of an interface, et cetera. Here, we're doing traps config, which means whenever anybody else goes to the global configuration, it's going to send a notification about that to the server.
SNMP Security Best Practice
The last thing to tell you here is some SNMP security best practice. We said before, the SNMP is an open standard supported by nearly all vendors' devices. Most devices will use a default read-only community string of public and a default read-write community string of private. Attackers can use this to read or set information on your devices.
If an attacker has got IP connectivity of the device, and it's been set up with SNMP enabled using the default community strings with public and private, then the attacker can use that to pool information about the device. There's likely to be sensitive information there, but they can then use to launch an attack against your devices. So you do not want to leave that as the default setting.
Best practices to disable SNMP on devices if it's not being used and if you do want to use SNMP, use SNMPv3 with secure passwords because that is a secure way of implementing it. However, quite likely, you will have devices that do not support SNMPv3. In that case, use SNMPv2c, but use non-default community strings, don't use public and private.
Syslog vs. SNMP
Syslog and SNMP are both used for logging. You've heard about SIEM systems and NMS systems as well. And you're probably thinking, well, aren't these things all doing the same thing? Do I have to choose one or the other? Or what do I do?
First, stop comparing Syslog and SNMP. Both Syslog and SNMP provide logging functionality. Syslog can often provide more granular detail than SNMP can, but it has support only for the device pushing information out to a Syslog server. It doesn't support a server pulling or sending information onto the device like you can do with SNMP.
Syslog is a bit more granular data on the amount of reporting it can do but SNMP has got a bit more functionality there. So do you have to choose one or the other? Well, No. NMS servers will typically support both Syslog and SNMP.
In the diagram below, that's from the Kiwi website, you can see Kiwi’s server marketed as a Syslog server, but it supports SNMP as well. It also supports other types of events coming in, for example, from the Windows event log.
This is typical, an NMS system will usually support getting information from multiple sources, both Syslog and SNMP and other sources as well, including net flow from Cisco routers. You don't have to choose one or the other. You can run both and you can use them where they fit best.
NMS vs. SIEM
The next thing is NMS and SIEM. The NMS is your Network Management System. The SIEM is your Security Information and Events Manager. Just like there's overlap with Syslog and SNMP, which are the protocols that are used, there’s overlap between NMS and SIEM systems as well, which are the servers that are used to monitor all this information.
With NMS and SIEM, both can gather logging information from network infrastructure devices, such as routers, switches, and firewalls, also from other devices as well, like servers. Both use protocols like Syslog and SNMP and NetFlow to send networking information from Cisco routers.
So what's the difference between NMS and SIEM? They are both gathering that information. A product that is marketed as an NMS will have a focus on collating network information and it will provide nice reports and a nice GUI so you can see what's going on with your network. It will provide early warning of any problems and easier troubleshooting those problems as well.
A product that is marketed as a SIEM as a security manager will have a focus on collating security information. It will provide reports, which focus on that and early warning of any security incidents and easier troubleshooting.
Both gather the same kind of information but they've got a different focus on how they're going to report it and the tools that you can use to manage it.
NMS
Let's have a look at an example of NMS system below. SolarWinds is a very popular paid NMS and you can see that it got a nice GUI. You can get nice graphical reports. And over on the right, you can see the kind of information that is being highlighted, interfaces with high percent utilization.
If you've got interfaces that are getting congested, it's going to tell you about that. You can fix it by putting more bandwidth in there, or maybe by configuring QoS quality of service. Also down at the bottom, there’s reporting and interfaces with high error and discard rates. It's giving you a nice dashboard where you can see everything that's going on in your network. It's also highlighting any potential network problems.
SIEM
If we look at SIEM, this is from the info site. It can get the same kind of information, but you see that it's focusing on different types of reports. It's telling us the top 10 event categories. We can see that the most common fault we have is authentication. Meaning people are putting in the wrong password. That's normal for that to be high because people do sometimes put in the wrong password.
But if you see that that is unusually high and there's been a jump in it, that could indicate that an attacker is trying to break in your systems by guessing your passwords. Further down, we can see the next most common thing is malware attacks against us. Another, we can see other exploits in there as well, other kinds of information.
We can see whichever the most common attacks are being launched against this. Also, which hosts have been receiving multiple events. So if we're a security engineer, we're going to come in the morning, we're going to look at this dashboard. Maybe one of the first things we'll do is we'll go and we'll investigate these hosts to see if there's anything bad happening with them.
SNMP Simple Network Management Protocol Configuration Example
This configuration example is taken from my free ‘Cisco CCNA Lab Guide’ which includes over 350 pages of lab exercises and full instructions to set up the lab for free on your laptop.
Click here to download your free Cisco CCNA Lab Guide.
- Configure SNMP communities on R1. Use Flackbox1 as the Read Only community string, and Flackbox2 as the Read Write community string.
R1(config)#snmp-server community Flackbox1 ro
R1(config)#snmp-server community Flackbox2 rw
2. Configure R1 so it will show events from all severity levels to the external Syslog server at 10.0.0.100.
R1(config)#logging 10.0.0.100
R1(config)#logging trap debugging
3. Verify you have set the correct severity level.
R1#show logging
Syslog logging: enabled (0 messages dropped, 0 messages rate-limited,
0 flushes, 0 overruns, xml disabled, filtering disabled)
No Active Message Discriminator.
No Inactive Message Discriminator.
Console logging: level debugging, 3 messages logged, xml disabled,
filtering disabled
Monitor logging: level debugging, 3 messages logged, xml disabled,
filtering disabled
Buffer logging: disabled, xml disabled,
filtering disabled
Logging Exception size (4096 bytes)
Count and timestamp logging messages: disabled
Persistent logging: disabled
No active filter modules.
ESM: 0 messages dropped
Trap logging: level debugging, 3 message lines logged
Logging to 10.0.0.100 (udp port 514, audit disabled,
authentication disabled, encryption disabled, link up),
2 message lines logged,
0 message lines rate-limited,
0 message lines dropped-by-MD,
xml disabled, sequence number disabled
filtering disabled
4. Enable then disable the FastEthernet 0/1 interface on R1.
R1(config)#int f0/1
R1(config-if)#no shutdown
%LINK-5-CHANGED: Interface FastEthernet0/1, changed state to up
R1(config-if)#shutdown
%LINK-5-CHANGED: Interface FastEthernet0/1, changed state to administratively down
5. On the Syslog server at 10.0.0.100, click ‘Services’ then ‘SYSLOG’ and check you can see events for the interface coming up then back down.
Additional Resources
How to Configure SNMP Community Strings: https://www.cisco.com/c/en/us/support/docs/ip/simple-network-management-protocol-snmp/7282-12.html
Network Management System: Best Practices White Paper: https://www.cisco.com/c/en/us/support/docs/availability/high-availability/15114-NMS-bestpractice.html
SNMP Configuration Guide: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/snmp/configuration/xe-16/snmp-xe-16-book/nm-snmp-cfg-snmp-support.html
Libby Teofilo
Text by Libby Teofilo, Technical Writer at www.flackbox.com
With a mission to spread network awareness through writing, Libby consistently immerses herself into the unrelenting process of knowledge acquisition and dissemination. If not engrossed in technology, you might see her with a book in one hand and a coffee in the other.