[Snort-users] snort behind TAP & asynchronous_link

Holger.Woehle at ...2701... Holger.Woehle at ...2701...
Thu Aug 15 07:26:04 EDT 2002


>I think the problem is that you are only seeing one side of the
>conversation. Copper taps generally split the taped data into send and
>receive wires, So Tap A is one direction of the traffic and Tap B is the
>other.
>
>You can feed tap A and tap B into a switch that has port monitoring
>capabilities so you can recombine the traffic from Tap A and Tap B into a
>single cable. Or you can use a computer with 2 nic cards and perform channel
>bonding between the nic cards.
>
>Hope this helps
>
>Ian

You are right about the function of the Tap splitting the traffic.
If i use bond0 with two devices on both Tap-ends everything works...
So, why wouldn't i do that ?
I have to observe a redundant ethernet infrastructur. For this reason i have to
use bond0
to merge Tap A from two Taps. That means 2 x 100mbit, wich is a lot of traffic,
but it works!
If i try to catch the answers at Tap B, i have a bonding interface with 4 x
100mbit...
only to be able to make stream assembly work. I think thats to high the price.
But let us talk about that opinion:
I don't need any rules observing the server answers.
Does the backwarding traffic stresses snort heavily even without rules ?
I think yes : Snort has to examine every packet so i think i would have a lot of
paket losses, wouldn't i ?

First i go for the asynchronous_link, but as a backup i test the 4 x bonding
case.
In the moment i have strange problems with a quad-ethernet d-link card, but
that's another mailing list.

cu
holgi









More information about the Snort-users mailing list