If it's in kilobytes it must be total buffer size (= packet_size * number_of_packets). I had heard of similar problems but on the receiving length - the UDP buffer size has to be big enough to accomodate lots of incoming packets (in case the kernel has better things to do than process them). An alternative solution might be to increase fprobe's priority with nice so it gets more CPU time...
On Thu, Dec 10, 2015 at 10:46 PM, Leandro <[email protected]> wrote: > Adrian: > B is : > -B <kilobytes> Kernel capture buffer size [0] > In my opinion, it means that fprobe will take: > B packets of S length before processing and sending as netflow data. > If it is ok , it is the packets queue length. > Also you have the "q" flag , witch in my opinion is the queue length for a > traffic/data burst. > > > It would be great if someone can clarify this. > Regards, > Leo. > > > > > On 10/12/15 16:53, Adrian Popa wrote: > > Glad to hear you sorted it out! What does -B stand for (I haven't used > fprobe)? UDP buffer? > > On Thu, Dec 10, 2015 at 4:32 PM, Leandro <[email protected]> wrote: > >> Adrian, finally I got it working properly. >> Reading the man page for fprobe I founded the following: >> >> Reasonable configuration to run under heavy load: >> fprobe -fip -B4096 -r2 -q10000 -t10000:10000000 localhost:2055 >> >> After applying the B , r and q parameters I got the complete traffic >> shape. >> Also at fprobe server , any performance parameter showed some increment >> so I think it is working >> >> Thanks for your advice. >> Leandro. >> >> >> On 05/12/15 04:28, Adrian Popa wrote: >> >> Hmm, if the source machine doesn't have enough resources to export the >> flows, you should see things like - a core being used 100% by fprobe or udp >> packets being dropped because of too small buffers in the output of netstat >> -s (check on both source and destination). You could use iptables to count >> packets leaving the source vs packets arriving at the destination to rule >> out network drops in between with something like >> iptables -A OUTPUT -m udp --dport 9995 -j ACCEPT >> iptables -A INPUT -m udp --dport 9995 -j ACCEPT >> And check stats with >> iptables -l -n -v >> >> But it's difficult to troubleshoot... >> On 4 Dec 2015 15:09, "Leandro" <[email protected]> wrote: >> >>> Adrian , thanks for your response. >>> About sampling ... Im not sure what is it but im running the fprobe just >>> with the line: >>> >>> /usr/local/sbin/fprobe -i eth3 -fip -n7 172.24.3.12:9995 >>> >>> Which in a case o a traffic bellow than 1gbps works great. >>> In my case the message you are describing "Sequence errors or bad >>> packets" >>> Apears many times in the collector log file, so there is some problem >>> ,but; >>> How can I confirm if the problem is on the nfcapd or the fprobe side ? >>> Can I modify on something on any side to properly export more than 1.4Gbps >>> ? >>> Both machine where they are running are very powerfull machines. >>> >>> I can provide more info >>> Thanks in advance!!! >>> Leo. >>> >>> >>> On 04/12/15 04:37, Adrian Popa wrote: >>> >>> If you're using sampling you should see differences between netflow >>> traffic and real traffic. If not, check that: >>> >>> 1. you're not losing UDP packets - if you lose packets you should see >>> something like this: >>> Dec 4 09:35:00 localhost nfcapd[13268]: Ident: 'MyRouter' Flows: 11763, >>> Packets: 930064, Bytes: 731126982, Sequence Errors: 0, Bad Packets: 0 >>> >>> Sequence errors or bad packets will indicate something's wrong on the >>> network side. >>> >>> 2. your router has enough capacity (TCAM memory) to export all the flows >>> If you get errors in your router's log that TCAM memory is nearly >>> exhausted, then the router will stop producing flows for a while and you >>> get those drops at higher traffic. >>> >>> >>> On Thu, Dec 3, 2015 at 9:48 PM, Leandro < <[email protected]> >>> [email protected]> wrote: >>> >>>> Hi , guys. >>>> It is very strange but , my nfsen is showing a maximun traffic value of >>>> 1.2 gbps when the traffic showed on cacti is 2gbps(also meassured on the >>>> router). >>>> Traffic shape is ok , minimun values mathes on both tools. >>>> Any ideas about it ? Is there something to tune on fprobe, nfcapd or >>>> nfsen ? >>>> >>>> Regards, >>>> Leandro. >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Go from Idea to Many App Stores Faster with Intel(R) XDK >>>> Give your users amazing mobile app experiences with Intel(R) XDK. >>>> Use one codebase in this all-in-one HTML5 development environment. >>>> Design, debug & build mobile apps & 2D/3D high-impact games for >>>> multiple OSs. >>>> http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140 >>>> _______________________________________________ >>>> Nfsen-discuss mailing list >>>> [email protected] >>>> https://lists.sourceforge.net/lists/listinfo/nfsen-discuss >>>> >>> >>> >>> >> > >
------------------------------------------------------------------------------
_______________________________________________ Nfsen-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/nfsen-discuss
