Hey Alfredo,
Thank you. Is there documentation on zbalance beyond what I'm finding via
Google? I'm not seeing how to use it to create the queues for Tcpdump to attach
to.
-Terry
On Friday, September 29, 2017 1:05 PM, Alfredo Cardigliano
<[email protected]> wrote:
Hi Terrydummy interfaces are usually used with Bro because this consumer is
well known to be unstable (or at least it crashes from time to time for some
reason)leaving ZC queues in an inconsistent state, preventing it from
reattaching to the queue again (in order to reattach a zbalance_ipc restart is
required).As long as tcpdump is closed correctly, there should be no problem
attaching to the queues directly. Please note dummy interfaces are slow as
traffic goes through the kernel, and you loose most of the boost provided by ZC.
Alfredo
On 29 Sep 2017, at 18:53, Terry <[email protected]> wrote:
Hey Alfredo,
Thanks, the zbalance stuff looks encouraging. How would this look in the
context of users constantly running/terminating their own instances of tcpdump?
I see the "Best practices for using Bro IDS with PF_RING ZC" article, where ZC
outputs to dummy interfaces which are then used by the application. Is this how
we would do it -- set up one-to-one mappings of ZC Interface -> Dummy
Interface, and then have users use the dummy interfaces with tcpdump rather
than the ZC interfaces directly?
-Terry
On Friday, September 29, 2017 5:12 AM, Alfredo Cardigliano
<[email protected]> wrote:
Hi TerryZC is a kernel-bypass technology, this means that the application
takes full control over the NIC in order to access the card memory in zero-copy
and maximise the performance. This implies thatone process at a time can open
an interface, thus what you are seeing with tcpdump is expected.This said,
there is a way to overcome this: you can use zbalance_ipc to open the zc
interface, andlet it distribute the traffic (fanout) to multiple applications
by means of zc queues. Please note this adds some overhead with respect to
opening the zc interface directly from the application, however you should not
notice the difference as tcpdump itself is a bottleneck.
Alfredo
On 29 Sep 2017, at 00:29, Tom J. <[email protected]> wrote:
Hello,
We're exploring using PF-RING ZC for our packet sniffers, but are looking to
get clarity on an issue before purchasing licenses.
The sniffers are standard servers running Linux, each with (16) 10G NIC ports
connected to SPAN ports on switches. Users log into the system and run TCPDUMP
to troubleshoot day-to-day connectivity issues in the environment.
As traffic levels have increased we're seeing more and more drops on the NICs,
so the thought was to implement ZC to make things better. But it looks like ZC
may limit us to one capture per NIC at any given time. Is this correct? I see
text on the product page about not being able to do standard networking
activities on a given NIC when ZC is actively running, but how about multiple
ZC-enabled TCPDUMPs at once? It doesn't seem to work for us (getting a "No such
device" error), but maybe it's something we're doing wrong.
Would appreciate any guidance.
-Terry
_______________________________________________
Ntop-misc mailing list
[email protected]
http://listgateway.unipi.it/mailman/listinfo/ntop-misc
_______________________________________________
Ntop-misc mailing list
[email protected]
http://listgateway.unipi.it/mailman/listinfo/ntop-misc
