WavebreakmediaMicro - Fotolia
What functionality should be included in automated network testing, and are enterprises ready to adopt the technology?
For some organizations, automated network testing may not be necessary. After all, many network management tools can reveal a network's state and identify network problems. Unfortunately, network management alerts are often overlooked or acknowledged without fixing the underlying problem. Automated network testing can help find a variety of problems without requiring manual processes.
Network testing can verify physical connectivity, routing protocol functionality, path performance and more. It checks if the network is connected, configured and operating as desired. Automated testing picks up where network management stops and incorporates more active processes to identify problems that may be difficult to find with a network management system.
Organizations that are serious about application reliability are adopting network testing methodologies, so they know for sure what will happen when each network component fails.
What should be tested to identify network problems?
All aspects of the network need to be tested, starting with physical connectivity, such as verifying device A is properly connected to device B. The routing and switching protocol data should match the expected next-hop device and metric range.
Network resilience needs to be validated through a redundancy check. In this step, some questions to ask include the following:
- Are the necessary links and devices able to handle a single failure?
- Does the network handle a failure fast enough for the desired application performance?
End-to-end performance should also be validated. While network monitoring based on Simple Network Management Protocol can detect interface errors and drops that indicate congestion, active testing with synthetic traffic is needed for end-to-end validation of latency, jitter and packet loss. The synthetic testing tool should be smart enough to not overload paths.
End-to-end testing can also identify incorrect firewall configurations and inconsistent quality-of-service operations. Ideal end-to-end testing would incorporate failure testing to verify the functionality of backup paths. Some products can show alternate paths, but real packet flows are required to verify the network will deliver them.
Another approach to active testing is to disable links and devices to simulate failures. Gartner analyst Andrew Lerner suggested a network Chaos Monkey to ensure network failures won't affect applications. This is a great idea, but I'm not aware of any service that does it.
Potential issues with automated network testing
The growing use of virtual topologies -- such as virtual extensible LAN, network functions virtualization and cloud-based systems -- expands the scope of automated network testing. Yet, the test needs to identify cases where packets take a path that bypasses a load balancer or firewall. In this case, too much connectivity may exist and allow attackers direct access to internal systems.
New technologies, like software-defined WAN, increase the challenge of understanding the packet flow paths and adequately testing them. Many of these tests will be based on vendor proprietary tools. Look for APIs that integrate these tools with other network testing tools.
When testing your network, scaling is a big problem. Automated testing on a large network needs tools that don't require looking at individual test results on a screen. Tests that pass should be recorded, so variations in results can be checked or baselined. Failures should be reported and acted upon in a timely manner.
Of course, some things can't be tested, such as circuits shared with other organizations. The typical example is the shared-fiber link that carries primary and backup links in shared infrastructure. In these cases, you have to pay the carrier additional money to provide disparate paths.
Network testing tools run the gamut
Many classes of network testing tools are available, including active-path analysis tools, such as AppNeta, NetBeez and NetNORAD. Information from network-source-of-truth databases, like NetBox and NSoT, can verify connectivity and address assignment.
Other tools sit on the fence between network management and network testing. Veriflow, for example, uses configurations and network state information to verify connectivity requirements the network staff creates.
In addition, big data analysis is starting to make inroads into network operation. The best-known example is Cisco's Tetration, which collects and analyzes massive volumes of data. While it isn't an active-testing tool, Tetration can identify application performance problems and packet flows that should not be permitted. It could be interesting to use in combination with an active-path analysis tool.
In the automation space, several open source projects exist, such as Ansible, Salt, Netmiko and NAPALM. Other vendors, like Gluware and Apstra, are creating network automation tools that do not require the network staff to learn how to program.
As usual, a combination of the above tools is required for full coverage.
Gauging enterprise adoption of automated network testing
Fortunately, it's easy to get started with basic automated network testing. Tools like AppNeta and NetBeez are easy to deploy and provide useful end-to-end information. But checking network intent is more challenging, because it requires creating a source-of-truth database, and additional work is needed to verify network state information against the database. NetBox and NSoT are a start down this road.
Are enterprises ready to embrace automated network testing? It depends on the organization. I know large financial firms that have been doing failure testing for many years by starting with manual processes.
We're in the early adopter stage of this transformation. We will see more enterprises using automated network testing, as network automation gains wider acceptance.