And last, but not least,
we're going to move onto configuring SNMP on a Cisco router.
Now I have a very simple Cisco router here,
it is a cloud services router 1000v that again,
is running in Azure just like the other 2 virtual machines.
And again, I know that not every organization uses Cisco equipment,
again, not getting involved in that whole holy war.
This is just honestly what I know the best and it's a good example of
how to configure SNMP v3 and exposes some of the more nuances of the
SNMP v3 authentication and privilege system.
So the first thing we're going to do is go into configuration mode,
and we're going to use the command snmp-server,
and we're going to use the snmp-server?
command just to see what options are available.
There are many options in the SNMP server configuration for Cisco devices.
Honestly, for this course,
we're not going to use most of them because we are focusing on
the SNMP protocol specifically and not necessarily the detailed
SNMP implementation on a Cisco device.
For SNMP version 2,
it's quite simply as simple as entering SNMP server
community and SNMP community string, in this case,
I'll use GLOBO-RO and telling it that it's a read-only community string.
Now you'll notice up near the top of the command list,
you can specify an access control list for use with the community string.
This is very similar to what's in the Windows operating system
where you can say only these hosts or this network is allowed to
access the SNMP interface on this device.
I recommend that if you use SNMP v2 on your Cisco devices that you always
use an access control list to limit which workstations or IP addresses can
access information on your device because,
again, as we've discussed, even if you can't actually write information to it,
you can read a whole lot of information and gain some
intelligence about how the network is laid out,
etc.
As an extra layer of security,
you can also use the view command towards the bottom of the
command list to specify a list of OIDs that this particular
read-only community string can view.
If you don't specify a view, then it can read any OIDs off of this device.
We'll get a little more into SNMP views when we
discuss SNMP v3 here in just a moment.
But honestly, for SNMP2, that's the only command you really have to have,
snmp-server community, the string, and whether it's read-only or read-write.
So once you do that,
if we do sh run and include just lines that have SNMP on there,
you'll see that that's the only SNMP command on the router right now.
Now we can also go in,
and we're going to do this for this router because there's not any default,
we'll do SNMP server and we'll do contact and a bit of contact information.
So I'll put my name there and we'll also do snmp-server location,
and we'll say somewhere in the cloud.
So now if we run that same command,
you'll see we have three SNMP server commands on this guy.
We have a read-only community string that can read anything on the
device and we specified the location and contact.
Now one other core SNMP command that you'll need to enable,
if we go back into configuration mode,
we will do snmp-server ifindex and we'll say persist.
What this does is this allows those interface indexes that
we saw when we used the MIB walker earlier in the course to
stay the same across reboots.
In theory, if you add or remove interfaces to an SNMP capable device,
it could change the SNMP interface ID or interface index and throw off all
of your SNMP manager statistics if they're not intelligent enough to realize
that hey this device has completely changed,
it used to be a serial port, now it's an ethernet port,
unless you remember to go change it yourself.
If you tell it to persist the interface indexes,
then once you assign an interface index to a particular physical interface,
that index will never change.
So now that we've done the basic SNMP configuration, we're going to move onto configuring SNMP v3.