Paolo Lucente
Mon, 04 Feb 2008 04:20:15 -0800
Hi Leo, please follow my replies inline. On Sun, Feb 03, 2008 at 12:55:00PM +0100, Alexander 'Leo' Bergolth wrote: > aggregate[inbound]: dst_host, dst_port > > Using this configuration, I'd expect the netflow packets to contain only > 0.0.0.0 as src_host and src_port. > However printing those packets with flow-tools, shows the following results: > -------------------- 8< -------------------- > # flow-receive -V5 0/0/2100 | flow-print -f3 -l > srcIP dstIP prot srcPort dstPort octets > packets > 203.68.227.15 192.168.60.233 17 0 0 46 1 > 216.73.86.106 195.202.144.148 6 80 0 2964 10 > 91.65.194.94 195.202.144.148 17 0 0 395 1 > 91.65.194.94 192.168.60.102 17 0 0 395 1 > [...] > -------------------- 8< -------------------- > > The left hand side contains arbitrary ip addresses, which IMHO shouldn't > be there since I've already been aggregating at the probe. > Will I have to aggregate traffic again at the collector, if it has > already been aggregated in a suitable format on the probe side? It really depends on the NetFlow version you are exporting the flows. In fact NetFlow v5 doesn't support aggregation at all, ie. the flow structure doesn't include a packets counter field. NetFlow v9 solves this issue and you should be able to verify it by appending to your config the following line: nfprobe_version[inbound]: 9 There is only one more glitch as you are including L4 primitives in your aggregate (dst_port): you have to add the "proto" primitive aswell in order to get the "dst_port" populated correctly, ie: aggregate[inbound]: dst_host, dst_port, proto > Another question: If I enable the second probe plugin (outbound > traffic), will I have to set different nfprobe_engine ids and types for > each plugin and filter them into two sql-plugins using pre_tag_map on > the collector-side? Correct! > Will there be any concurrent access problems when collecting incoming > and outgoing traffic from different probes? (I'd like to use sqlite as a > first shot.) No, pmacct locks the table while using it. Further instances will just queue until who holds the lock has finished its business. The instances are started at the same time and while having the same sql_refresh_time keeps things clean and simple, it will cause races. This is why you also have a "sql_startup_delay" directive to minimize races - well, given a sufficient delay compared to the average amount of data you are writing to the DB. > Btw: Allowing MAC aggregation for link type 113 would really be nice, > since this link type (linux cooked, DLT_LINUX_SLL) is used not only for > ppp but also for many other interfaces like the "any" interface on > linux. See "man 3 pcap" for info in DLT_LINUX_SLL. Agreed. This has also arisen in some recent email here on the list but i need a trace in pcap format to see feasibility. I enquired for that already but received none. Would you mind sending me a trace with a few full payload packets privately? "tcpdump -i xxx -w trace.pcap -s 1500" should do the job. Cheers, Paolo _______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists