Re: [pmacct-discussion] sflow agent address
On 1/9/07, Juraj Sucik [EMAIL PROTECTED] wrote: Hello, I am trying to use sfacctd. I am receiving sflow packets from two Force10 routers. However the routers send sflow packets to a host which then forwards them to another host where I run sfacctd. How is the host forwarding this packets? if you're not already, you should be using samplicate (works perfectly). I receive a lot of warnings like: WARN: expecting flow '9210526' but received '5813156' collector=(null):2060 agent=192.168.1.1:1 WARN: expecting flow '7618226' but received '10013980' collector=(null):2060 agent=192.168.1.1:0 WARN: expecting flow '10013981' but received '7618227' collector=(null):2060 agent=192.168.1.1:0 WARN: expecting flow '13099151' but received '7581594' collector=(null):2060 agent=192.168.1.1:13 WARN: expecting flow '7581594' but received '13099152' collector=(null):2060 agent=192.168.1.1:13 The 192.168.1.1 is the address of the forwarding host. It seems that sflacctd takes the source address of udp packet as an agent address, which I think is incorrect. According to sflow specs the agent address is included in sflow protocol itself (see page 32 of http://sflow.org/sflow_version_5.txt ) and sfacctd should use this one instead. I think this is also the reason for the warnings (sfacctd actually thinks they are coming from the same source, but they are not). sfacctd uses the information provided in the sFlow datagrams, not the source address of the udp packet (well...I hope. using samplicate I keep the original source address so...maybe I'm wrong.) aaron.glenn ___ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
Re: [pmacct-discussion] nfacctd warnings
On 11/15/06, Peter Nixon [EMAIL PROTECTED] wrote: It appears to be unrelated to the actual problem though as the error still occurs.. I have also rebooted the ciscos so it doesnt appear to be that.. Any ideas? I am running pmacct-0.11.1-3.1 this feature was implemented to detect packetloss between the exporter and the collector. unless you can think of a better reason for receiving flows wildly out of order, I'd say something is dropping packets between your collector and your cisco gear. ___ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
Re: [pmacct-discussion] pmacct on 64 bit OS ?
On 11/14/06, zulkarnain [EMAIL PROTECTED] wrote: Hi, Has anyone used pmacct on 64 bit OS (FC6 or other linux distro)? And if you are aware of any bug or shortcoming of pmacct on the 64 bit OS? Or it works as normal. runs great on sparc64 ___ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
Re: [pmacct-discussion] sFlow capturing from HP 3400cl
On 10/26/06, Oliver Hookins [EMAIL PROTECTED] wrote: I guess my question at this point is, what do you do when you have say 1GBps of traffic to record and you need 100% accuracy? you use the SNMP octet counters and poll them at regular intervals. but guess what - you'll generally end up with the same value. what application do you have that requires precisely 100% precision? I can't think of any. Nearly all ISP billing these days is, and has been, done by sampling interface octet counters at 5 minute intervals, and then chucking the top 5% of the sampled values (roughly). using sampled flow data for billing is actually statistically *more* accurate (depending on your sampling method, of course). ___ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
Re: [pmacct-discussion] pmacctd rc3 core dumps
On 8/22/06, Gert Burger [EMAIL PROTECTED] wrote: Hi Seems like my pmacctd crashes everytime it writes to my mysql4.1 db. The main prog keeps running but a core dump is created with every write to the db. I tried configuring with --enable-debug, but gdb still gives nothing when doing a backtrace(No symbols). What can I try next to get more debug info? What command do you use to launch GDB? What OS are you running? Did you build the mysql libs with symbols? rubber# gdb -c sfacctd.core `which sfacctd` GNU gdb 6.2.1 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-dragonfly... Core was generated by `sfacctd'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libpcap.so.3...done. Loaded symbols for /usr/lib/libpcap.so.3 Reading symbols from /usr/local/lib/libpq.so.5...done. Loaded symbols for /usr/local/lib/libpq.so.5 Reading symbols from /usr/lib/libm.so.3...done. Loaded symbols for /usr/lib/libm.so.3 Reading symbols from /usr/lib/libz.so.3...done. Loaded symbols for /usr/lib/libz.so.3 Reading symbols from /usr/lib/libc.so.6...done. Loaded symbols for /usr/lib/libc.so.6 Reading symbols from /usr/lib/libssl.so.4...done. Loaded symbols for /usr/lib/libssl.so.4 Reading symbols from /usr/lib/libcrypto.so.4...done. Loaded symbols for /usr/lib/libcrypto.so.4 Reading symbols from /usr/lib/libcrypt.so.3...done. Loaded symbols for /usr/lib/libcrypt.so.3 Reading symbols from /usr/libexec/ld-elf.so.2...done. Loaded symbols for /usr/libexec/ld-elf.so.2 #0 0x2818b8cd in strdup () from /usr/lib/libc.so.6 (gdb) bt #0 0x2818b8cd in strdup () from /usr/lib/libc.so.6 #1 0x280f6014 in conninfo_parse (conninfo=0x0, errorMessage=0x29604310) at fe-connect.c:2522 #2 0x280f395b in connectOptions1 (conn=0x29604000, conninfo=0x0) at fe-connect.c:360 #3 0x280f38f2 in PQconnectStart (conninfo=0x0) at fe-connect.c:319 #4 0x280f38b0 in PQconnectdb (conninfo=0x0) at fe-connect.c:277 #5 0x0806cef5 in PG_DB_Connect (db=0x80add98, host=0x0) at pgsql_plugin.c:608 #6 0x0806e5e0 in sql_cache_insert (data=0x28d7e768, idata=0xbfbcd780) at sql_common.c:463 #7 0x0806ae5a in pgsql_plugin (pipe_fd=5, cfgptr=0x28393928, ptr=0x80a8b00) at pgsql_plugin.c:251 #8 0x0805701f in load_plugins (req=0xbfbddee3) at plugin_hooks.c:162 #9 0x08051eb9 in main (argc=3, argv=0xbfbffab4, envp=0xbfbffac4) at sfacctd.c:463 (gdb) quit rubber# uname -a DragonFly rubber.nsindus.net 1.7.0-DEVELOPMENT DragonFly 1.7.0-DEVELOPMENT #0: Sun Aug 13 03:11:51 CEST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 regards, aaron.glenn ___ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
[pmacct-discussion] reliability of dst_host aggregate?
I've been using sfacctd extensively for quite some time, and have never run across an issue where the values it returned were wildly inaccurate. I'm sure this is a configuration snafu on my part, however I simply can't find it. I've got a collector that collects for two large routers; my AS and MAC aggregate numbers are flawless, however I also need to graph throughput and pps for a single IP address (our IRC server). The interface counters report 800Kbps in throughput and around 300-400pps, however deriving these values from sflow I get about a tenth of that. The routers sample egress only and therefore I have tripled checked to make sure all ports passing traffic are also being sampled. Using sflowtool, I see many more sflow datagrams with the dstIP I'm interested in, as well as the proper outputPort ifIndex value - hence why I'm wondering if this is a strange pmacct thing. any ideas? thanks, aaron ___ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
Re: [pmacct-discussion] PostgreSQL performance
On 4/7/06, Sven Anderson [EMAIL PROTECTED] wrote: Is there a tuning problem, or is PostgreSQL known to be not as fast as MySQL? I thought, maybe there are some kind of rollback journals written, which MySQL doesn't, or the hash-tables are not indexed correctly? Any ideas? It could be a myriad of issues. Have you changed any of the default PostgreSQL settings? PostgreSQL, by default, is not configured for anything but pure compatibility - meaning it will certainly work, but not at it's best. For what it's worth, I had PostgreSQL and pmacct on an OpenBSD 3.8 box and experienced no problems past the 1.2million row mark (I shutdown that installation for unrelated reasons). If you are not familiar with PostgreSQL - definitely start reading here[1] regards, aaron.glenn [1]http://www.postgresql.org/docs/8.1/interactive/runtime-config.html
Re: [pmacct-discussion] sfacctd and -D not daemonizing
On 3/9/06, Ivan A. Beveridge [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I am trying to get get sfacctd to daemonize with the -D flag, and it seems to refuse to do so. It works fine with the daemonize: true entry in the config file though. What platform are you running on? I've got rc1 and the 0.9.6 branch running on both OpenBSD 3.8/sparc64 and FreeBSD 5.4/ia32 with the -D flag no problem... aaron.glenn
