pmacct-discussion  

Re: [pmacct-discussion] nfprobe and nfacctd

Alexander 'Leo' Bergolth
Sun, 10 Feb 2008 02:27:10 -0800

Hi Paolo!

On 02/09/2008 12:56 AM, Paolo Lucente wrote:

sorry for this late reply. You can safely ignore that debug log for your
purposes and check what gets really written on the remote collector side
(which should be the network traffic aggregated as per your expectations).


Ooops! I should have checked that...
Sorry for the noise!
I verified it using nfacctd and everything works as expected.

Unfortunately  Netflow version 9 seems to imply mac-aggregation:
"MAC aggregation not available for link type: 113" :(
I've simply enabled mac aggregation for the linux-cooked link-type using the attached small patch and everythink works fine now... 


That debug gives you insights on how flows are cached inside the nfprobe
plugin itself - and before being exported to the collector. The plugin
has still the concept of micro-flows in memory. Reason for that being
the need to handle properly cut over of such flows (through TCP flags or
protocol-specific timeouts). Once purged they get aggregated, if the
configuration requests so.


Yes, that shounds reasonable. ;-)
But if you are tracking e.g. tcp flags, why are the ports still aggregated according to the ports_file? 

-------------------- 8< --------------------
DEBUG ( outbound/nfprobe ): ADD FLOW seq:28 [137.208.89.100]:22 <> [192.168.60.4]:0 proto:6 
-------------------- 8< --------------------
If analyzing the tcp fin flag as an indicator for an ended flow, shouldn't the micro-flow be identified by the whole unaggregated socket-pair (src_host, src_port, dst_host, dst_port, proto)?
I found out that in my configuration, ended tcp flows are in many cases expiring according to the "tcp" nfprobe_timeout, not according to the "tcp.fin" timeout, even though tcpdump shows the corresponding fin-packet on the wire. Maybe that's because of that port_file aggregation: The fin-packet sets the flow-expiry-timer to tcp_fin_timeout but the next packet from another tcp connection that matches because the src/dst-port has been rewritten to zero resets the expiry-timer to tcp_timeout? If that's the reason, it works in this direction (the ports_file-aggregated micro-flows will live longer if packets from other matching tcp connections reset the timer) but on the other hand, it may lead to flows being ended too early: If there are multiple tcp connections being aggregated by the ports_file, pmacct sees a fin packet and the other connections won't produce any traffic for the next fin_timeout seconds, the flow will be expired. 

Is this the intended behavior or am I missing something?

Cheers,
--leo
Btw: The nfprobe plugin contains a statistics function that doesn't seem to be called anywhere... 


On Wed, Feb 06, 2008 at 11:57:52AM +0100, Alexander 'Leo' Bergolth wrote:

On 02/04/2008 01:20 PM, Paolo Lucente wrote:

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
OK, I've tried version 9 now with the following aggregation directives, but I'm still getting multiple flows for different foreign (src_host) hosts and one local (dst_host) host...
aggregate_filter[inbound]: dst net 192.168.0.0/16 and not src net 192.168.0.0/16 and src port 80 
aggregate[inbound]: dst_host, src_port, proto

-------------------- 8< --------------------
DEBUG ( inbound/nfprobe ): ADD FLOW seq:1 [89.149.217.215]:80 <> [192.168.60.4]:0 proto:6 DEBUG ( inbound/nfprobe ): ADD FLOW seq:2 [89.149.217.214]:80 <> [192.168.60.101]:0 proto:6 DEBUG ( inbound/nfprobe ): ADD FLOW seq:3 [62.146.108.150]:80 <> [192.168.60.4]:0 proto:6 DEBUG ( inbound/nfprobe ): ADD FLOW seq:4 [62.146.108.150]:80 <> [192.168.60.101]:0 proto:6 DEBUG ( inbound/nfprobe ): ADD FLOW seq:5 [80.240.229.101]:80 <> [192.168.60.4]:0 proto:6 DEBUG ( inbound/nfprobe ): ADD FLOW seq:6 [192.168.60.101]:0 <> [194.232.104.21]:80 proto:6 DEBUG ( inbound/nfprobe ): ADD FLOW seq:7 [80.240.229.101]:80 <> [192.168.60.103]:0 proto:6 DEBUG ( inbound/nfprobe ): ADD FLOW seq:8 [192.168.60.101]:0 <> [194.232.105.164]:80 proto:6 DEBUG ( inbound/nfprobe ): ADD FLOW seq:9 [192.168.60.101]:0 <> [213.90.74.22]:80 proto:6 
-------------------- 8< --------------------

Any hints?

Thanks,
--leo
--
e-mail   ::: Leo.Bergolth (at) wu-wien.ac.at
fax      ::: +43-1-31336-906050
location ::: Computer Center | Vienna University of Economics | Austria




--
e-mail   ::: Leo.Bergolth (at) wu-wien.ac.at
fax      ::: +43-1-31336-906050
location ::: Computer Center | Vienna University of Economics | Austria


--- src/pmacctd.c.orig	2008-02-10 11:21:42.237534087 +0100
+++ src/pmacctd.c	2008-02-09 16:53:30.607813195 +0100
@@ -476,7 +476,8 @@
   }
   else Log(LOG_INFO, "OK ( default/core ): link type is: %d\n", device.link_type); 
 
-  if (device.link_type != DLT_EN10MB && device.link_type != DLT_IEEE802) {
+  if (device.link_type != DLT_EN10MB && device.link_type != DLT_IEEE802
+      && device.link_type != DLT_LINUX_SLL) {
     list = plugins_list;
     while (list) {
       if ((list->cfg.what_to_count & COUNT_SRC_MAC) || (list->cfg.what_to_count & COUNT_DST_MAC)) {

_______________________________________________
pmacct-discussion mailing list
http://www.pmacct.net/#mailinglists