Check out our White Paper Series!
A complete library of helpful advice and survival guides for every aspect of system monitoring and control.
1-800-693-0351
Have a specific question? Ask our team of expert engineers and get a specific answer!
Sign up for the next DPS Factory Training!
Whether you're new to our equipment or you've used it for years, DPS factory training is the best way to get more from your monitoring.
Reserve Your Seat TodayA network device, such as a router, switch, or firewall, is one of the many "nuts and bolts" elements that forms any network. Without proper monitoring, these devices can become overloaded and reduce network performance.
One of the best ways to avoid network outages is to proactively monitor network devices. By monitoring devices, you can see potential problems before they cause an outage.
You also have devices that are not part of your network infrastructure but are nonetheless communicating on your network. That makes the "network devices" that can be monitored over the network, so you should also monitor them.
Good monitoring of every device on your network means that you can anticipate trouble with the function of that device before it happens. Nothing in your network is there for show. Everything has a function, and it's your job to protect that.
There are many different ways to monitor network devices. Let's review some of the most popular methods and talk about your options for software and hardware network device monitoring systems.
One of the most basic and popular methods for network device monitoring is to use ICMP pings. Most network devices have the ability to respond to an ICMP echo request, also known as a "ping."
You can use this functionality to verify that a network device is up and running. If you don't receive a response, you know that the device is down.
You can also use ICMP pings to get information about network latency. By sending a series of ICMP echo requests and measuring the time it takes to receive a reply, you can get an idea of how long it takes for data to travel from one network device to another. This can reveal the state of unmanaged network devices indirectly, which makes it an important clue to you overall network health.
Unfortunately, ICMP pings don't provide a lot of detailed information about network devices. They can tell you if a device is up or down, and they can give you some insight into network latency, but that's about it.
If you want to get more detailed information about network devices, you'll need to use other methods.
Simple Network Management Protocol (SNMP) is a network protocol that allows network devices to share information about their current state.
You can use SNMP to get information from network devices, such as the amount of traffic flowing through a router or the number of errors on a switch port.
You can also use SNMP to set configuration parameters on network devices. For example, you could use SNMP to change the password on a router or to enable or disable a switch port.
SNMP is very popular for network device monitoring because it provides a lot of detailed information about network devices. However, it has some drawbacks.
First, SNMP uses UDP, which is a less reliable network protocol than TCP. This can cause problems if the network is congested (which is precisely when you need your device monitoring to work) or if there is a lot of network noise.
Second, SNMP is an asynchronous "push" protocol with respect to its standard "trap" message type. This means that you have to actively request information from network devices to effectively monitor them.
This can be a problem if you want to collect information from a large number of network devices, because you have to make a separate request for each device. Fortunately, for the purposes of network device monitoring, you only have to make one "GET request" per device to see if you receive a "GETresponse" message in return. You can think of this as a kind of "SNMP pinging", even though it has nothing to do with ICMP.
Lastly, not every network-enabled device was engineered to support the standard SNMP communication protocol. If that's the case, you obviously can't use SNMP GET messages to monitor that device.
Another popular method for network device monitoring is TCP connect scans. With this method, you try to establish a TCP connection with each network port on each network device.
This can give you a lot of information about network devices, because each network port has a different function. For example, a network device might have a web server running on port 80, and if you can establish a TCP connection to that port, you know that the web server is up and running.
TCP connect scans have some advantages over SNMP GET requests. First, they're less likely to generate network traffic, because you're only sending TCP SYN packets, which are small.
Second, they're more reliable than SNMP GET requests, because TCP is a more reliable network protocol than UDP.
However, TCP connect scans have one big disadvantage: they're very slow. It can take a long time to scan all the ports on all the network devices in a large network.
If you want to get started with network device monitoring, ICMP pings and SNMP GET requests are good place to start. If you want to get more information about network devices, TCP connect scans can give you a lot of detail, but they're very slow.
With that in mind, focusing on pings and SNMP GETs can be your best first step. They're relatively easy to set up, and many devices support them. A lot of the gear you're monitoring will respond to SNMP messages, and ICMP pinging is almost universal (just check for security settings that can suppress ping responses).
As opposed to much of the physical-layer and environmental monitoring that my clients do with RTUs, what we're talking about here is very much network-layer monitoring. We're not talking about temperature monitoring, water leakage, or door monitoring. Instead, we simply want to know what devices are active in the network and the overall congestion levels in the network itself.
For that reason, many people doing their initial research start thinking about software-only solutions that run on a standard server. Those solutions exist for purchase from many different vendors, and they're tremendously better than blindly hoping for good network performance.
Don't forget, however, that you have increasingly great options to bring dedicated monitoring appliances like RTUs into play here to create a superior monitoring system.
For one simple example, consider that you can ping every device on your network from a central server. You could also, however, use a device at the network edge to ping nearby (in network terms, and likely also physically nearby) devices. This provides different information than a centralized ping, because the ping and response traverse much less of the network.
If you've been a network administrator for more than about... oh... 38 seconds, you're also probably excited about the idea that the network traffic for simple monitoring won't congest the entire network.
When you use an RTU to ping nearby devices, that's exactly what happens. You get a more specific result about your network segments, and you get it with much more traffic efficiency.
If we extend this concept to SNMP GET "pinging", all of the above applies. You can absolutely do this with one central SNMP manager, but a network of RTUs acting as regional managers throughout your network can do it better.
I hate getting to the end of a guide without any signposts for where to go next. I would never do that to you.
If you want to get a better feel for what hardware-based network device monitors look like, take a look at our NetGuardian RTUs. Virtually all of them support "Ping Alarms" (automated pinging with failure alerts), and many now support "SNMP GET Polling" (the same concept, but with SNMP instead of ICMP pings).
Please don't, however, get overwhelmed by all the NetGuardian models available. For many of my clients, DPS is a semi-custom shop. We'll adjust capacity, physical mounting style and form factor, and network protocols to suit your requirements. As a result, we have a big catalog with overlapping devices. In all likelihood, one of those off-the-shelf designs will be great for your project.
Just give me a call at 1-800-693-0351 to discuss your project. We can talk about network device monitoring, but also everything else you'll be able to monitor with NetGuardians and, if needed, our central master station called T/Mon. You can also always email me at sales@dpstele.com
Andrew Erickson
Andrew Erickson is an Application Engineer at DPS Telecom, a manufacturer of semi-custom remote alarm monitoring systems based in Fresno, California. Andrew brings more than 17 years of experience building site monitoring solutions, developing intuitive user interfaces and documentation, and opt...