At present network traffic is monitored locally, using SPAN ports and/or inline with taps. SPAN ports tend to drop packets at random when the switch is loaded. What's more, many shops don't have enough available SPAN ports for even minimal monitoring coverage. Inline network taps are a direct way to capture traffic but they have traditionally lacked the selective aggregation, filtering capabilities, distributed management features and range of port densities necessary to make them anything more than a stand-alone solution.
With no way to get a centralized view over a LAN down to Layer 2, service-level agreements for real-time applications such as video and financial trades cannot be assured and enterprises cannot comply with regulations requiring a true and complete copy of transactions and lawful intercepts. This situation is exacerbated by the need to use existing gigabit monitoring infrastructure even as 10-gigabit switches continue to be rolled out at the core and access layers.
Much of the focus on network monitoring has been at the application layer. In part this is because monitoring equipment has become more capable and specialized, able to identify more events and correlate diverse data sets into actionable reports. But the equipment does not provide visibility into all parts of the network from a central location, leaving segments of the network unmonitored and the monitoring equipment's capacity either underutilized or oversubscribed.
Distributed traffic capture involves deploying traffic capture devices across the network as a unified system, linking network infrastructure to the analytical equipment. In this way traffic capture closely meshes with network topology, collecting a copy of traffic at any point and sending it in real time to centralized monitoring tools.
In large, distributed Ethernet networks, monitoring equipment sits atop an IP infrastructure oriented to a best-effort delivery. With the rapidly increasing presence of time-sensitive high-bandwidth traffic running at 10-gigabit over IP, network professionals have begun to apply traffic engineering principles to network design. One example is the adoption of traffic management protocols, such as MPLS, widely used as the basis for VPNs.
Likewise, engineers are beginning to take a traffic engineering approach to network monitoring: employing distributed traffic capture as a system matched to the network. The capabilities of the traffic capture devices are determined by the speeds, nature of traffic and their location in the network's core, distribution, access and/or gateway layers and, if applicable, related telecom architectures.
A traffic capture system is optimally comprised of two layers: 1) inline or SPAN port capture-aggregation, and 2) aggregation-distribution to the monitoring equipment. This design enables flexibility in terms of where the capture points are located and provides for scalability. The system collects the copied traffic at a few or hundreds of capture points anywhere on the network, grooms it and then forwards it to centralized analytical and monitoring devices.
Grooming operations occur in real time and solely in hardware, typically resulting in an average propagation delay of two packets or less. The copied traffic may be selectively aggregated, filtered on Layers 2 to 4 depending on the types of analytical devices to which it is going, load balanced to ensure that the monitoring equipment is not oversubscribed, and sent to a centralized location.
A key element to the traffic capture system's scalability is an interface, preferably graphical, that lets users create filter settings and securely manage all of the capture devices from one location, either at one traffic capture device or remotely.
The design of a distributed traffic capture system is based on the requirements of the monitoring devices. Commonly used monitoring equipment are: intrusion detection/prevention systems, performance monitors, service assurance tools and data recording devices. Each of these devices may need to see only certain slices of traffic -- such as HTTP, voice, video, signaling, virtual LAN data and/or payload -- and from only selected network segments or the entire network.
Design criteria that network engineers should take into account include:
* The number of networks being monitored.
* The media is copper, fiber or mixed.
* The location and number of capture points, whether SPAN ports or inline.
* The speed for each link associated with a capture point.
* The type and volume of traffic to be monitored.
* The performance capability/bandwidth of the analytical equipment and its location.
* Available rack space.
The most efficient design process for a distributed traffic capture system usually follows these steps:
1) Determine the traffic the monitoring tools must see.
2) Identify the traffic capture points.
3) Map the capture points to the best combination of port densities, speeds and grooming capabilities of the traffic capture device.
4) At the traffic capture distribution layer, configure the monitor output ports to send traffic customized for reach monitoring device.
Implementation criteria for traffic capture devices are generally straightforward. One that's not is how the device handles gigabit failover on copper media. Network engineers designing a traffic capture system should ensure that the device will fail over quickly enough, typically less than 100 milliseconds, so as not to cause link loss.
Traffic capture devices are typically set and forgotten. But if you think that yours may one day be redeployed, look for maximum flexibility, such as configurable I/O ports, inline as well as SPAN capture, and the ability to download firmware delivering additional functionality. Further, the system should allow the addition of capture points and analytics interfaces as needed.
The key to effective monitoring is being able to scale a growing number of analytics systems across a growing number of capture points. The emergence of today's traffic capture devices with onboard intelligence for complex traffic grooming allows their deployment as a system for total monitoring and security coverage, while at the same time reducing deployment costs and achieving a higher ROI for the analytics tools of choice.
Monitoring professionals are awakening to a new era where the old paradigm of rigid cost-laden architectures has given way to a layered and scalable system of total visibility and hardware driven efficiency.
Breslin is CEO and founder of VSS Monitoring ().