Active network monitoring (a network monitoring technique) is real-time testing, performed by software agents or hardware sensors, on network infrastructure and against applications to verify that the network (or applications) are available and performing well. Active tests report real-time data such as end-to-end reachability, packet loss, jitter, bandwidth, and HTTP response time. One of the most common tests run by active network monitoring tools is the ping command, which verifies round trip time to a remote host as well as packet loss.
$ ping www.google.com PING www.google.com (74.125.29.105): 56 data bytes 64 bytes from 74.125.29.105: icmp_seq=0 ttl=46 time=69.206 ms 64 bytes from 74.125.29.105: icmp_seq=1 ttl=46 time=208.630 ms 64 bytes from 74.125.29.105: icmp_seq=2 ttl=46 time=62.758 ms 64 bytes from 74.125.29.105: icmp_seq=3 ttl=46 time=307.980 ms 64 bytes from 74.125.29.105: icmp_seq=4 ttl=46 time=112.118 ms --- www.google.com ping statistics --- 5 packets transmitted, 5 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 62.758/152.138/307.980/93.751 ms $
Benefits of Active Network Monitoring
One of the benefits of this technique is that it reports real-time information on network availability and performance. In a previous blog post, I covered the Cisco IP SLA network performance monitoring suite. If you are a network engineer familiar with this technology, you may find active network monitoring to be very similar. In fact, as stated in the Cisco IP SLA Configuration Guide, “IP SLAs uses active traffic monitoring—the generation of traffic in a continuous, reliable, and predictable manner—for measuring network performance”.
Active network monitoring is indeed very effective for quickly detecting network and application problems; it tests the actual network routes and applications with real traffic (instead of monitoring individual devices in a network, or components of an application) to infer network and application availability and performance for the end-users based on their overall status. This is one of the reasons why NetBeez is primarily based on active tests: to quickly detect network problems before the users detect them.
The following screenshot from the NetBeez dashboard shows a ping test to www.google.com run by a Ethernet active monitoring sensors.
Test Interval and Detection Time
The network manager decides how quickly to detect problem by setting the frequency of the network and application tests. For example, the table below shows that if we run a ping test every five seconds, and declare a remote network unreachable after five consecutive tests fail, we’ll have detected connectivity issues within twenty-five seconds. That’s a very short detection time when compared to the five-minute interval that most SNMP systems are configured by default.
| Test | Primary Metric(s) | Test interval* | Detection time* |
| PING | RTT, Packet loss | 5 seconds | 25 seconds |
| DNS | DNS lookup time | 30 seconds | 2 minutes 30 seconds |
| HTTP | HTTP GET time | 60 seconds | 5 minutes |
| Traceroute | Hop count, RTT, MTU | 120 seconds | n/a |
| iPerf | TCP/UDP/Multicast throughput | User-defined | n/a |
| VoIP | Jitter, packet loss, MOS | User-defined | n/a |
| Speedtest | Download/Upload throughput | User-defined | n/a |
The above table reports the active tests that NetBeez runs, in real-time, end-to-end.
To conclude, network engineers and administrators that are interested in proactively detecting network and application problems on large, complex enterprise networks, should implement active monitoring against web and cloud applications. If you are evaluating such a tool, request a demo of NetBeez. It’s easy to deploy, simple to use, and highly scalable.
