We have a very modest box with PF_RING and 2 Snort (2.9.5.6 with daq 2.0.1)
processes monitoring a link (one interface) that peaks at 50MB. This was an
initial test setup (installation, performance, upgrades, etc...) to an upcoming
hardware upgrade.
The box was running PF_RING version 5.6.2 (no revision was showing) with the
PF_RING aware NIC driver e1000e. One of the major reasons this sensor was setup
is to monitor P2P. At peak times and during ongoing P2P, the box was crunching
packets with almost zero drops (~ 6000 rules). This has changed after we
upgraded to PF_RING from SVN (version 5.6.3 Revision 7331) and Snort (2.9.6.0
with daq 2.0.2). After the upgrade, PF_RING starts dropping packets when P2P
happens.
I do not have the statistics before the upgrade (sorry), configuration wise, it
is the same for both setups. Running PF_RING in transparent_mode 2 :
cat /proc/net/pf_ring/info
PF_RING Version : 5.6.3 ($Revision: 7331$)
Total rings : 2
Standard (non DNA) Options
Ring slots : 65536
Slot version : 15
Capture TX : No [RX only]
IP Defragment : No
Socket Mode : Standard
Transparent mode : No [mode 2]
Total plugins : 0
Cluster Fragment Queue : 0
Cluster Fragment Discard : 1385
Everything runs fine until a P2P "session" kicks in. The distribution of the
packets seems to favor on process over the other. Clearly the Num Free Slots of
the first process is 0:
/proc/net/pf_ring/14815-eth1.6
Appl. Name : snort-cluster-11-socket-0
Tot Packets : 295195537
Tot Pkt Lost : 73299631
TX: Send Errors : 0
Reflect: Fwd Errors: 0
Min Num Slots : 78028
Num Free Slots : 0
/proc/net/pf_ring/14826-eth1.7
Appl. Name : snort-cluster-11-socket-0
Tot Packets : 89023033
Tot Pkt Lost : 0
TX: Send Errors : 0
Reflect: Fwd Errors: 0
Min Num Slots : 78028
Num Free Slots : 78010
/proc/net/pf_ring/14815-eth1.6
Appl. Name : snort-cluster-11-socket-0
Tot Packets : 298773670
Tot Pkt Lost : 74293208
TX: Send Errors : 0
Reflect: Fwd Errors: 0
Min Num Slots : 78028
Num Free Slots : 0
/proc/net/pf_ring/14826-eth1.7
Appl. Name : snort-cluster-11-socket-0
Tot Packets : 89169841
Tot Pkt Lost : 0
TX: Send Errors : 0
Reflect: Fwd Errors: 0
Min Num Slots : 78028
Num Free Slots : 77928
And from snort stats:
/var/snort/snort-1.stats pkt_drop_percent as 34.181
/var/snort/snort-2.stats pkt_drop_percent as 0.000
After the P2P session ends (note the value of [Num Free Slots] of the first
snort process). The value of the [Tot Pkt Lost] is right after the P2P session
ends:
/proc/net/pf_ring/14815-eth1.6
Appl. Name : snort-cluster-11-socket-0
Tot Packets : 350584381
Tot Pkt Lost : 94985249
TX: Send Errors : 0
Reflect: Fwd Errors: 0
Min Num Slots : 78028
Num Free Slots : 77927
/proc/net/pf_ring/14826-eth1.7
Appl. Name : snort-cluster-11-socket-0
Tot Packets : 96783586
Tot Pkt Lost : 0
TX: Send Errors : 0
Reflect: Fwd Errors: 0
Min Num Slots : 78028
Num Free Slots : 77961
/var/snort/snort-1.stats pkt_drop_percent as 0.000
/var/snort/snort-2.stats pkt_drop_percent as 0.000
Currently we are not binding processes to cores, that is something I am going
to test soon to see the difference. The command running snort is wrapped by a
loop and using the following:
/usr/local/snort/bin/snort -c /usr/local/snort/etc/snort.conf -i eth1 -l
/var/log/snort/snort-1 --perfmon-file /var/snort/snort-1.stats -g snort -u
snort --pid-path=/var/run -R -1
/usr/local/snort/bin/snort -c /usr/local/snort/etc/snort.conf -i eth1 -l
/var/log/snort/snort-2 --perfmon-file /var/snort/snort-2.stats -g snort -u
snort --pid-path=/var/run -R -2
The PF_RING configurations are stored in the daq configuration section within
snort.conf file:
more /usr/local/snort/etc/snort.conf | grep daq
# Configure DAQ related options for inline operation. For more information, see
README.daq
config daq: pfring
config daq_dir: /usr/local/lib/daq
config daq_mode: passive
config daq_var: clusterid=11
I know that the modest hardware (CPU) may have a major role in this but the
fact that such drops were not observed in the previous setup/before the upgrade
makes me wonder if I missed something in the middle or if there were new
changes I am not aware of. Any leads or help are appreciated.
Thanks.
YM
_______________________________________________
Ntop-misc mailing list
[email protected]
http://listgateway.unipi.it/mailman/listinfo/ntop-misc
