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]<mailto:[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]<http://qosient.com>] Sent: Monday, July 15, 2013 3:13 PM To: Craig Merchant Cc: Argus ([email protected]<mailto:[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
