Common Interface to Packets
Recently a blog reader asked me an interesting question. He wanted to know if it would be possible to replace the variety of network traffic inspection and analysis products with a single box running multiple applications. He was interested in some sort of common interface to packets that could perform the collection function and make traffic available to other products.There are several ways to look at this issue. First, one can do that already using a commodity hardware platform. It is possible to run multiple traffic inspection applications against a single interface now, but one has to be careful as the number of applications increases. We use this approach with Sguil, where Snort listens to generate alerts, SANCP listens to create session records, Daemonlogger listens to log full content data, PADS listens to generate host records, and so on.
Second, one could buy a fairly open packet capture box and create virtual interfaces which provide a traffic stream to applications. Options which come to mind include Solera Networks capture appliances and Endace Ninja platforms. These typically run Linux and act as a high-end option for packet capture.
Third, one could think of a network tap (like a Net Optics regeneration tap or a Gigamon GigaVUE as that common interface to packet data. The tap collects traffic and then sends it to multiple products. This is a very common scenario for a simple reason: few vendors are willing to accept the decisions made by another vendor regarding packet capture. Everyone wants to collect data themselves, using their own NICs, or drivers, or libraries. That's perfectly understandable but it makes it tough for users who end up managing so many separate boxes.
What do you think?
Comments
-- WXS
1) Scalability: Up to 10 Gigamons can be stacked (for a total of 202 ports (any port can be tool or network) functioning in one logical unit) via 10 gigabit Infiniband connectors. There are 8 gigabit copper connectors in the base unit. The unit is expanded using GigaPORT and GigaTap modules. An additional 3 GigaPORT modules can be added to each chassis (this provides an additional 12 ports (are UTP and SFP)
2) Nearly limitless possibilities when it comes to aggregation (many to any), multicasting (any to many), and filtering (vlans, networks, protocols, etc.).
3) Support for 10 Gigabit Ethernet.
I keep running into the situation where all the existing monitor ports are used up. Having the Gigamon basically eliminates this problem.
Also consider the situation where you have many taps and you need to inspect traffic on particular ports from these taps. You can pass all these taps into a Gigamon, then tell the Gigamon to filter the output (so only the traffic on ports you want to see is sent) and send it to one tool port to inspect with one monitoring box.
I've deployed several recently and deploying a couple more in the near future.
Note that said tools would probably need modification to do this.
Several vendors have expressed interest, can't say much more at this time. :)