Alright folks, let's take this time to have a quick discussion on SNMP, Simple Network Management Protocol.
So what we're dealing with here is a management protocol that we typically use to poll our devices.
Why are we polling our devices? Like our routers, our switches, our servers, or any other device that supports SNMP,
so we can collect and organize information about the health and well-being about them.
You see, each of our devices that support SNMP has something known as the Management Information Base, the MIB.
And the MIB is essentially a database that stores variables.
Okay, what is variables? Information about very specific things.
What specific things? Everything about our device.
So for example, like your interface status, your five-minute CPU utilization, your two-minute CPU utilization,
your five-second CPU utilization, the amount of memory that's being consumed,
the amount of this, the amount of that, etc., etc., etc., etc.
Pretty much anything you can do in the command line interface or verify in the command line interface,
there is an SNMP variable in our MIB associated with that that we can use SNMP to poll and grab
and have that information available to us on an SNMP network management system.
So with SNMP, we have an NMS running SNMP management software, and then our devices are running an SNMP agent.
And it's the communication between the SNMP server and the SNMP agent that uses SNMP,
Sybil Network Management Protocol.
And by default, we're using UDP port 161 for that communication.
So we can configure our devices, because if you can modify a variable in the MIB, then you can configure, right?
But you can also simply just poll and say, hey, give me information about this.
Give me information about that.
Give me the information you have about this.
Give me the information you have about that.
That would be polling the device and using it for monitoring purposes.
So the agent is going to control access to the MIB on the devices.
And our devices already come preloaded with the SNMP agent on them, our Cisco iOS devices.
Now, the problem with this scenario for a lot of us is that there is a polling period.
And so the polling period is going to be dependent on what you're trying to collect.
So, for example, mission-critical information, you might want to poll more often.
You might want to poll, like, maybe at a 15-second interval or a 30-second interval or maybe a 5-second interval.
Whereas non-mission-critical information, you might be polling maybe a 5-minute interval, 1-day interval, whatever.
So it's up to you to configure your NMS with the right polling interval for the information that you want to collect and when you want to collect it.
But there are going to be times when you don't want to wait for that polling period no matter what for certain things.
If something happens, an event on our device, a change of state, we want to know right away.
And so that's where TRAPS and INFORMS come into play with SNMP.
So with TRAPS and INFORMS, we have the ability to be notified right away as opposed to waiting for the polling period to get that information.
So TRAPS is about pushing information, pushing information.
INFORMS are about pushing information, pushing information.
Whereas typical operation is to just poll.
All right.
So TRAPS and INFORMS, we have reliable and unreliable.
So TRAPS are unreliable.
INFORMS are reliable.
Let me repeat that.
TRAPS are unreliable.
INFORMS are reliable.
And you might be saying, oh, TCP, UDP.
No, you're wrong.
Not this time.
No, sorry.
So they're both using EDP.
So it's UDP port 162.
So polling uses UDP port 161.
TRAPS and INFORMS use UDP port 162.
So what makes, for example, the INFORM reliable and the TRAP unreliable?
So think about it this way.
A TRAP, we send the message, boom, done.
So let's say our five-minute CPU utilization was 80%.
Boom, send the message, we're done.
We don't even care.
That's it.
It's over.
So did the NMS get a yes or no?
We don't know.
And as admin, we wouldn't know if it got it.
We wouldn't even know this was going on then.
So if you need reliable, then basically when that situation occurs, you send the INFORM,
and then you're waiting for a reply from the server.
If the server got it successfully, it replies back with, yeah, I got it.
Good, thank you.
That's it.
Basically thumbs up.
Think of it that way.
If it doesn't respond, then I send it again.
If it doesn't respond, I send it again.
Then all of a sudden it responds back, yeah, I got it.
Good.
Perfect.
Done.
Now I can stop sending it.
So that's all the INFORM does.
It gives us the ability to have an acknowledgement.
That's all it does.
All right.
So knowing port numbers is always a good thing for any Cisco certification exam.
So there they are.
So TRAPS and INFORMS are 162.
The polling uses 161.
You don't really need to know these messages for the exam, but these were the messages
that were originally introduced with SNMP version 1.
These were the ones that were added with version 2.
The thing, though, is that most of us don't realize that version 2 was actually something
that offered enhanced authentication, enhanced encryption, and it never took off because
it was so complicated, but people still wanted these additional INFORM and GET BULK requests.
That's why they invented version 2C.
So version 2C doesn't mean A failed, B failed, we ended up with C in the end.
No.
C means community strings.
So with SNMP version 1, we use community strings.
With SNMP version 2C, we use community strings.
And what is a community string?
If you don't know, it's a shared password, a shared secret.
That's all it is.
Everything's in plain text.
Keep that in mind.
All right.
So it's not until SNMP version 3 where we get more secure.
And so with more security, we get what?
Like enhanced authentication, integrity checking, encryption, authorization, all of that comes
along with SNMP version 3.
And we have three different security models.
We've got no auth, we have auth, and we have priv.
Now, many people fall into the trap because they're misled into thinking that no auth
means no authentication.
No, no, no, no.
It simply means like no authenticity, no integrity checking, nothing like that, but we still
have to authenticate.
And we authenticate with what is called a username.
So my device has to be configured with the same username as the NMS.
Okay.
Now, when I say username here, folks, we're talking about the SNMP username configuration.
Essentially, it boils down to being a community string.
That's all it is.
So it's basically a shared password, a shared secret.
Everything's in plain text.
That's all it is.
So it's really very similar to version 1 and version 2C when it's all said and done from
a security standpoint.
Auth now uses the username plus hashing algorithms.
So now we get enhanced authentication.
We get integrity checking as well.
And then priv uses the username, the hashing algorithm, and an encryption algorithm.
So now we get our enhanced authentication, our integrity checking, and our encryption
for our privacy when it's all said and done.
So the best one here is SNMP version 3 priv.
I'm going to show you a couple of configs here now, one for 2C and one for version 3
just to help you get in the right mindset for the certification exam.
So that way there, if an SNMP config shows up, you have the ability to read through it.
So we're not going to get into the nitty-gritty details of SNMP configuration and doing some
fancy things with it.
It's just basic, straightforward, fundamental here, just like you would alerts in CCNA.
So first of all, I always love talking about the access control list because you have this
server out here that is going to be your NMS.
And you want to make sure that you are controlling who is allowed to connect to your MIB,
who is talking to your agent.
So because your server has an IP address, you might as well create an access control list that
you can then call upon later on.
So that way there, you only allow the server with this IP address to actually talk to you
using SNMP.
This line here, SNMP server community, this is setting up the community string on the
device.
So that would have to match whatever we decided to set up on the server for this scenario.
So there you go.
Notice it says read-only, RO.
That means that this is for read-only communication.
You cannot write.
You cannot change variables.
You can only read the variables and the information out of the MIB.
Now, if you wanted to do read-write instead, you wouldn't need this line, of course.
You would just need the next line, SNMP server community, and then have your password.
So in this case, I typed in a different password there.
And RW would have to be listed there.
So that would be read-write, meaning you can pull from the MIB, but you can also change
variables in the MIB as well with that configuration.
You have traps.
So what do we say?
Traps give us the ability to push, push, push to the server.
So what's the server's IP address?
SNMP server host, 10.0.3.8.
Traps, if we didn't want traps, then I could just type in informs there instead, informs.
Version 2c in this case.
And there's the community string.
So that community string would have to be configured on the server as well.
This last value here, if index persists, what does that mean?
What we need to realize is that within SNMP, MIB, our database, every single one of our
interfaces gets an index number associated with it.
And you might use this index number for running your reports.
You might actually be using it for polling.
So let's say you decide that, hey, when I want to get interface statistics or interface
information off the device, I am going to go to my NMS and I'm going to say, I want
you to poll this particular device and get the information pertaining to index number
four.
The problem is, is that if these interfaces change, meaning let's say you add another
interface, another loopback interface, or maybe you add another physical interface to
the device, these numbers can change during a reboot.
Now, in this case here, if we don't change the interface, if we don't add any extra
loopback interfaces or tunnel interfaces or physical interfaces, when we reboot, they're
going to be the same because this is what they were set up as.
But if anything changes, then this can change because our device during a reboot assigns
the index numbers based on a certain criteria that exists inside the actual product.
So we could end up with different numbers during a reboot.
And if that happens, imagine your next polling or the next statistical gathering you're trying
to do of an interface, and now all of a sudden you're getting something from a different
interface because it's now using the number that you were using on another interface.
What if the new tunnel interface was four that you created and this old interface here
is now maybe number seven?
Well, that's no good, right?
That's no good for you.
So SNMP server if index persists means do not allow these numbers to ever change once
they're assigned.
That's all that means.
And I know what you're thinking right now.
Well, why isn't that the default?
This seems rather silly, Raymond.
Yeah, I know.
I know.
I agree with you.
But, hey, it's what it is.
So imagine having something as critical as this that is not the default.
Hmm.
Might I need to know that?
Maybe.
Just saying.
All right.
Let's look at our SNMP version three example.
If you've never used SNMP version three, it can be a little bit complicated at the beginning
only because there's a nesting that goes on here.
So let's go ahead and this is our NMS, our IP address.
So, again, an access control is a really great way to start your config.
That way there you can apply it later on as we've done there.
This is an example of you controlling what's allowed to actually be pulled.
So it's another security essential parameter that we have here.
It's called creating a view.
What are we allowed to view?
So if the server accesses me, what are they allowed to view?
What are they allowed to look at?
What are they allowed to gather?
What are they allowed to pull?
So I'm creating a custom view here.
There are built-in views on our device.
You'll see some of them a little later on today.
But this custom view I called MGMT, and I am saying that you can only view the interface administrative status
and the interface operational status.
That's what that means.
And I'm going to apply it where?
I'm going to apply it right here.
You're only allowed to read the interface admin status and the interface operational status
if you are 10.0.3.8.
That's what it's all coming down to here.
So with that in mind now, what else do we have in this config?
Well, here's my SNMP server group, and I didn't get very creative with the name.
I just called it my test group for demonstration purposes.
But this group is really what's bringing everything together.
So this group called test is running SNMP version 3, and our security model is priv.
Remember, we have no auth, we have auth, and we have priv.
That is an option for SNMP version 3.
So if it's no auth, then I only need a username for authentication.
If it's auth, then I need a username and a hashing algorithm.
And if it's priv, I need username, hashing algorithm, and encryption algorithm.
So how do we specify it now?
We specify it using our SNMP server user command.
So you'll see here I created a user called user1, so user1 would have to be created here as well.
And user1 is going to be used for my group test.
Ah, look at that.
Group test.
There's my link, my nesting, my embedding that's going on here.
And this user is going to be using version 3.
So here's the deal now.
If this said no auth instead, then that's it.
I could stop right here because all I need is a username.
I could stop right there.
I have my username.
It's user1.
It matches what's on my server.
But let's say it was auth instead.
If it's auth, then we've got to go over here.
So we have our username, and now we have our hashing algorithm, and then we have our shared secret, P-A-S-S-W-0-R-D.
And if you're priv like we are, priv, then you need to go all the way.
You also need your encryption algorithm.
So we're using A-E-S-2-56-P-A-5-5-W-0-R-D.
So let's look at the username now in its entirety.
It says here SNMP user1 test group.
It's for the test group.
We're using version 3.
And because the group is using priv, I need my hashing algorithm.
My hashing algorithm is going to be SHA with a shared secret.
And then we have our encryption algorithm, A-E-S-2-56, with that particular shared secret as well.
So what's going to happen now is any time I am sending messages from my device to the server
or the server is sending messages to my device, there's going to be a hash attached to the message
for authentication and integrity checking, and everything's going to be encrypted as well.
So now we have our encrypted communication and our hashing for integrity checking and authentication.
Being enabled here, just like we did with version 2C example,
and then setting up our device to send the traps to the server.
So SNMP server host, 10.0.3.8 traps.
If I want it to be informs, then we just type in informs instead of traps.
Version 3.
And because it's version 3, then we have to specify our security group.
So is it no auth, auth, or priv?
So not security group, but security model, I mean.
So is it going to be no auth, auth, or priv?
In this case, we're going with priv, the best option available.
And then we're specifying user 1 because user 1 has the parameters that we need.
They have the hashing algorithm and the encryption algorithm that we need.
And let's not forget about if index persists.
So if index persists is all about making sure that these numbers do not change during a reboot,
whatever, ever, ever, ever.
All right.
All right, so to wrap this up, let's look at a few show commands.
So show SNMP, not very exciting.
But I did not actually have an SNMP server set up that I could send my stuff to in this particular example.
So that's why everything says zero.
But this would be about keeping track of the SNMP packets.
So are there any errors?
What are the PDUs responses?
Trap PDUs, get requests, get next, and so on and so forth.
So keeping track of those SNMP messages going back and forth from a statistical standpoint.
Down here, it does show that SNMP logging is enabled.
So this is where you can verify how many were sent, how many were dropped in regards to our logging to our server.
So traps and inform messages.
There is an example of our views.
So we have some built-in views.
And up here was the custom view that we created.
Just by typing in show SNMP view, you can verify that.
Show SNMP user, you can verify by typing in show SNMP user.
So in this case, we have user one we created.
And we created them to be used with the PRIV security model.
So there's our hashing algorithm.
There's our encryption algorithm.
And it doesn't show the shared secret in this case because that would kind of, you know, be a little bit of a security concern if it did that as well.
So it just shows our actual algorithms here.
But it shows us which group we're connected to, and that's how you have to verify that.
So to verify it, you have to look at, hey, what is the user, what are the users I have,
and which group is listed with a user that matches the group that I have.
So if we come over here, for example, we'll see here that with show SNMP group, here's my test group.
So my test group, I have a user associated with it called user number one or user one.
And if we look over here, we'll see that my security model for my test group is called version 3 PRIV,
which means my user better have a hashing algorithm and they better have an encryption algorithm.
So things maybe you might have to verify on a certification exam.
What is missing in the config?
Things like that, right?
Become familiar with that config and what you need to do what with.
Review management.
So what is a review?
If we have a right view, it would be listed there as well.
And then lastly, our show SNMP host output.
This is going to allow us to verify who we're sending traps or informs to.
So you'll see 10.0.3.8, UDP port 162 for both traps and informs.
So here it's traps.
But if we had configured informs, it would show up as informs instead.
And then our user.
So which user are we using for this particular security model of version 3 PRIV?
So user one.
So does user one, because it's version 3 PRIV, have all the necessary parameters we need?
Yes.
We need our encryption algorithm.
We need our hashing algorithm.
And they are listed right there.
So, folks, that is our coverage of SNMP for the Encore certification exam.