By Dan Pocek

Proactive traffic monitoring becomes more complicated in a high-capacity, converged network for a number of reasons. First, converged networks are exacerbating what I will call the fire hose problem, or the fact that tools are trying to monitor a specific traffic type that is traversing the network in an increasing larger pipe of mixed voice, video, and data traffic. This is like filling a water glass with a fire hose as the traffic arrives at the monitoring tool and “overwhelms” it; as data rates increase, this problem grows exponentially. Second, network tunneling, or the encapsulation of data within public and private network infrastructure, has become widespread in today’s corporate networks, driven by a need to securely transport sensitive data and leverage public networks. This is not welcome news for monitoring tools such as protocol analyzers and transaction recording solutions that are already struggling to keep up with converged network data flows. These tools now must also find a way to access and process complicated tunnels. This article looks at these two issues in greater detail and evaluates the solutions that attempt to address them.

Converged networks are carrying a combination of voice, video, and data at increasingly higher speeds. This presents a problem for monitoring tools that are designed to monitor a specific application, service, or suite of services since most of these tools only need access to a small fraction of the data in a high-speed line. The process of isolating the service of interest for each tool can exhaust the resources of the monitoring equipment, leaving fewer resources for higher-level processing. A VoIP monitoring tool, for example, must first find and target the VoIP traffic within a large converged pipe before it can begin to measure Quality of Service and other metrics and key performance indicators that provide valuable information about how the service is performing.

solves the fire hose problem. Using SPAN ports on a router provides a fairly straightforward approach to providing access and can even offer some level of traffic aggregation, assuming the router platform is lightly utilized. However, this approach is not reliable since these processing functions are contingent upon the amount of resources not being utilized for other, higher-priority router tasks. Furthermore, the primary function of a router is not to provide monitoring access, so burning SPAN ports on these platforms for this purpose can quickly become cost-prohibitive. Optical TAPs, on the other hand, eliminate the cost issues related to SPAN ports, but have their own restrictions. Most importantly, they do not have