Hi Craig yes, libpcap over dna cluster queue provides pcap_stats() support.
Alfredo On Jul 18, 2013, at 9:01 PM, Craig Merchant <[email protected]> wrote: > Alfredo, > > I ran both pfcount –i dnacluster:10@28 (the queue argus monitors) and pfcount > –i dna0 (when pfdnacluster_masterr wasn’t running). Both of them showed a > 0.1% packet loss. > > What about this question that Carter had: > > Does the pfdnacluster_master queue provide standard pcap_stats() ? > We should be able to look at the MARs, which will tell us how > many packets the interface dropped. > > I’m not familiar with what pcap_stats() are… > > Thanks. > > Craig > > From: [email protected] > [mailto:[email protected]] On Behalf Of Alfredo > Cardigliano > Sent: Thursday, July 18, 2013 12:44 AM > To: [email protected] > Subject: Re: [Ntop-misc] FW: [ARGUS] Direction and IP/TCP timeout settings > > Hi Craig > what do you mean with "Pfcount says that the queue that argus is running on > is only dropping 0.1% of packets"? You should look at the stats on the queue > argus is using. > Select/poll are not supported by the cluster as we experienced that using > usleep behaves better than the poll implementation in this case. > > Alfredo > > On Jul 16, 2013, at 1:51 AM, Craig Merchant <[email protected]> wrote: > > > I’m trying to troubleshoot some issues with the argus netflow tool running on > top of pfdnacluster_master. Pfcount says that the queue that argus is > running on is only dropping 0.1% of packets, yet argus can’t figure out the > direction of about 60% of the flows. That means for some reason it isn’t > seeing the SYN and SYNACK of a lot of flows. > > The argus developer had a couple questions about the pfdnacluster_master that > I can’t answer… They are below. > > Thanks. > > Craig > > From: Carter Bullard [mailto:[email protected]] > Sent: Monday, July 15, 2013 3:13 PM > To: Craig Merchant > Cc: Argus ([email protected]) > Subject: Re: [ARGUS] Direction and IP/TCP timeout settings > > Hey Craig, > If radium doesn't keep, the argi will drop the connections, > so unless you see radium losing its connection and > then re-establishing, I don't think its radium. We can measure > all of this, so its not going to be hard to track down, I don't > think. > > If argus is generating the same number of flows, then its probably > seeing the same traffic. So, it seems that we are not getting all > the packets, and it doesn't appear to be due to argus running > out of cycles. Are we running out of memory? How does vmstat look > on the machine ?? Not swapping out ? > > To understand this issue, I need to know if the pfdnacluster_master queue > is a selectable packet source, or not. We want to use select() to get > packets, so that we can leverage the select()s timeout feature to wake > us up, periodically, so we can do some background maintenance, like queue > timeouts, etc… > > When we can't select(), we have to poll the interface, and if > there isn't anything there, we could fall into a nanosleep() call, > waiting for packets. That may be a very bad thing, causing us to > could be lose packets. > > Does the pfdnacluster_master queue provide standard pcap_stats() ? > We should be able to look at the MARs, which will tell us how > many packets the interface dropped. > > Not sure that I understand the problem with multiple argus processes? > You can run 24 copies of argus, and have radium connect to them > all to recreate the single argus data stream, if that is something > you would like to do. > > Lets focus on this new interface. It could be we have to do something > special to get the best performance out of it. > > Carter > > > > _______________________________________________ > 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
