If you want to know if your business’ network and applications are operating properly, active path testing can answer that question.
What Is Active Path Testing?
Active path testing generates synthetic network traffic and measures network characteristics that are critical to application performance. The characteristics that are important vary according to the application and the underlying network protocols that it uses. Real-time voice uses User Datagram Program (UDP), while non-real-time data applications use Transmission Control Protocol (TCP) for its reliable delivery characteristics. Latency, jitter, and packet loss negatively influence the operational characteristics of UDP and TCP. Since you can configure active path testing to operate all the time, you can gain visibility into problems that occur outside normal business hours.
Active path testing works by generating streams of different types of packets to measure the above characteristics and to detect problems. Packets can be UDP, TCP, or Internet Control Message Protocol (ICMP). They can contain sequence numbers and timestamps that allow for precise measurements. Some active testing systems incorporate means of creating synthetic application transactions. I refer to these as application-level pings, in that they test application response times. All tests will have thresholds to generate alerts when problems are detected.
The monitoring and alerting nature of path testing makes it a valuable component of a comprehensive network management architecture (see my Netcraftsmen post, “
A Network Management Architecture, Part 1”). It provides visibility into actual network performance, using the current active paths. Basic planning and preparation can hold down costs and provide valuable insights into network problems.
Planning
Not surprisingly, requirements analysis is the principal component of a well-designed system. You should start by identifying the applications that need to be monitored. Which protocols and paths do those applications use? Do any specific hotspots have problems or does the entire network need to be instrumented? Make a list of paths that need to be monitored. The below list may be used as a starting guide:
- Intra-data center (i.e., east-west trafic, perhaps between application tiers)
- Data center to data center (including to cloud-based infrastructure)
- Branch to data center (including WAN to data center)
- Branch to branch (may be WAN to WAN)
- Intra-departmental
- Department to department
- Branch or data center to Internet-based service (i.e., XaaS)
- WiFi endpoint to anywhere
- Internet to call center
- SIP and PSTN calls to business sites (including call centers)
Then you will need to identify what types of tests to run over each path. You may find that basic application performance monitoring is sufficient for many paths. However, application differences may dictate different testing methodologies. Voice testing with Differentiated Services Code Point (DSCP) tracking may be needed, combined with network bandwidth and packet loss measurements that influence TCP-based applications.
The endpoints of each test may need to be identified, and putting together a matrix of endpoints and tests may be the best way to manage the collection. If there are many tests, you’ll want to investigate using automation with an API for their configuration. (This is a good time to start with automation. Hire a consultant if necessary.) A typical configuration would locate a test node at each branch and in each data center.
Don’t forget to consider monitoring of secondary paths that will be used when a primary path fails. You may need to locate test nodes in locations that facilitate these tests or create separate tests that monitor these paths.
You should be able to gain an understanding of the scale of the testing after you complete the basic planning. It’s then time to start checking with vendors or looking at open source tools (see my No Jitter post, “
Are Open Source Active Path Testing Tools Viable for You?”). Determine the classes of tests and the node types that will be needed. Virtual machines and host-based testing software can eliminate the need for physical test nodes.
Make sure that you understand the testing methodology and what it can’t do. Single-ended tests using ICMP or UDP may eliminate the need for a test node at many locations, but only measure the network in one direction. Single-ended tests typically use ICMP instead of UDP, and therefore may be handled differently by network devices. Network throughput tests may use periodic high-throughput packet streams that fill a path, causing congestion that impacts business applications. The alternative is for the test nodes to send a brief set of packets of different sizes and use the packet timings to estimate path bandwidth and occupancy.
Monitoring
Even a small network can have a large number of concurrently running tests. The testing system should generate alerts when thresholds are breached and those thresholds should be derived from network performance SLAs. The result is a system that is managed by exception (i.e., “no news is good news”). I recommend sending all alerts to an event management system that uses AI and machine learning to correlate events and reduce the number of events that must be handled.
When you’re defining thresholds for TCP-based applications, look for the ability to trigger on very small percentages of packet loss (0.001%), as discussed in my Netcraftsmen post, “
TCP Performance and the Mathis Equation.” I’m also a fan of application-level pings. These are synthetic transactions that are used to test overall application response times. Application-level pings are valuable because they measure network performance as well as an application’s internal operation and communications, including database performance. That one metric can alert you to a problem. The network-specific tests allow you to determine whether the network or the application is the cause. Many testing systems will include the ability to create synthetic transactions for websites and other common application delivery mechanisms. This is another area where it pays to learn the details about each product’s features.
Consistent QoS handling is important for smoothly functioning UC applications. The testing system should provide alerts if changes in QoS markings are detected. Many of these detailed tests will need to be double-ended, between pairs of test nodes that measure network performance in both directions.
Conclusion
Active path testing can provide great visibility into network operations. I’m a big fan of application-level pings because they provide comprehensive visibility into application performance.
I’ll discuss more on this topic early next year in a No Jitter podcast, sponsored by Spearline, about active path testing of voice and video infrastructures. In you’re interested in active path testing, you will want to tune in for a discussion on the differences in comprehensive testing of call infrastructure.
Email Beth Schultz, No Jitter editor, for details on when the podcast will run.
Join Terry at Enterprise Connect, where he’ll be leading sessions on network automation, AI’s impact on network management, delivering QoS across disparate networks and indoor cellular vs. WiFi. Check out the full program here, and register soon using the code NOJITTER to save $200 off our lowest rate!
