There are many different methods for managing the network. In this video, you’ll learn about network discovery, traffic analysis, availability monitoring, and more.
When you sit down to troubleshoot a network issue, you’re starting with no information. So we need to start gathering more details, using a number of different techniques. These would commonly be things like LLDP, which is a link layer discovery protocol on switches. There’s also CDP, which is Cisco’s version of this, called the Cisco discovery protocol. You might also use scanners that are able to perform ping scans or port scans of the network to identify devices that may be up and running. There may also be commercial network scanners in place, or you might use simple network management protocol.
Some organizations will run these types of scans every night on their network to gain an understanding of exactly what devices may be installed. Or this may be a scan that we simply do any time we’re trying to do some troubleshooting. And it’s not something that commonly runs every day. But if you do have a daily cycle of scans and information gathering and you can perform reports on that information, you may be able to build an interesting view of exactly what type of traffic is on your network and what devices may be sending that traffic.
We often refer to traffic analysis as a detailed frame-by-frame or packet-by-packet description of exactly the traffic that’s flowing across the network. Often, this is summarized into simplified views so that you don’t have to sift through hundreds or even thousands of lines of frames just to understand what type of traffic went across the network. For example, if you were looking at a detailed firewall log, you would be able to see exactly how much traffic was sent across the network, at which time frames.
You would know which IP was the source of that traffic flow and what IP address was the destination. And you might also be able to gather additional details such as the port number that was used, the application in use, or exactly how many bytes were transferred between those two devices. And if you’re collecting this information and storing it over a long period of time, you can use this for creating long term reports or being able to go back in time and perform detailed forensics.
Here’s a view of this firewall log. You can see, there are a number of different columns of information that are collected. One is the timestamp of the traffic flow. You can see in this view, it starts at 7:49 and 38 seconds and goes down to 7:44 and 57 seconds. There’s quite a number of traffic flows that have occurred on that network during that time frame.
You can see the protocol in use, whether it was TCP or UDP. And you can see port numbers are also listed in this log. We have a client IP address and a server IP address, so we know exactly what two devices were communicating with each other. And if we have a DNS server, we may be able to take those IP addresses and convert them into host names. In this example, the host name is the same as the client IP address. This provides us with a wealth of information for every single flow of traffic going across the network. So if you were ever wondering if someone was able to see exactly what you were sending across the network, there may be ways to gather a great deal of that information using these firewall logs.
If we’re troubleshooting a problem, we may be interested in overall performance from that device. This might include network utilization statistics or an overview of any errors that may have occurred on that device. You can usually gather this type of information using SNMP, the simple network management protocol. Maybe you’re gathering netflow statistics, you’re doing protocol analysis and looking down at the frame level. Or maybe there’s a software agent running on that device, and it’s providing you with a summary of this performance information. Based on these statistics, we can begin to understand if our network is highly utilized, if we’re seeing a large number of errors, and try to get an idea of where the problems may be occurring with that device.
Sometimes, the statistic that is most important is, is a device up, or is a device down? We can find this information by looking at our availability monitoring. This provides us with green for up and red for down. And we can instantly see where a device may be active or where it may no longer be on the network.
This could also be rolled into a set of alarms and alerts. So we can constantly monitor these devices. And if any one of them happens to turn red, we can instantly start sending email messages, opening up helpdesk tickets, and sending alarms and alerts to the people that can solve this problem. The view that we have here is a real time view of the devices and whether they are up or whether they’re down. But we could also collect this information over time, allowing us to build a report that shows overall performance and availability over an extended period.
This is obviously a very simple metric. The device is either active, or the device is not active. If you need additional details about the performance of the device, you may have to drill down deeper and gather netflow statistics or information via SNMP.
All of the devices on our network have configuration files. These may be files that we can easily see and list on the screen. Or they may be stored in different places on the switch, the router, or the firewall. Many of these devices also allow us to back up the configuration files and restore those configurations if we need to update or make any changes to the device. These configuration files might also be specific to a particular version that’s running on that device.
So if we have an older configuration file and a newer version of software running on that switch or router, we may not be able to load that older configuration file back onto that device. In those situations, we may need to downgrade that device back to that previous version, just so we can now install that older configuration file back on that switch or that router. This means we not only need to collect our configuration files and store those for future reference, but we also need to keep our firmware or previous software versions just in case we need to go back to that previous config.
If we have multiples of these devices, we can also compare and contrast the changes between those configuration files on all of those different devices. For example, you might have 10 identical web servers, and each of those web servers should have a very similar configuration. There may be a way to use the configuration files to be able to verify the configuration across all of those.
Many organizations will also perform ongoing monitoring of those configuration files, and there will be an alert or an alarm if anyone makes any change to that configuration without prior approval. This is usually part of an overall management system that is integrated with the change control within your organization. So you may have software that’s monitoring the configuration files and a larger process that is involved with changing and modifying those configuration files in a very standardized way.