Monitoring your network interfaces can help you identify the first signs of trouble. In this video, you’ll learn about interface monitoring and some of the important metrics to examine on your network interfaces.
<< Previous: Utilization StatisticsNext: Configuration Management >>
As network professionals, we want to be sure that the devices that are connected to our network are performing optimally. So it’s going to be important that we monitor the interfaces to make sure that everything is working exactly as we expect. We can usually start to find small problems occurring if we’re monitoring our interfaces. Maybe we’re seeing a number of errors over time. Maybe we’ve got a bad cable or we’ve got a bad interface. And we can plan to swap those out to see if we can resolve what those errors might be. Sometimes you can catch these problems before anybody even knows there was an issue.
Of course, it’s not always as straightforward as that. Sometimes you’ll see error messages, or things that will appear on an interface, and they are being caused by something else occurring on the network. So it’s important to start doing research when you see these errors so that you can really define exactly why that error is occurring and where it’s coming from.
There’s a number of places you can go to get interface statistics. One is the operating system of the device itself. Almost all operating systems are collecting statistics and information on the interfaces. And you should be able to gather a lot right from the device.
Some of these devices are SNMP enabled, which means that we can access it through the Simple Network Management Protocol. So we could be at a central station and gather network interface statistics for every device on our network that supports SNMP. If a device is supporting SNMP, there’s a good chance that it’s gathering those interface statistics using a Management Information Base, or a MIB, called MIB-II. MIB-II is a very common MIB. If it supports SNMP, there’s a very good chance that it also supports MIB-II.
There are a number of statistics that are important to monitor on an interface. Let’s look at a few of these.
And let’s start with the link status. If a link is up and operational, that’s important to know. It’s also important to know if a link is down, if the link is off. And it’s also important to know if the link is alternating between being up and being down. That might indicate a problem, as well. The problem might be with the cable. It might be associated with the interfaces themselves. Or it may be that someone is making a change to the network outside the scope of the normal change control.
When you query an interface, you’ll often get a rundown of all of the possible errors that may be occurring on that interface, and how many times they’ve occurred. So you can see things like CRC errors, runts, giants, and other malformed packets that may be coming through. This may indicate that you have a problem with cabling. Or it may indicate that bad information was being sent into the interface, or the interface is not able to receive the information properly.
Of course, it’s useful to know just how much this interface is being used. And we may be able to correlate some of the error statistics with how much traffic is coming through. If not much traffic is being utilized, than we might not see many errors. But you may find, when there are very large file transfers, that the error rate increases. So you can start making some correlations between how much the network is being used and how many errors you happen to be seeing.
Another important metric is how well this device is handling the packets. Occasionally, a device will be operational. The cable is fine. The interfaces are working properly. The hardware is in top working condition. But the device tends to drop packets anyway. And you’ll see a counter that shows how many packets have been dropped, or how many packets have been discarded. The system was not able to process that packet. Maybe there was high utilization. Maybe it didn’t have the memory or other resources in that device to be able to properly handle the influx of traffic. And instead of being able to pull that in and process it, it simply drops it onto the floor. That might give you some insight into how well a device is performing, and whether it might be a good idea to upgrade or replace that device.
Another important interface log entry might be something like the interface resetting. It gets to a point where it’s trying to send information. Perhaps buffers fill up. And it may be part of the operating system or the operation of that device to completely reset the interface to try to get things going again. If the interface has a hardware problem, or there’s some other type of issue with the software, you may find that the interface reset doesn’t help. But occasionally, that’s the only choice you have, is to turn that interface off and back on again to see if it clears up the problem.
In the days where 100-megabit ethernet was the fastest speed we had, the auto negotiation process didn’t always work properly. Then, you’d have one side that would come on to the link at full duplex, and the other side would negotiate at half duplex, and you’d end up having errors between the two whenever you tried to transfer data. To get the right perspective of speed and duplex, you would need to look at the interface on both sides, and make sure that those values are exactly the same.