1. 15.0 Monitoring and Analyzing Networks
We don’t just set up our network one time and it runs forever, we need to keep a constant eye on how it’s doing. We need to be able to gather information for troubleshooting issues that will most definitely come up. So in this module, we’re going to be taking a look at some devices, protocols, and applications that let us monitor our network and analyze its performance. In fact, we’re going to check out some device monitoring tools in our next video. I’ll see you there in just a moment.
2. 15.1 Device Monitoring Tools
As network administrators or network engineers, it’s important that we keep our finger on the pulse of the network to be monitoring what’s going on with the network. That way we can better anticipate a potential issue before it actually impacts our users. We might be able to anticipate that we’re going to run out of bandwidth a couple of months from now. If we don’t upgrade, we might be able to anticipate the need for another router because we have high CPU utilization on our current router or high memory utilization. That’s what we want to focus on in this video, monitoring what’s going on in our network. First, let’s talk about device monitoring. And there are lots of different pieces of hardware and software that we could use to monitor network devices. There’s a specific term I want you to know about. It’s sort of an umbrella term.
We pronounce it Simsiem, which stands for Security Information and Event Management. This is a very broad term. It’s talking about a collection of hardware and software that can monitor various network services and allow those services to report the information that they collect back to a single repository where we can then examine that information. One example of a software service that might fall under this category is something called Syslog, and there are many different network appliances and servers that can report information to a Syslog server. We can have routers and firewalls and switches it’s. A few examples say if an event occurs that is of a certain severity level, I’m going to report that to this centralized Syslog repository.
And later in this video, I’m going to show you how we can configure a Cisco router to point to a Syslog server, and we’ll take a look at the information collected on that Syslog server. We might also want to keep an eye on interface statistics. If we’re getting errors on an interface, that might prompt us to do some investigation. We might see if we’re approaching full capacity on that interface. Let’s keep an eye on our CPU utilization and our memory utilization. Are we about to run out of capacity on a particular device? Now? Let’s consider monitoring different processes. We mentioned that we could use something like Syslog to collect log information.
Well, it’s great that we’re collecting it, but we should have somebody assigned to routinely go in and inspect those logs, maybe looking for specific warning signs, because if we don’t examine our log information, it’s of limited value to us. We might also do something that an attacker might do. We want to do it before them. We might want to do a port scan. We can specify a range of network addresses, and we can say for each of the addresses in this range. I’m going to see what ports are open and are there any vulnerabilities known on those ports on that particular operating system. And to help protect someone from launching an exploit against one of those vulnerabilities.
We should routinely patch our servers and our hardware. In fact, Microsoft used to have something, in fact, I think they still do, called Patch Tuesday, where every Tuesday they would come out with a security patch that you should apply. And I think it’s great if you or someone else on your team has that as one of their responsibilities to periodically apply those patches. And when we’re looking at our data and reviewing our logs, how do we know what’s a good number and what’s a bad number? We should have some baseline data. In other words, data for these statistics that we’re examining. What does that data look like during the good times when we’re not having an issue on the network? That way, if we are experiencing an issue, we can say, I wonder if this is a good number or a bad number.
Let’s go check the baseline. And if we are far off from that baseline, yeah, we might need to investigate that. Another tool we can use to monitor what’s going on on the network is a packet analysis, some sort of a packet capture software. And I’m a big fan of the free wireshark which you can get@wireshark. org. And some of our devices, like our routers, they may support something called NetFlow. NetFlow can give us very detailed visibility into what’s happening in our network with different traffic flows. And there are many vendors that make software called NetFlow collectors. Here’s one example of one that I’ve used a bit. It’s called live action. And you can see from the different lines on screen of various colors, you can actually see the end to end communication of different traffic flows. Now let’s go out and take a look at a Cisco router. For example, I’ll show you how we can point it to a Syslog server. And we’ll take a look at the results on that Syslog server. And we’ll play with a couple of other commands as well. Here we’re on a Cisco router. It’s named r One. And up top on screen, you see the console for my Syslog server and the Syslog server. You see its IP address 170, 216, 110, 178. So I want to point my Cisco router to that Syslog server. Here’s. How I do that? I’m going to say logging, and I’ll give the IP address of 170, 216, 110, 178.
Now I can specify what events get reported to that Syslog server. I probably don’t want to report every little thing that could maybe fill up the hard drive on that Syslog server. So check this out. I can say logging trap and notice we can specify different severity levels. I could use either the numbers zero through seven or the name like emergencies or informational. And the lower the number, the more severe the condition. You see that a severity level of a zero is an emergency. The system is unusable a severity level of a three, well, that’s an error. But everything’s not broken and a severity level of five. Let’s do that one in our configuration. This is going to give us a notification. It’s not indicating that something is wrong, but it’s something significant that we should know about.
So I can say logging trap and I could either say notifications or give the number five. I’ll just say notifications and we’ll press Enter and let’s do something that’s going to create a normal but significant condition. And one thing is just me exiting my configuration mode. This message that just popped up at the bottom, that is a Syslog message. And you can see that it’s a severity level of a five. That’s what that means. And if I refresh my Syslog server, you’ll see that here is the information about that event that just happened. It was a notice or a notification. It came from a device named R One on my LAN and it has a message, it says Configure from console by console. Now let’s shut down an interface. Let’s go into global configuration mode and I’ll say interface gigabit zero one and I’ll do a shutdown.
And if I refresh my Syslog server again, we should see that as well. And we see that the interface gigabit zero one changed state and it gave me another, hey, somebody configured something from the console because I went back into global configuration mode and then came back out again. So that’s a look at how we can set up a Cisco router to point to a Syslog server. But let me show you a couple of other things. If I want to keep an eye on interface statistics, I could use this command. I could say show interface and I’ll use gigabit zero. And this is going to give me some information about, on average, what is my input and output rate on this interface? I’m not really sending much from this interface.
The average is zero bits per second. But coming in from my network, this is just a router in a lab environment. So I’m not generating any traffic going out to the network. But it looks like we’ve got about 117 kbps coming into this router. And if I had error messages, well, I could get some stats about those different types of errors. If I want to see what my processor utilization is, I could say show processes. And this is going to tell me over the last 5 seconds, on average I have a 2% processor utilization over a 1 minute average 3%, and over a five minute average 3%. But yeah, it looks like I’ve got plenty of processor utilization to spare on this particular router running in my lab environment. And that’s a look at how we can monitor some different processes and devices in our network.
3. 15.2 SNMP
In this video, we want to take a look at a protocol we can use to manage our network. It’s called SNMP Simple Network Management Protocol. And with SNMP we can have a server running some sort of an SNMP manager software package. And we can be monitoring and communicating with devices on the network if they are configured as SNMP agents. And an SNMP agent has a database of information that it can monitor and that might vary device to device. One device might be measuring interface throughput, another device might be measuring the temperature in a room. It could vary widely. But this database of things that they can monitor and manage, it’s called a MIB, a Management Information Base. And this Management Information base again, is made up of individual things that can be monitored. And those are called OIDs object identifiers.
And this is a two way communications protocol. Here’s what I mean by that. We can configure these SNMP agents to keep an eye on specific statistics and we can say if a certain threshold is exceeded or we drop below a certain threshold, then we can let the SNP manager proactively know about that. Let’s say that I’m monitoring interface statistics on R One and the bandwidth utilization on an interface gets up to about 75% of that interface capacity. And that might be noteworthy enough for us to inform the SNPP manager. So if I’ve exceeded this threshold that I’m monitoring on R One, r One can send out what is called a trap notification to that SNMP manager to say, hey, you told me to watch for this event and it happened, and I’m notifying you about that. But I mentioned that this is two way communication. And what I mean by that is not only can the agents proactively inform the SNMP manager what’s going on, I could go to the SNMP manager and query one of those devices. I could say, for example, what is the temperature in your room? I want to make sure you’re not overheating. Perhaps because we just lost one of our HVAC systems, we’ll say so I could send out a query and we’ll get a response saying, all right, here is the current temperature. And a big consideration when it comes to SNMP is how we do security. Because for years it was very not secure. And here’s why.
In the original version of SNMP, version one, security was enforced by community strings, which are basically passwords. There was a readonly community string and if you had that string, then you could get information from the device. And there was a read write community string. If you had that password or that community string, not only could you read information from the device, you could reconfigure the device. You could actually write changes to the device. And again, those were called community strings. Think of those as passwords. Then version two came out, and version two had much more robust security and it had some other nice features. However, the security was so difficult to implement, almost nobody did it. So SNMP sort of took a half step back. They said, all right, we want to keep all the new features in version two, but nobody really likes the way we’re doing security.
So let’s go back to community strings. And even in version two C, we were using the very non secure community strings. And one reason I emphasize that it was not very secure is that when I was working with this back in these early versions, multiple vendors would use the same default community strings on their equipment. Almost any device I bought would have a read only community string of public and a read write community string of private. And if somebody knew that information, they could go into an environment that was not really doing SNMP. They just left everything at the default configuration and they could actually change the configuration on those devices because they could just try that very, very well known read write community string of private.
So today, when you’re setting this up, I strongly recommend you use version three. It does security, right? Not only does it encrypt data going back and forth, it’s going to do integrity checking to make sure it doesn’t get corrupted or manipulated in transit, and it’s going to do authentication. In fact, there’s a requirement with version three that says even if I get your router configuration printed out, I cannot see your username information that has to be hidden. So it is very, very secure, especially compared to previous versions of SNMP. And that’s a look at SNMP the Simple Network Management protocol.
