Re: [pmacct-discussion] mysql - stamp_inserted in the past
Yes -- this is on Juniper IPFIX. Elisa: I can try to capture an 'errant' flow packet. Paolo: That seems like a good work around. Thanks. I've fought a lot with the docs, maybe they don't match my learning style. (would it be possible to try to add some internal linking/anchors in the doc?) A FAQ might be in order too based on historical mailing list Qs? Want some help trying to put this together? --Joel On Tue, Feb 25, 2014 at 9:51 AM, Paolo Lucente pa...@pmacct.net wrote: Hi Joel, On top of Elisa's answer, inline: On Mon, Feb 24, 2014 at 07:30:38PM -0800, Joel Krauska wrote: Any way to override the flow timestamps with some actual time window data? Yes, nfacctd_time_new set to true. Feel free to read docs and give it a try. Unless: a) timers are set short (ie. less than one minute imho) on the router, also for active flows!, and b) such timers are honoured for true (ie. these timestamps well in the past are only result of a timestamp reporting bug and flows are actual instead) - going this way might not give you the expected solution. Cheers, Paolo ___ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists ___ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
[pmacct-discussion] mysql - stamp_inserted in the past
I'm doing mysql rollups and seeing odd timestamps. I'm seeing occasional stamp_inserted times in the past. (some even as far back as several weeks) This is using pmacct-1.5.0rc2 snippet of relevant config: !# Tag Map to set agent_id pre_tag_map: pretag.map plugins: mysql[asn] sql_optimize_clauses: true sql_refresh_time: 300 sql_history: 5m sql_history_roundoff: m !sql_dont_try_update: true !# ASN Aggregation aggregate[asn]: tag,dst_as,as_path,peer_dst_as sql_table[asn]: traffic_by_asn sql_table_type[asn]: bgp My mysql schema. CREATE TABLE `traffic_by_asn` ( `agent_id` int(4) unsigned NOT NULL, `as_dst` int(4) unsigned NOT NULL, `as_path` char(21) NOT NULL, `peer_as_dst` int(4) unsigned NOT NULL, `packets` int(10) unsigned NOT NULL, `bytes` bigint(20) unsigned NOT NULL, `stamp_inserted` datetime NOT NULL, `stamp_updated` datetime DEFAULT NULL, PRIMARY KEY (`agent_id`,`as_dst`,`as_path`,`peer_as_dst`,`stamp_inserted`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1; I assume the timestamp might be coming from the flow data? Possibly a really old flow just now sending FINs? Any advice on what this might be? Any way to override the flow timestamps with some actual time window data? Cheers, --Joel ___ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
[pmacct-discussion] Byte Count Scaling with IPFIX?
Should I expect sampling 'correction' scaling to work with IPFIX? I have this configuration, but my byte counts appear to be off by our scaling factor. nfacctd_renormalize: true Is there a debug/log message that would identify the netflow sampling rate detected? It looks like I can hardcode with nfacctd_ext_sampling_rate or a sampling map, but I was hoping IPFIX would be transmitting the rate. Cheers, Joel ___ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
Re: [pmacct-discussion] Byte Count Scaling with IPFIX?
Maybe answering my own question... It looks like IPFIX fields 304-311 are used to identify sampling information. http://www.iana.org/assignments/ipfix/ipfix.xhtml I am not seeing these field types with debug turned on. (-d) DEBUG ( default/core ): NfV10 agent : ::: DEBUG ( default/core ): NfV10 template type : flow DEBUG ( default/core ): NfV10 template ID : 256 DEBUG ( default/core ): - DEBUG ( default/core ): |pen | field type | offset | size | DEBUG ( default/core ): | 0 | IPv4 src addr | 0 | 4 | DEBUG ( default/core ): | 0 | IPv4 dst addr | 4 | 4 | DEBUG ( default/core ): | 0 | tos| 8 | 1 | DEBUG ( default/core ): | 0 | L4 protocol| 9 | 1 | DEBUG ( default/core ): | 0 | L4 src port| 10 | 2 | DEBUG ( default/core ): | 0 | L4 dst port| 12 | 2 | DEBUG ( default/core ): | 0 | icmp type | 14 | 2 | DEBUG ( default/core ): | 0 | input snmp | 16 | 4 | DEBUG ( default/core ): | 0 | IPv4 src mask | 20 | 1 | DEBUG ( default/core ): | 0 | IPv4 dst mask | 21 | 1 | DEBUG ( default/core ): | 0 | src as | 22 | 4 | DEBUG ( default/core ): | 0 | dst as | 26 | 4 | DEBUG ( default/core ): | 0 | IPv4 next hop | 30 | 4 | DEBUG ( default/core ): | 0 | tcp flags | 34 | 1 | DEBUG ( default/core ): | 0 | output snmp| 35 | 4 | DEBUG ( default/core ): | 0 | in bytes | 39 | 8 | DEBUG ( default/core ): | 0 | in packets | 47 | 8 | DEBUG ( default/core ): | 0 | 152| 55 | 8 | DEBUG ( default/core ): | 0 | 153| 63 | 8 | DEBUG ( default/core ): | 0 | 136| 71 | 1 | DEBUG ( default/core ): - DEBUG ( default/core ): Netflow V9/IPFIX record size : 72 DEBUG ( default/core ): DEBUG ( default/core ): NfV10 agent : ::: DEBUG ( default/core ): NfV10 template type : options DEBUG ( default/core ): NfV10 template ID : 512 DEBUG ( default/core ): DEBUG ( default/core ): | field type | offset | size | DEBUG ( default/core ): | 144| 0 | 4 | DEBUG ( default/core ): | 160| 4 | 8 | DEBUG ( default/core ): | 130| 12 | 4 | DEBUG ( default/core ): | 214| 16 | 1 | DEBUG ( default/core ): | 215| 17 | 1 | DEBUG ( default/core ): - DEBUG ( default/core ): Netflow V9/IPFIX record size : 18 So it looks like my router (MX80) isn't sending this data... Maybe it's a JunOS config option? --Joel On Sat, Dec 7, 2013 at 8:46 AM, Joel Krauska j...@krauska.net wrote: Should I expect sampling 'correction' scaling to work with IPFIX? I have this configuration, but my byte counts appear to be off by our scaling factor. nfacctd_renormalize: true Is there a debug/log message that would identify the netflow sampling rate detected? It looks like I can hardcode with nfacctd_ext_sampling_rate or a sampling map, but I was hoping IPFIX would be transmitting the rate. Cheers, Joel ___ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
[pmacct-discussion] reload/refresh config?
Does pmacct support config reload without restarting processes like BGP? Use case: I'm tweaking our sampling rate, checking router CPU and UDP traffic loads. I'll need to adjust the sampling rate in the config. I'd rather avoid restarting the process and just 'reload' the config to get the new sampling rate. Is this possible? Workaround?:It looks like I could change BGP to run in a separate process... Another line of thinking: If I put the sampling map in a file, does that file get rechecked from time to time or only at startup? Cheers, --Joel ___ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
[pmacct-discussion] # ? !! comments
Would it be possible to adjust the config file parser to accept # as an alternative to !? I find myself using !# as it 'does the right thing' in most syntax highlighting. But !# means something else to scripters. util.c: 287 (in int iscomment(char *line)) if (line[j] == '!' || line[j] == '#' ) return TRUE; Clearly I'm down to nitpicky cosmetic issues. :) Thanks for all your help! --Joel ___ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
Re: [pmacct-discussion] Off by one warning?
Paolo, Sorry I missed that you had replied. Yes, these happen all the time. There's a big burst on startup and then a pretty steady one afterwards. It looks like the later burst might be due to sending two streams? INFO ( testing/print ): *** Purging cache - START *** INFO ( testing/print ): *** Purging cache - END (QN: 6, ET: 0) *** WARN: expecting flow '25593234' but received '234608' collector=0.0.0.0:6001agent=X:0 WARN: expecting flow '234609' but received '25593234' collector=0.0.0.0:6001agent=X:0 WARN: expecting flow '25593299' but received '234609' collector=0.0.0.0:6001agent=X:0 WARN: expecting flow '234610' but received '25593299' collector=0.0.0.0:6001agent=X:0 WARN: expecting flow '25593367' but received '234610' collector=0.0.0.0:6001agent=X:0 WARN: expecting flow '234611' but received '25593367' collector=0.0.0.0:6001agent=X:0 INFO ( testing/print ): *** Purging cache - START *** INFO ( testing/print ): *** Purging cache - END (QN: 7, ET: 0) *** WARN: expecting flow '25593429' but received '234611' collector=0.0.0.0:6001agent=X:0 WARN: expecting flow '234612' but received '25593429' collector=0.0.0.0:6001agent=X:0 WARN: expecting flow '25593510' but received '234612' collector=0.0.0.0:6001agent=X:0 WARN: expecting flow '234613' but received '25593510' collector=0.0.0.0:6001agent=X:0 WARN: expecting flow '25593572' but received '234613' collector=0.0.0.0:6001agent=X:0 WARN: expecting flow '234614' but received '25593572' collector=0.0.0.0:6001agent=X:0 See how the flow numbers flip back and forth between 234k and 25M? I'm willing to disable checks, but I wouldn't want to miss other debug information in my testing. Cheers, Joel On Mon, Nov 11, 2013 at 3:16 PM, Paolo Lucente pa...@pmacct.net wrote: Hi Joel, Could also be packets are received out of order, which can be harmless depending on the use-cases. Anyway if annoying these messages can be disabled by setting nfacctd_disable_checks to true. I propose this idea because i don't seem to have seen such warnings on a regular basis on other IPFIX exports. Maybe would help if you can define better frequently. Is that like in always, at times, in specific times of the day, or ..? Cheers, Paolo On Sun, Nov 10, 2013 at 06:26:22PM -0800, Joel Krauska wrote: (I should have mentioned I'm testing rc1 NetFlow Accounting Daemon, nfacctd 1.5.0rc1 (20130829-00) --enable-mysql --enable-64bit --enable-threads --enable-geoip I frequently get these Warnings. WARN: expecting flow '4423369' but received '4423371' collector=0.0.0.0:6001agent=BLAH:0 WARN: expecting flow '4423371' but received '4423372' collector=0.0.0.0:6001agent=BLAH:0 WARN: expecting flow '4423372' but received '4423374' collector=0.0.0.0:6001agent=BLAH:0 WARN: expecting flow '4423374' but received '4423375' collector=0.0.0.0:6001agent=BLAH:0 WARN: expecting flow '4423375' but received '4423376' collector=0.0.0.0:6001agent=BLAH:0 It seems odd to see them in series like this, since the 'expected' usually is the one it just received just before... Looks like possibly an off by 1 error? Cheers, Joel ___ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists ___ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists ___ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
[pmacct-discussion] buffer overflow / backtrace on 1.5rc1
I get a pretty repeatable buffer overflow when trying to use nfacctd with BGP enabled. (threaded) It will run for a few moments and then bombs out. *** buffer overflow detected ***: nfacctd: Core Process [default] terminated === Backtrace: = /lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x37)[0x7f56d4dd1f47] /lib/x86_64-linux-gnu/libc.so.6(+0x109e40)[0x7f56d4dd0e40] nfacctd: Core Process [default](bgp_nlri_parse+0x15f)[0x46b17f] nfacctd: Core Process [default](bgp_update_msg+0x3a7)[0x46bb87] nfacctd: Core Process [default](skinny_bgp_daemon+0xc1f)[0x46e84f] nfacctd: Core Process [default](thread_runner+0x5b)[0x45f72b] /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)[0x7f56d508ee9a] /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f56d4dbb3fd] === Memory map: 0040-004ca000 r-xp fd:01 270072 /opt/pmacct/sbin/nfacctd 006c9000-006ca000 r--p 000c9000 fd:01 270072 /opt/pmacct/sbin/nfacctd 006ca000-006cb000 rw-p 000ca000 fd:01 270072 /opt/pmacct/sbin/nfacctd 006cb000-0074c000 rw-p 00:00 0 00ab9000-00ada000 rw-p 00:00 0 [heap] 7f56c400-7f56c6e8c000 rw-p 00:00 0 7f56c6e8c000-7f56c800 ---p 00:00 0 7f56cbde2000-7f56cbdf7000 r-xp fd:01 390697 /lib/x86_64-linux-gnu/libgcc_s.so.1 7f56cbdf7000-7f56cbff6000 ---p 00015000 fd:01 390697 /lib/x86_64-linux-gnu/libgcc_s.so.1 7f56cbff6000-7f56cbff7000 r--p 00014000 fd:01 390697 /lib/x86_64-linux-gnu/libgcc_s.so.1 7f56cbff7000-7f56cbff8000 rw-p 00015000 fd:01 390697 /lib/x86_64-linux-gnu/libgcc_s.so.1 7f56cbfff000-7f56cc00 rw-p 00:00 0 7f56cc00-7f56d000 rw-p 00:00 0 7f56d3a0-7f56d3fb3000 rw-s 00:04 10398639 /dev/zero (deleted) 7f56d3fb3000-7f56d3fb4000 ---p 00:00 0 7f56d3fb4000-7f56d47b4000 rw-p 00:00 0 7f56d47b4000-7f56d48af000 r-xp fd:01 394152 /lib/x86_64-linux-gnu/libm-2.15.so 7f56d48af000-7f56d4aae000 ---p 000fb000 fd:01 394152 /lib/x86_64-linux-gnu/libm-2.15.so 7f56d4aae000-7f56d4aaf000 r--p 000fa000 fd:01 394152 /lib/x86_64-linux-gnu/libm-2.15.so 7f56d4aaf000-7f56d4ab rw-p 000fb000 fd:01 394152 /lib/x86_64-linux-gnu/libm-2.15.so 7f56d4ab-7f56d4ac6000 r-xp fd:01 390743 /lib/x86_64-linux-gnu/libz.so.1.2.3.4 7f56d4ac6000-7f56d4cc5000 ---p 00016000 fd:01 390743 /lib/x86_64-linux-gnu/libz.so.1.2.3.4 7f56d4cc5000-7f56d4cc6000 r--p 00015000 fd:01 390743 /lib/x86_64-linux-gnu/libz.so.1.2.3.4 7f56d4cc6000-7f56d4cc7000 rw-p 00016000 fd:01 390743 /lib/x86_64-linux-gnu/libz.so.1.2.3.4 7f56d4cc7000-7f56d4e7c000 r-xp fd:01 394141 /lib/x86_64-linux-gnu/libc-2.15.so 7f56d4e7c000-7f56d507c000 ---p 001b5000 fd:01 394141 /lib/x86_64-linux-gnu/libc-2.15.so 7f56d507c000-7f56d508 r--p 001b5000 fd:01 394141 /lib/x86_64-linux-gnu/libc-2.15.so 7f56d508-7f56d5082000 rw-p 001b9000 fd:01 394141 /lib/x86_64-linux-gnu/libc-2.15.so 7f56d5082000-7f56d5087000 rw-p 00:00 0 7f56d5087000-7f56d509f000 r-xp fd:01 394150 /lib/x86_64-linux-gnu/libpthread-2.15.so 7f56d509f000-7f56d529e000 ---p 00018000 fd:01 394150 /lib/x86_64-linux-gnu/libpthread-2.15.so 7f56d529e000-7f56d529f000 r--p 00017000 fd:01 394150 /lib/x86_64-linux-gnu/libpthread-2.15.so 7f56d529f000-7f56d52a rw-p 00018000 fd:01 394150 /lib/x86_64-linux-gnu/libpthread-2.15.so 7f56d52a-7f56d52a4000 rw-p 00:00 0 7f56d52a4000-7f56d52a6000 r-xp fd:01 394156 /lib/x86_64-linux-gnu/libdl-2.15.so 7f56d52a6000-7f56d54a6000 ---p 2000 fd:01 394156 /lib/x86_64-linux-gnu/libdl-2.15.so 7f56d54a6000-7f56d54a7000 r--p 2000 fd:01 394156 /lib/x86_64-linux-gnu/libdl-2.15.so 7f56d54a7000-7f56d54a8000 rw-p 3000 fd:01 394156 /lib/x86_64-linux-gnu/libdl-2.15.so 7f56d54a8000-7f56d54db000 r-xp fd:01 131070 /usr/lib/libGeoIP.so.1.4.8 7f56d54db000-7f56d56da000 ---p 00033000 fd:01 131070 /usr/lib/libGeoIP.so.1.4.8 7f56d56da000-7f56d56db000 r--p 00032000 fd:01 131070 /usr/lib/libGeoIP.so.1.4.8 7f56d56db000-7f56d56dd000 rw-p 00033000 fd:01 131070 /usr/lib/libGeoIP.so.1.4.8 7f56d56dd000-7f56d5711000 r-xp fd:01 135098 /usr/lib/x86_64-linux-gnu/libpcap.so.1.1.1 7f56d5711000-7f56d5911000 ---p 00034000 fd:01 135098 /usr/lib/x86_64-linux-gnu/libpcap.so.1.1.1 7f56d5911000-7f56d5912000 r--p 00034000 fd:01 135098 /usr/lib/x86_64-linux-gnu/libpcap.so.1.1.1 7f56d5912000-7f56d5913000 rw-p 00035000 fd:01 135098 /usr/lib/x86_64-linux-gnu/libpcap.so.1.1.1 7f56d5913000-7f56d5914000 rw-p 00:00 0 7f56d5914000-7f56d5bd2000 r-xp fd:01 130807 /usr/lib/x86_64-linux-gnu/libmysqlclient.so.18.0.0 7f56d5bd2000-7f56d5dd1000 ---p 002be000 fd:01 130807 /usr/lib/x86_64-linux-gnu/libmysqlclient.so.18.0.0 7f56d5dd1000-7f56d5dd7000 r--p 002bd000 fd:01 130807 /usr/lib/x86_64-linux-gnu/libmysqlclient.so.18.0.0 7f56d5dd7000-7f56d5e55000 rw-p 002c3000 fd:01 130807 /usr/lib/x86_64-linux-gnu/libmysqlclient.so.18.0.0 7f56d5e55000-7f56d5e5a000 rw-p 00:00 0 7f56d5e5a000-7f56d5e7c000 r-xp fd:01 394153
Re: [pmacct-discussion] buffer overflow / backtrace on 1.5rc1
FWIW: I get the same on nfacctd 0.14.3 (20130503-00) On Wed, Dec 4, 2013 at 4:18 PM, Joel Krauska j...@krauska.net wrote: I get a pretty repeatable buffer overflow when trying to use nfacctd with BGP enabled. (threaded) It will run for a few moments and then bombs out. *** buffer overflow detected ***: nfacctd: Core Process [default] terminated === Backtrace: = /lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x37)[0x7f56d4dd1f47] /lib/x86_64-linux-gnu/libc.so.6(+0x109e40)[0x7f56d4dd0e40] nfacctd: Core Process [default](bgp_nlri_parse+0x15f)[0x46b17f] nfacctd: Core Process [default](bgp_update_msg+0x3a7)[0x46bb87] nfacctd: Core Process [default](skinny_bgp_daemon+0xc1f)[0x46e84f] nfacctd: Core Process [default](thread_runner+0x5b)[0x45f72b] /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)[0x7f56d508ee9a] /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f56d4dbb3fd] === Memory map: 0040-004ca000 r-xp fd:01 270072 /opt/pmacct/sbin/nfacctd 006c9000-006ca000 r--p 000c9000 fd:01 270072 /opt/pmacct/sbin/nfacctd 006ca000-006cb000 rw-p 000ca000 fd:01 270072 /opt/pmacct/sbin/nfacctd 006cb000-0074c000 rw-p 00:00 0 00ab9000-00ada000 rw-p 00:00 0 [heap] 7f56c400-7f56c6e8c000 rw-p 00:00 0 7f56c6e8c000-7f56c800 ---p 00:00 0 7f56cbde2000-7f56cbdf7000 r-xp fd:01 390697 /lib/x86_64-linux-gnu/libgcc_s.so.1 7f56cbdf7000-7f56cbff6000 ---p 00015000 fd:01 390697 /lib/x86_64-linux-gnu/libgcc_s.so.1 7f56cbff6000-7f56cbff7000 r--p 00014000 fd:01 390697 /lib/x86_64-linux-gnu/libgcc_s.so.1 7f56cbff7000-7f56cbff8000 rw-p 00015000 fd:01 390697 /lib/x86_64-linux-gnu/libgcc_s.so.1 7f56cbfff000-7f56cc00 rw-p 00:00 0 7f56cc00-7f56d000 rw-p 00:00 0 7f56d3a0-7f56d3fb3000 rw-s 00:04 10398639 /dev/zero (deleted) 7f56d3fb3000-7f56d3fb4000 ---p 00:00 0 7f56d3fb4000-7f56d47b4000 rw-p 00:00 0 7f56d47b4000-7f56d48af000 r-xp fd:01 394152 /lib/x86_64-linux-gnu/libm-2.15.so 7f56d48af000-7f56d4aae000 ---p 000fb000 fd:01 394152 /lib/x86_64-linux-gnu/libm-2.15.so 7f56d4aae000-7f56d4aaf000 r--p 000fa000 fd:01 394152 /lib/x86_64-linux-gnu/libm-2.15.so 7f56d4aaf000-7f56d4ab rw-p 000fb000 fd:01 394152 /lib/x86_64-linux-gnu/libm-2.15.so 7f56d4ab-7f56d4ac6000 r-xp fd:01 390743 /lib/x86_64-linux-gnu/libz.so.1.2.3.4 7f56d4ac6000-7f56d4cc5000 ---p 00016000 fd:01 390743 /lib/x86_64-linux-gnu/libz.so.1.2.3.4 7f56d4cc5000-7f56d4cc6000 r--p 00015000 fd:01 390743 /lib/x86_64-linux-gnu/libz.so.1.2.3.4 7f56d4cc6000-7f56d4cc7000 rw-p 00016000 fd:01 390743 /lib/x86_64-linux-gnu/libz.so.1.2.3.4 7f56d4cc7000-7f56d4e7c000 r-xp fd:01 394141 /lib/x86_64-linux-gnu/libc-2.15.so 7f56d4e7c000-7f56d507c000 ---p 001b5000 fd:01 394141 /lib/x86_64-linux-gnu/libc-2.15.so 7f56d507c000-7f56d508 r--p 001b5000 fd:01 394141 /lib/x86_64-linux-gnu/libc-2.15.so 7f56d508-7f56d5082000 rw-p 001b9000 fd:01 394141 /lib/x86_64-linux-gnu/libc-2.15.so 7f56d5082000-7f56d5087000 rw-p 00:00 0 7f56d5087000-7f56d509f000 r-xp fd:01 394150 /lib/x86_64-linux-gnu/libpthread-2.15.so 7f56d509f000-7f56d529e000 ---p 00018000 fd:01 394150 /lib/x86_64-linux-gnu/libpthread-2.15.so 7f56d529e000-7f56d529f000 r--p 00017000 fd:01 394150 /lib/x86_64-linux-gnu/libpthread-2.15.so 7f56d529f000-7f56d52a rw-p 00018000 fd:01 394150 /lib/x86_64-linux-gnu/libpthread-2.15.so 7f56d52a-7f56d52a4000 rw-p 00:00 0 7f56d52a4000-7f56d52a6000 r-xp fd:01 394156 /lib/x86_64-linux-gnu/libdl-2.15.so 7f56d52a6000-7f56d54a6000 ---p 2000 fd:01 394156 /lib/x86_64-linux-gnu/libdl-2.15.so 7f56d54a6000-7f56d54a7000 r--p 2000 fd:01 394156 /lib/x86_64-linux-gnu/libdl-2.15.so 7f56d54a7000-7f56d54a8000 rw-p 3000 fd:01 394156 /lib/x86_64-linux-gnu/libdl-2.15.so 7f56d54a8000-7f56d54db000 r-xp fd:01 131070 /usr/lib/libGeoIP.so.1.4.8 7f56d54db000-7f56d56da000 ---p 00033000 fd:01 131070 /usr/lib/libGeoIP.so.1.4.8 7f56d56da000-7f56d56db000 r--p 00032000 fd:01 131070 /usr/lib/libGeoIP.so.1.4.8 7f56d56db000-7f56d56dd000 rw-p 00033000 fd:01 131070 /usr/lib/libGeoIP.so.1.4.8 7f56d56dd000-7f56d5711000 r-xp fd:01 135098 /usr/lib/x86_64-linux-gnu/libpcap.so.1.1.1 7f56d5711000-7f56d5911000 ---p 00034000 fd:01 135098 /usr/lib/x86_64-linux-gnu/libpcap.so.1.1.1 7f56d5911000-7f56d5912000 r--p 00034000 fd:01 135098 /usr/lib/x86_64-linux-gnu/libpcap.so.1.1.1 7f56d5912000-7f56d5913000 rw-p 00035000 fd:01 135098 /usr/lib/x86_64-linux-gnu/libpcap.so.1.1.1 7f56d5913000-7f56d5914000 rw-p 00:00 0 7f56d5914000-7f56d5bd2000 r-xp fd:01 130807 /usr/lib/x86_64-linux-gnu/libmysqlclient.so.18.0.0 7f56d5bd2000-7f56d5dd1000 ---p 002be000 fd:01 130807 /usr/lib/x86_64-linux-gnu/libmysqlclient.so.18.0.0 7f56d5dd1000-7f56d5dd7000 r--p 002bd000 fd:01 130807 /usr/lib/x86_64-linux-gnu/libmysqlclient.so
Re: [pmacct-discussion] Off by one warning?
Sure thing. On Wed, Dec 4, 2013 at 4:37 PM, Paolo Lucente pa...@pmacct.net wrote: Hi Joel, Disabling checks is harmless, apart from having the benefit of removing you the annoying part of those warning messages. But one more question: you say sending two streams but i see only a single exporter, 'agent=X:0'. Is it X reallt corresponding to a single IP address (which would justify the warnings) or not? If yes, would it be possible for you to send me privately a brief trace of the export packets from that agent? Cheers, Paolo On Wed, Dec 04, 2013 at 03:53:04PM -0800, Joel Krauska wrote: Paolo, Sorry I missed that you had replied. Yes, these happen all the time. There's a big burst on startup and then a pretty steady one afterwards. It looks like the later burst might be due to sending two streams? INFO ( testing/print ): *** Purging cache - START *** INFO ( testing/print ): *** Purging cache - END (QN: 6, ET: 0) *** WARN: expecting flow '25593234' but received '234608' collector=0.0.0.0:6001agent=X:0 WARN: expecting flow '234609' but received '25593234' collector=0.0.0.0:6001agent=X:0 WARN: expecting flow '25593299' but received '234609' collector=0.0.0.0:6001agent=X:0 WARN: expecting flow '234610' but received '25593299' collector=0.0.0.0:6001agent=X:0 WARN: expecting flow '25593367' but received '234610' collector=0.0.0.0:6001agent=X:0 WARN: expecting flow '234611' but received '25593367' collector=0.0.0.0:6001agent=X:0 INFO ( testing/print ): *** Purging cache - START *** INFO ( testing/print ): *** Purging cache - END (QN: 7, ET: 0) *** WARN: expecting flow '25593429' but received '234611' collector=0.0.0.0:6001agent=X:0 WARN: expecting flow '234612' but received '25593429' collector=0.0.0.0:6001agent=X:0 WARN: expecting flow '25593510' but received '234612' collector=0.0.0.0:6001agent=X:0 WARN: expecting flow '234613' but received '25593510' collector=0.0.0.0:6001agent=X:0 WARN: expecting flow '25593572' but received '234613' collector=0.0.0.0:6001agent=X:0 WARN: expecting flow '234614' but received '25593572' collector=0.0.0.0:6001agent=X:0 See how the flow numbers flip back and forth between 234k and 25M? I'm willing to disable checks, but I wouldn't want to miss other debug information in my testing. Cheers, Joel On Mon, Nov 11, 2013 at 3:16 PM, Paolo Lucente pa...@pmacct.net wrote: Hi Joel, Could also be packets are received out of order, which can be harmless depending on the use-cases. Anyway if annoying these messages can be disabled by setting nfacctd_disable_checks to true. I propose this idea because i don't seem to have seen such warnings on a regular basis on other IPFIX exports. Maybe would help if you can define better frequently. Is that like in always, at times, in specific times of the day, or ..? Cheers, Paolo On Sun, Nov 10, 2013 at 06:26:22PM -0800, Joel Krauska wrote: (I should have mentioned I'm testing rc1 NetFlow Accounting Daemon, nfacctd 1.5.0rc1 (20130829-00) --enable-mysql --enable-64bit --enable-threads --enable-geoip I frequently get these Warnings. WARN: expecting flow '4423369' but received '4423371' collector=0.0.0.0:6001agent=BLAH:0 WARN: expecting flow '4423371' but received '4423372' collector=0.0.0.0:6001agent=BLAH:0 WARN: expecting flow '4423372' but received '4423374' collector=0.0.0.0:6001agent=BLAH:0 WARN: expecting flow '4423374' but received '4423375' collector=0.0.0.0:6001agent=BLAH:0 WARN: expecting flow '4423375' but received '4423376' collector=0.0.0.0:6001agent=BLAH:0 It seems odd to see them in series like this, since the 'expected' usually is the one it just received just before... Looks like possibly an off by 1 error? Cheers, Joel ___ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists ___ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists ___ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
Re: [pmacct-discussion] buffer overflow / backtrace on 1.5rc1
Running Ubuntu 12.04.2. Can't speak to the BGP config on the Juniper side, but I'll ask for that. I believe IPv6 might be in the mix here. I'll do the gdb bt and email you. On Wed, Dec 4, 2013 at 4:46 PM, Paolo Lucente pa...@pmacct.net wrote: Hi Joel, Wow, interesting. What OS are you running? What BGP capabilities are enabled and which address families are you sending over? It would help if you can run the daemon under gdb and collect 'bt' information (send it directly to me). Post in the same email also your config. We can take it from there. Cheers, Paolo On Wed, Dec 04, 2013 at 04:18:42PM -0800, Joel Krauska wrote: I get a pretty repeatable buffer overflow when trying to use nfacctd with BGP enabled. (threaded) It will run for a few moments and then bombs out. *** buffer overflow detected ***: nfacctd: Core Process [default] terminated === Backtrace: = /lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x37)[0x7f56d4dd1f47] /lib/x86_64-linux-gnu/libc.so.6(+0x109e40)[0x7f56d4dd0e40] nfacctd: Core Process [default](bgp_nlri_parse+0x15f)[0x46b17f] nfacctd: Core Process [default](bgp_update_msg+0x3a7)[0x46bb87] nfacctd: Core Process [default](skinny_bgp_daemon+0xc1f)[0x46e84f] nfacctd: Core Process [default](thread_runner+0x5b)[0x45f72b] /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)[0x7f56d508ee9a] /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f56d4dbb3fd] === Memory map: 0040-004ca000 r-xp fd:01 270072 /opt/pmacct/sbin/nfacctd 006c9000-006ca000 r--p 000c9000 fd:01 270072 /opt/pmacct/sbin/nfacctd 006ca000-006cb000 rw-p 000ca000 fd:01 270072 /opt/pmacct/sbin/nfacctd 006cb000-0074c000 rw-p 00:00 0 00ab9000-00ada000 rw-p 00:00 0 [heap] 7f56c400-7f56c6e8c000 rw-p 00:00 0 7f56c6e8c000-7f56c800 ---p 00:00 0 7f56cbde2000-7f56cbdf7000 r-xp fd:01 390697 /lib/x86_64-linux-gnu/libgcc_s.so.1 7f56cbdf7000-7f56cbff6000 ---p 00015000 fd:01 390697 /lib/x86_64-linux-gnu/libgcc_s.so.1 7f56cbff6000-7f56cbff7000 r--p 00014000 fd:01 390697 /lib/x86_64-linux-gnu/libgcc_s.so.1 7f56cbff7000-7f56cbff8000 rw-p 00015000 fd:01 390697 /lib/x86_64-linux-gnu/libgcc_s.so.1 7f56cbfff000-7f56cc00 rw-p 00:00 0 7f56cc00-7f56d000 rw-p 00:00 0 7f56d3a0-7f56d3fb3000 rw-s 00:04 10398639 /dev/zero (deleted) 7f56d3fb3000-7f56d3fb4000 ---p 00:00 0 7f56d3fb4000-7f56d47b4000 rw-p 00:00 0 7f56d47b4000-7f56d48af000 r-xp fd:01 394152 /lib/x86_64-linux-gnu/libm-2.15.so 7f56d48af000-7f56d4aae000 ---p 000fb000 fd:01 394152 /lib/x86_64-linux-gnu/libm-2.15.so 7f56d4aae000-7f56d4aaf000 r--p 000fa000 fd:01 394152 /lib/x86_64-linux-gnu/libm-2.15.so 7f56d4aaf000-7f56d4ab rw-p 000fb000 fd:01 394152 /lib/x86_64-linux-gnu/libm-2.15.so 7f56d4ab-7f56d4ac6000 r-xp fd:01 390743 /lib/x86_64-linux-gnu/libz.so.1.2.3.4 7f56d4ac6000-7f56d4cc5000 ---p 00016000 fd:01 390743 /lib/x86_64-linux-gnu/libz.so.1.2.3.4 7f56d4cc5000-7f56d4cc6000 r--p 00015000 fd:01 390743 /lib/x86_64-linux-gnu/libz.so.1.2.3.4 7f56d4cc6000-7f56d4cc7000 rw-p 00016000 fd:01 390743 /lib/x86_64-linux-gnu/libz.so.1.2.3.4 7f56d4cc7000-7f56d4e7c000 r-xp fd:01 394141 /lib/x86_64-linux-gnu/libc-2.15.so 7f56d4e7c000-7f56d507c000 ---p 001b5000 fd:01 394141 /lib/x86_64-linux-gnu/libc-2.15.so 7f56d507c000-7f56d508 r--p 001b5000 fd:01 394141 /lib/x86_64-linux-gnu/libc-2.15.so 7f56d508-7f56d5082000 rw-p 001b9000 fd:01 394141 /lib/x86_64-linux-gnu/libc-2.15.so 7f56d5082000-7f56d5087000 rw-p 00:00 0 7f56d5087000-7f56d509f000 r-xp fd:01 394150 /lib/x86_64-linux-gnu/libpthread-2.15.so 7f56d509f000-7f56d529e000 ---p 00018000 fd:01 394150 /lib/x86_64-linux-gnu/libpthread-2.15.so 7f56d529e000-7f56d529f000 r--p 00017000 fd:01 394150 /lib/x86_64-linux-gnu/libpthread-2.15.so 7f56d529f000-7f56d52a rw-p 00018000 fd:01 394150 /lib/x86_64-linux-gnu/libpthread-2.15.so 7f56d52a-7f56d52a4000 rw-p 00:00 0 7f56d52a4000-7f56d52a6000 r-xp fd:01 394156 /lib/x86_64-linux-gnu/libdl-2.15.so 7f56d52a6000-7f56d54a6000 ---p 2000 fd:01 394156 /lib/x86_64-linux-gnu/libdl-2.15.so 7f56d54a6000-7f56d54a7000 r--p 2000 fd:01 394156 /lib/x86_64-linux-gnu/libdl-2.15.so 7f56d54a7000-7f56d54a8000 rw-p 3000 fd:01 394156 /lib/x86_64-linux-gnu/libdl-2.15.so 7f56d54a8000-7f56d54db000 r-xp fd:01 131070 /usr/lib/libGeoIP.so.1.4.8 7f56d54db000-7f56d56da000 ---p 00033000 fd:01 131070 /usr/lib/libGeoIP.so.1.4.8 7f56d56da000-7f56d56db000 r--p 00032000 fd:01 131070 /usr/lib/libGeoIP.so.1.4.8 7f56d56db000-7f56d56dd000 rw-p 00033000 fd:01 131070 /usr/lib/libGeoIP.so.1.4.8 7f56d56dd000-7f56d5711000 r-xp fd:01 135098 /usr/lib/x86_64-linux-gnu/libpcap.so.1.1.1 7f56d5711000-7f56d5911000 ---p 00034000
[pmacct-discussion] IPFIX Decodes
Howdy there. I've been experimenting with nfacctd and it's be a delight to setup. (very simple config) A quick note: Some of the IPFIX Field types aren't being decoded in debug... eg. DEBUG ( default/core ): NfV10 template type : flow DEBUG ( default/core ): NfV10 template ID : 256 DEBUG ( default/core ): - DEBUG ( default/core ): |pen | field type | offset | size | DEBUG ( default/core ): | 0 | IPv4 src addr | 0 | 4 | DEBUG ( default/core ): | 0 | IPv4 dst addr | 4 | 4 | DEBUG ( default/core ): | 0 | tos| 8 | 1 | DEBUG ( default/core ): | 0 | L4 protocol| 9 | 1 | DEBUG ( default/core ): | 0 | L4 src port| 10 | 2 | DEBUG ( default/core ): | 0 | L4 dst port| 12 | 2 | DEBUG ( default/core ): | 0 | icmp type | 14 | 2 | DEBUG ( default/core ): | 0 | input snmp | 16 | 4 | DEBUG ( default/core ): | 0 | IPv4 src mask | 20 | 1 | DEBUG ( default/core ): | 0 | IPv4 dst mask | 21 | 1 | DEBUG ( default/core ): | 0 | src as | 22 | 4 | DEBUG ( default/core ): | 0 | dst as | 26 | 4 | DEBUG ( default/core ): | 0 | IPv4 next hop | 30 | 4 | DEBUG ( default/core ): | 0 | tcp flags | 34 | 1 | DEBUG ( default/core ): | 0 | output snmp| 35 | 4 | DEBUG ( default/core ): | 0 | in bytes | 39 | 8 | DEBUG ( default/core ): | 0 | in packets | 47 | 8 | DEBUG ( default/core ): | 0 | 152| 55 | 8 | DEBUG ( default/core ): | 0 | 153| 63 | 8 | DEBUG ( default/core ): | 0 | 136| 71 | 1 | DEBUG ( default/core ): - Field types 152,152 and 136 appear to be documented in RFC 5102. http://www.ietf.org/rfc/rfc5102.txt 152 = flowStartMilliseconds 153 = flowStartMilliseconds 136 = flowEndReason But they do not appear to be as-yet 'understood' by pmacct. Not sure if this is useful, but thought you might like to know. Cheers, Joel ___ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
