Excerpts from Christopher Morrow's message of Thu Jan 28 08:55:34 -0800 2010:
On Thu, Jan 28, 2010 at 10:00 AM, Jeffrey Lyon <jeffrey.lyon@blacklotus.net> wrote:
IntruGuard is highly customizable both from the GUI and CLI with the engineer's assistance. Its the highest performance, reasonably priced box that we've tried so far.
'highest performance' == 100mbps on a 1gbps copper interface? or sessions setup/second? or remote-addresses tracked? or ?
Indeed, the only IntruGuard products I can see on their site appear to be some sort of active inspection device that support 100 and 1000 Mbit/s of traffic. Being able to task a device to inspect the data in every packet is wonderful. It allows a properly-controlled system to be able to create statistics, capture traffic, and deeply-inspect traffic. But then you're putting all that traffic through a CPU-bound chokepoint, no? I suppose one could use some sort of ECMP or link aggregation and split that traffic over several inspection devices, but at some point you're bound by the maximum number of paths (Anyone know if all vendors have a limitation of max. links per group?) If one wanted to increase the breadth of this fanout, they could add layers of routers, all fanning out n*n equal-cost paths. Add n*n inspection devices to the bottom of this tree. At todays traffic levels in larger ISPs, adding all this hardware can become expensive to maintain enough capacity. And this, I think, is the crux of why hardware-based traffic traffic inspection and filtering is, at a certain scale, far more efficient at finding abberant network behavior and squashing it at your edge (or even at your upstream's network edge). It can leverage network routing hardware you already have to measure traffic and to redirect it as necessary. Something utilizing sflow/netflow and flowspec to block or direct traffic into a scrubbing box gets you much better bang for your buck past a certain scale. Cheers, jof