Re: Snort 1.9.1 Dual Sensor

[Bennett Todd <bet () rahul net>]

2003-03-13T04:59:49 Grime, Richard S:
> Does this mean there's a significant performance overhead to running with
> bonded interfaces?

You were responding to a post from Matt, so properly speaking your
question was addressed to him, but that sort of thing never slows me
down:-).

Taking the liberty of reading into Matt's posting my own
interpretation, I'd say, no, there's no serious performance hit to
bonded interfaces, and I can testify to that from my own experience.

Matt was talking about hypothetically modifying snort, to perform in
user-space the job that bonding driver does in the kernel.

It might be hard, or impossible, to add functionality to snort to
allow

        snort -i eth1 -i eth2

to act like bonding without degrading the performance to the point
where it's no better than

        snort -i eth1
        snort -i eth2

(although the latter can't handle cases where traffic must be
aggregated into a single snort to do the job, like network taps).

But bonding inflicts a sufficiently modest performance hit that I've
been unable to document any difference in my benchmarking --- load
and drop rates go up just the same whether its on traffic generator
feeding one interface, or two traffic generators each at have the
speed feeding a bonded pair. I've not personally benchmarked with
more than two traffic generators, but from my reading of the list
people routinely expect performance to scale up with negligible loss
in EtherChannel applications, where the common practice is to bond
four interfaces; and I can't think of any reason why it should hit a
performance knee at any realistic number of interfaces above that.

> I can see that's it's just the same as running two instances -
> [...]

No, a bonded interface is faster than two separate snorts, unless
one of the links is nearly idle (in which case it's the same), or
you have N CPUs for N snorts on a platform that does -really- good
SMP (in which case it could be slower, if the SMP support is good
enough).

And N snorts is less effective; if the packets that constitute a
session arrive on multiple interfaces, separate snorts won't see the
whole picture.

> I'm not sure which feature you're thinking shouldn't be added?

Putting words into Matt's mouth, I believe he was arguing against

        snort -i eth1 -i eth2 ...

to tell it to poll/select/whatever across multiple different pcap
sockets, aggregating the traffic in userland.

> As the interfaces are bonded, we only need to use Snort's standard
> functionality as in:
>
> snort -i bond0 ...

as I do, routinely.

May I recommend you settle the performance question yourself?
tcpreplay <URL:http://tcpreplay.sf.net/> running with capture files
(remember if you grab 'em with tcpdump to use -s 0 so it'll capture
full packets rather than just headers) from your real monitoring
points. Snort running on a sensor with multiple interfaces,
connected by crossover cables to traffic generators.

-Bennett

Attachment: _bin
Description: