Network testing definition
What is network testing, really? Since I am not very good at explaining things, I went to the Wikipedia article on software testing and found this:
“Software testing is an investigation conducted to provide stakeholders with information about the quality of the product or service under test. Software testing can also provide an objective, independent view of the software to allow the business to appreciate and understand the risks of software implementation.” – Wikipedia – Software Testing
That sounds pretty good to me. But if we take that passage and replace “software” with “network”, we get:
“Network testing is an investigation conducted to provide stakeholders with information about the quality of the product or service under test. Network testing can also provide an objective, independent view of the network to allow the business to appreciate and understand the risks of network implementation.”
Couldn’t be further from the truth. Network testing is, in the end, making sure that your network configuration works as designed. Network testing is very similar to software testing, with one exception: in contrast to software testing, network testing often has to happen in a production environment, after the configuration change was made. In fact, it is sometimes very difficult, or almost impossible, to model a complex system like a large enterprise network, or the Internet itself, in a lab environment. Thus, network testing is a MUST-HAVE step in the network implementation process.
Network testing use cases
Network testing should be run ad-hoc after a configuration change to validate that everything went well, as well as permanently, via active network monitoring, to detect network problems as soon as they happen. In the first case, here are some situations in which you want to validate your design and implementation assumptions after a configuration change:
- Circuits or site turn-up: once a new remote site or WAN link is installed, you can verify with a tool like iPerf that you get the bandwidth requested of your carrier and with ping to confirm that the circuit has no packet loss; you can also use single-board computers with iperf installed; another important thing to test in a new site, is testing what’s the maximum MTU (Maximum Transmission Unit) allowed.
- Routing policy change: due to network complexity, the larger the network, the higher the risk that a routing policy change will have unexpected consequences on your routing table. By relying on distributed monitoring agents that run continuous ping and traceroute tests in a full-mesh fashion, you can validate in real-time that a routing policy change is modifying your routing table as expected.
- Firewall rules updates: it’s always good practice to verify that a new firewall ruleset is successfully implemented, whether it should be blocking, or allowing, certain traffic. To verify a successful update of a firewall, you can use a port scanner like nmap, or perform a TCP-based ping test from the unprotected to the protected network.
- Quality of Service (QoS): applying a QoS configuration to your network is not an easy task. There are so many dependencies and little things that could go wrong, so testing is extremely important to verify that, in the end, the network is classifying, marking, and queuing traffic as designed. If you want to learn more about this use case, you can read a blog post by Matt Smith about how to validate QoS.
- Network speed tests: measuring throughput, such as download and upload speed to the Internet, is very important when estimating the end-user experience; to measure network speed, there are open-source utilities available, such as iperf (mentioned above), as well as commercial ones; check out this article that lists different open-source and commercial solutions for speedtest.
So how do we get started with network testing? One of the tools that can get you started with is already in your hands, and it’s called the terminal. Whether you are in a Unix/Linux, Windows, or Mac environment, the out-of-the-box command line interface (CLI) provides a lot of utilities that can be used to perform network validation, including ping and traceroute. (Check out the post I wrote about the top 5 Linux CLI utilities for network engineers.)
The only problem with the CLI is that it’s local and not distributed. You can telnet or SSH to different remote hosts, and remotely perform the same tests that you would locally run. However, this method doesn’t scale and it doesn’t provide historical data. For this reason, it’s important to use a distributed, GUI-driven testing solution that simultaneously runs network testing commands on many hosts and stores their results for historical review. NetBeez is a network monitoring solution that provides these features in a browser-based interface. You can run ad-hoc, or permanently, commands like ping, traceroute, and iPerf. If you want to check it out, just request a demo.