Hi Terry dummy 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 Terry > ZC 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 that > one 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, and > let 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] >> <mailto:[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] <mailto:[email protected]> >> http://listgateway.unipi.it/mailman/listinfo/ntop-misc > > >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Ntop-misc mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop-misc
