Netflow Accounting mit pflow(4)

D

dunkel

Member
Hallo,

ich plane unsere derzeitigen FreeBSD-Router durch OpenBSD-Router zu ersetzen. Bisher wurden die Netflows auf dem Router via netgraph und ng_netflow erstellt und an den Receiver geschickt.

Da OpenBSD mittlerweile auch ueber eine Kernel-Implementierung fuer Netflow verfuegt (pflow), moechte ich gerne diese nutzen.
An sich funktioniert das Ganze auch gut, allerdings sind alle Flows doppelt vorhanden.
Das Problem scheint hier mit den State-Table-Eintraegen zusammenzuhaengen.

Ein Beispiel:

Auf dem Rechner deb-01 laeuft flow-receive als Netflow Collector:
Code: 
deb-01:~# flow-receive 0.0.0.0/0.0.0.0/2100 -o bsdflow
flow-receive: setsockopt(size=4194304)

flow-receive: New exporter: time=1294143869 src_ip=192.168.89.150 dst_ip=192.168.89.52 d_version=5

Der Router rtr-fra-01 (mit der enstprechenden Konfiguration fuer pflow s.u.) befindet sich zwischen 2 weiteren Rechnern, auf denen ich Performance Tests ausfuehre.

Code: 
rtr-fra-01# cat /etc/hostname.pflow0
flowsrc 192.168.89.150 flowdst 192.168.89.52:2100
rtr-fra-01# grep -v ^\# /etc/pf.conf 
set skip on lo
pass keep state (pflow)         # to establish keep-state
block in on ! lo0 proto tcp to port 6000:6010
rtr-fra-01#

Auf einem der Rechner schicke ich nun Testdaten an den korrespondierenden Server.

Code: 
grabnebel:~# nuttcp -i1 192.168.92.55
  102.0721 MB /   1.00 sec =  856.2173 Mbps
  111.3174 MB /   1.00 sec =  933.8174 Mbps
  111.6529 MB /   1.00 sec =  936.6071 Mbps
  111.6529 MB /   1.00 sec =  936.5912 Mbps
  111.6529 MB /   1.00 sec =  936.6240 Mbps
  111.6529 MB /   1.00 sec =  936.6287 Mbps
  111.6571 MB /   1.00 sec =  936.6241 Mbps
  111.6529 MB /   1.00 sec =  936.6296 Mbps
  111.6598 MB /   1.00 sec =  936.6725 Mbps
  111.6529 MB /   1.00 sec =  936.5959 Mbps

 1108.1875 MB /  10.01 sec =  928.3151 Mbps 6 %TX 20 %RX
grabnebel:~#

Im State-Table von pf sehe ich entsprechend zwei Eintraege - einen pro Richtung.

Code: 
rtr-fra-01# pfctl -vss | grep -A2 5001 
all tcp 192.168.92.55:5001 <- 192.168.89.55:50609       FIN_WAIT_2:FIN_WAIT_2
   [3659736762 + 5888] wscale 6  [491808162 + 1749184] wscale 6
   age 00:00:39, expires in 00:01:01, 802503:402038 pkts, 1203748980:20916988 bytes, rule 0, pflow
all tcp 192.168.89.55:50609 -> 192.168.92.55:5001       FIN_WAIT_2:FIN_WAIT_2
   [491808162 + 1749184] wscale 6  [3659736762 + 5888] wscale 6
   age 00:00:39, expires in 00:01:01, 802503:402038 pkts, 1203748980:20916988 bytes, rule 0, pflow
rtr-fra-01#

Das Problem scheint zu sein, dass die Eintraege zwar einen Richtungsunterschied aufweisen, aber jeweils RX u. TX Traffic-Daten angezeigt werden, sodass diese entsprechend doppelt exportiert werden.

Code: 
deb-01:~# flow-print < bsdflow | grep 5001
192.168.89.55    192.168.92.55    6     50609    5001     1203748980  802503    
192.168.92.55    192.168.89.55    6     5001     50609    20916988    402038    
192.168.89.55    192.168.92.55    6     50609    5001     1203748980  802503    
192.168.92.55    192.168.89.55    6     5001     50609    20916988    402038    
deb-01:~#

In Summe bedeutet das also, dass alle Daten doppelt accountet werden.
Hat jemand eine Idee, wie ich das Problem auf dem Router loesen kann?

Gruss,
Bernd
 
Die PF-Regeln sind bereits aufgefuehrt. Da sich das Ganze im Teststatium befindet, reduziert sich das Regelwerk auf die Pflow-Regel.

dunkel schrieb:
Code: 
rtr-fra-01# grep -v ^\# /etc/pf.conf 
set skip on lo
pass keep state (pflow)         # to establish keep-state
block in on ! lo0 proto tcp to port 6000:6010
rtr-fra-01#
Zum Vergrößern anklicken....

Ich hatte auch schon mit einer einschraenkenden pf-Config getestet, um nicht soviel unsinniges in den Flows zu haben.

Code: 
set skip on lo
pass quick proto tcp from 192.168.89.55 to 192.168.92.55 port 5001 keep state (pflow)
pass keep state
block in on ! lo0 proto tcp to port 6000:6010

Das Ergebnis bleibt allerdings das Gleiche.
 
hm,

wenn ich mir die states anschaue so sieht das fuer mich eher wie 2 states aus
ergo pro state 1x in 1x out pfflow

warum 2 states ?
ggf weil die software 2 verbindungen aufbaut ? aufgebaut hat ( wegen finwait2 )
schonmal mit einem eifachen webserver gestestet ?

holger
 
Ein Webserverzugriff stellt sich im State-Table genauso dar.
Code: 
all tcp 192.168.92.55:80 <- 192.168.89.55:53772       FIN_WAIT_2:FIN_WAIT_2
   [347424212 + 2669568] wscale 6  [4273781935 + 5824] wscale 6
   age 00:00:40, expires in 00:01:12, 38969:218244 pkts, 2083623:327343071 bytes, rule 1, pflow
all tcp 192.168.89.55:53772 -> 192.168.92.55:80       FIN_WAIT_2:FIN_WAIT_2
   [4273781935 + 5824] wscale 6  [347424212 + 2669568] wscale 6
   age 00:00:40, expires in 00:01:12, 38969:218244 pkts, 2083623:327343071 bytes, rule 1, pflow

Selbst ein simples netcat erzeugt 2 State-Table-Eintraege. Es scheint sich also um das dafault-Verhalten zu handeln.

Entsprechend werden auch wieder die redundanten Flows exportiert.
Code: 
bsd-01# flow-print < bsdflow                                                   
srcIP            dstIP            prot  srcPort  dstPort  octets      packets
192.168.89.55    192.168.92.55    6     53772    80       2083623     38969     
192.168.92.55    192.168.89.55    6     80       53772    327343071   218244    
192.168.89.55    192.168.92.55    6     53772    80       2083623     38969     
192.168.92.55    192.168.89.55    6     80       53772    327343071   218244    
bsd-01#
 
Zuletzt bearbeitet:
dunkel schrieb:
Selbst ein simples netcat erzeugt 2 State-Table-Eintraege. Es scheint sich also um das dafault-Verhalten zu handeln.
Zum Vergrößern anklicken....

AFAIK bekommst Du einen State pro Interface, und da sind bei einem Router wenig ueberraschend ja immer zwei im Spiel ;-)

Wenn Du mal Traffic nur zum (oder vom) Router generierst, solltest Du entsprechend nur einen State dazu sehen.

Du muesstest also die Regel mit dem pflow z.B. explizit an ein Interface nageln. Falls der Router nicht nur zwischen internen Netzen routet, sondern auch in Richtung Upstream, und es Dir nicht um den internen Traffic geht, waere dann also das Interface, an dem Upstream haengt, der Wunschkandidat.
 
Danke fuer den Tipp.
Mit
Code: 
pass out keep state (pflow)
kann ich alle Interfaces abdecken, und bekomme auch nur einen State mit pflow flag.
 
hi

wollte schon sagen da ich das vehalten so bei mir nicht habe .
jedoch binde ich meine regeln immer direkt ans interface


quasi

pass out on if from bla to blu

oder nur
pass quick on if from bal to blub

holger
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben