Hi Terry please find zbalance_ipc+tcpdump examples here: https://github.com/ntop/PF_RING/blob/dev/userland/examples_zc/README.examples <https://github.com/ntop/PF_RING/blob/dev/userland/examples_zc/README.examples>
Alfredo > On 2 Oct 2017, at 22:58, Terry <[email protected]> wrote: > > 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 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] >> <mailto:[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] <mailto:[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 >>> <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
