Voice & Video Need Path-Based Network Testing
Part of my consulting practice focuses on the network design needed to properly support voice and video conferencing (real-time) traffic on an IP network. One of the big disconnects today is on the testing side. Many enterprises are not using the right kind of test tools to find and fix problems in real-time traffic support.
Path-based testing is a methodology whereby the test tool is able to test the complete network path used by a voice or video stream. These tools often have an appliance or an agent in the device that can generate synthetic traffic, and flow that traffic across the network to another similar device. This flow of traffic across the network can then be tested for the key characteristics necessary to the support of real-time traffic, including packet loss, jitter and latency.
Device-based test tools look at the behavior of individual devices in the network, e.g. a router, to see if any problems exist at that device. The theory is that if each device is operating correctly, then the network as a whole is operating correctly. Unfortunately, in a real-world environment, this isn’t true. Failures may be occurring in components that are untested because they are new, because they are old and don’t support that approach, because they were forgotten or because they were never included in the testing methodology in the first place. Secondly there may be design issues. For example, if a router configuration not properly classifying real-time traffic, it may be behaving exactly as it should for its configuration, but it is not doing the right thing for the overall network design.
Here is a typical example. We have a path with a duplex-mismatch between the access switch and the aggregation switch. The voice or video endpoint CDRs are indicating packet loss during a call, and the users are complaining. But the SNMP management tool shows that none of the routers or switches along the path are showing any packet drops. The network team concludes that the voice or video team doesn’t know what they are talking about.
The problem is that the packets dropped by the duplex mismatch are being dropped below the switching layer. These packets never make it to the next switch or router. The switches and routers are in fact delivering every packet they receive, but these packets are dropped on the wire and never make it into the next switch. If the SNMP tool is also monitoring CRC errors, runts and/or late collisions it may spot this problem, but the team may not know to correlate this with the voice/video loss issues.
A path-based tool will see the same packet drops experienced by the real-time traffic, and will report that path as having a problem. A good path-based tool can also show when the problem occurs, how often, and the magnitude of the issue. A really good path-based tool will then run more extensive diagnostics to help find out where along that path the problem is occurring.
Cisco IP-SLA is a path-based tool that can be used to find issues between routers in the network. Many network management systems today are implementing front-ends to take advantage of this Cisco router-based functionality. NetIQ has appliance-based tools, as does Ixia that can be used for this kind of testing. My favorite is PathView from Apparent Networks, which is able to glean details of a network path using only low bandwidth ICMP packets.
If you are having hard-to-manage quality issues with real-time traffic, take a look at using path-based testing. Most folks never go back once they get the network visibility that path-based testing provides.