Hi Alfredo,
Thanks for your suggestion!
I've changed pfdump.c to use cluster_per_flow_2_tuple:
if(clusterId > 0) {
rc = pfring_set_cluster(pd, clusterId, cluster_per_flow_2_tuple);
printf("pfring_set_cluster returned %d\n", rc);
}
I then re-ran the test as follows:
Replayed a TCP stream with 11 packets onto eth1:
sudo tcpreplay -i eth1 -M10 testmyids.pcap
sending out eth1
processing file: testmyids.pcap
Actual: 11 packets (1062 bytes) sent in 0.00 seconds
Rated: inf bps, inf Mbps, inf pps
Statistics for network device: eth1
Attempted packets: 11
Successful packets: 11
Failed packets: 0
Retried packets (ENOBUFS): 0
Retried packets (EAGAIN): 0
Ran two instances of pfdump on eth1 with same clusterId but neither of
them saw traffic this time:
sudo ./pfdump -l77 -i eth1 -w instance1.pcap
Using PF_RING v.5.5.3
Capturing from eth1 [00:0C:29:5F:58:D8][ifIndex: 3]
# Device RX channels: 1
pfring_set_cluster returned 0
1 sec pkts 0 drop 0 bytes 0 | pkts 0 bytes 0 drop 0
2 sec pkts 0 drop 0 bytes 0 | pkts 0 bytes 0 drop 0
3 sec pkts 0 drop 0 bytes 0 | pkts 0 bytes 0 drop 0
4 sec pkts 0 drop 0 bytes 0 | pkts 0 bytes 0 drop 0
5 sec pkts 0 drop 0 bytes 0 | pkts 0 bytes 0 drop 0
6 sec pkts 0 drop 0 bytes 0 | pkts 0 bytes 0 drop 0
7 sec pkts 0 drop 0 bytes 0 | pkts 0 bytes 0 drop 0
8 sec pkts 0 drop 0 bytes 0 | pkts 0 bytes 0 drop 0
9 sec pkts 0 drop 0 bytes 0 | pkts 0 bytes 0 drop 0
10 sec pkts 0 drop 0 bytes 0 | pkts 0 bytes 0 drop 0
11 sec pkts 0 drop 0 bytes 0 | pkts 0 bytes 0 drop 0
12 sec pkts 0 drop 0 bytes 0 | pkts 0 bytes 0 drop 0
13 sec pkts 0 drop 0 bytes 0 | pkts 0 bytes 0 drop 0
^CLeaving...
14 sec pkts 0 drop 0 bytes 0 | pkts 0 bytes 0 drop 0
sudo ./pfdump -l77 -i eth1 -w instance2.pcap
Using PF_RING v.5.5.3
Capturing from eth1 [00:0C:29:5F:58:D8][ifIndex: 3]
# Device RX channels: 1
pfring_set_cluster returned 0
1 sec pkts 0 drop 0 bytes 0 | pkts 0 bytes 0 drop 0
2 sec pkts 0 drop 0 bytes 0 | pkts 0 bytes 0 drop 0
3 sec pkts 0 drop 0 bytes 0 | pkts 0 bytes 0 drop 0
4 sec pkts 0 drop 0 bytes 0 | pkts 0 bytes 0 drop 0
5 sec pkts 0 drop 0 bytes 0 | pkts 0 bytes 0 drop 0
6 sec pkts 0 drop 0 bytes 0 | pkts 0 bytes 0 drop 0
7 sec pkts 0 drop 0 bytes 0 | pkts 0 bytes 0 drop 0
8 sec pkts 0 drop 0 bytes 0 | pkts 0 bytes 0 drop 0
9 sec pkts 0 drop 0 bytes 0 | pkts 0 bytes 0 drop 0
10 sec pkts 0 drop 0 bytes 0 | pkts 0 bytes 0 drop 0
11 sec pkts 0 drop 0 bytes 0 | pkts 0 bytes 0 drop 0
12 sec pkts 0 drop 0 bytes 0 | pkts 0 bytes 0 drop 0
^CLeaving...
13 sec pkts 0 drop 0 bytes 0 | pkts 0 bytes 0 drop 0
tcpdump -nnvvr instance1.pcap
reading from file instance1.pcap, link-type EN10MB (Ethernet)
tcpdump -nnvvr instance2.pcap
reading from file instance2.pcap, link-type EN10MB (Ethernet)
I've repeated this a few times and get the same result each time.
Any ideas why cluster_per_flow_2_tuple wouldn't be passing the traffic?
Thanks!
Doug
On Sun, Jun 2, 2013 at 12:41 PM, Alfredo Cardigliano
<[email protected]> wrote:
> Hi Doug
> the code in pfcount sets the cluster mode to round-robin,
> for flow coherency you should change it to (for instance)
> cluster_per_flow_2_tuple.
> The daq-pfring code sets the cluster mode to cluster_per_flow_2_tuple by
> default.
>
> Best Regards
> Alfredo
>
> Index: pfcount.c
> ===================================================================
> --- pfcount.c (revisione 6336)
> +++ pfcount.c (copia locale)
> @@ -924,7 +924,7 @@
> #endif
>
> if(clusterId > 0) {
> - rc = pfring_set_cluster(pd, clusterId, cluster_round_robin);
> + rc = pfring_set_cluster(pd, clusterId, cluster_per_flow_2_tuple);
> printf("pfring_set_cluster returned %d\n", rc);
> }
>
> On Jun 2, 2013, at 2:54 PM, Doug Burks <[email protected]> wrote:
>
> I copied the clusterId code from pfcount and pasted into pfdump and
> compiled it. Then tested with a fresh pcap of "curl testmyids.com":
>
> tcpdump -nnr testmyids.pcap
> reading from file testmyids.pcap, link-type EN10MB (Ethernet)
> 12:37:21.846561 IP 172.16.116.128.44229 > 217.160.51.31.80: Flags [S],
> seq 2183306783, win 42340, options [mss 1460,sackOK,TS val 13599714
> ecr 0,nop,wscale 11], length 0
> 12:37:21.963023 IP 217.160.51.31.80 > 172.16.116.128.44229: Flags
> [S.], seq 3354284181, ack 2183306784, win 64240, options [mss 1460],
> length 0
> 12:37:21.963070 IP 172.16.116.128.44229 > 217.160.51.31.80: Flags [.],
> ack 1, win 42340, length 0
> 12:37:21.963268 IP 172.16.116.128.44229 > 217.160.51.31.80: Flags
> [P.], seq 1:166, ack 1, win 42340, length 165
> 12:37:21.963423 IP 217.160.51.31.80 > 172.16.116.128.44229: Flags [.],
> ack 166, win 64240, length 0
> 12:37:22.083864 IP 217.160.51.31.80 > 172.16.116.128.44229: Flags
> [P.], seq 1:260, ack 166, win 64240, length 259
> 12:37:22.083906 IP 172.16.116.128.44229 > 217.160.51.31.80: Flags [.],
> ack 260, win 42081, length 0
> 12:37:22.084118 IP 172.16.116.128.44229 > 217.160.51.31.80: Flags
> [F.], seq 166, ack 260, win 42081, length 0
> 12:37:22.085362 IP 217.160.51.31.80 > 172.16.116.128.44229: Flags [.],
> ack 167, win 64239, length 0
> 12:37:22.202741 IP 217.160.51.31.80 > 172.16.116.128.44229: Flags
> [FP.], seq 260, ack 167, win 64239, length 0
> 12:37:22.202786 IP 172.16.116.128.44229 > 217.160.51.31.80: Flags [.],
> ack 261, win 42081, length 0
>
> I then started the two instances of pfdump using the same clusterId
> and then replayed the 11 packets with tcpreplay:
> sudo tcpreplay -i eth1 -M10 testmyids.pcap
> sending out eth1
> processing file: testmyids.pcap
> Actual: 11 packets (1062 bytes) sent in 0.01 seconds
> Rated: 106200.0 bps, 0.81 Mbps, 1100.00 pps
> Statistics for network device: eth1
> Attempted packets: 11
> Successful packets: 11
> Failed packets: 0
> Retried packets (ENOBUFS): 0
> Retried packets (EAGAIN): 0
>
> FIRST INSTANCE OF PFDUMP
>
> sudo ./pfdump -l77 -i eth1 -w instance1.pcap
> Using PF_RING v.5.5.3
> Capturing from eth1 [00:0C:29:5F:58:D8][ifIndex: 3]
> # Device RX channels: 1
> pfring_set_cluster returned 0
> <snip>
> 241 sec pkts 6 drop 0 bytes 500 | pkts 6 bytes 500 drop 0
> <snip>
>
> tcpdump -nnr instance1.pcap
> reading from file instance1.pcap, link-type EN10MB (Ethernet)
> 12:38:55.886037 IP 172.16.116.128.44229 > 217.160.51.31.80: Flags [S],
> seq 2183306783, win 42340, options [mss 1460,sackOK,TS val 13599714
> ecr 0,nop,wscale 11], length 0
> 12:38:55.886889 IP 172.16.116.128.44229 > 217.160.51.31.80: Flags [.],
> ack 3354284182, win 42340, length 0
> 12:38:55.887325 IP 217.160.51.31.80 > 172.16.116.128.44229: Flags [.],
> ack 165, win 64240, length 0
> 12:38:55.887986 IP 172.16.116.128.44229 > 217.160.51.31.80: Flags [.],
> ack 260, win 42081, length 0
> 12:38:55.888306 IP 217.160.51.31.80 > 172.16.116.128.44229: Flags [.],
> ack 166, win 64239, length 0
> 12:38:55.888741 IP 172.16.116.128.44229 > 217.160.51.31.80: Flags [.],
> ack 261, win 42081, length 0
>
> SECOND INSTANCE OF PFDUMP
>
> sudo ./pfdump -l77 -i eth1 -w instance2.pcap
> Using PF_RING v.5.5.3
> Capturing from eth1 [00:0C:29:5F:58:D8][ifIndex: 3]
> # Device RX channels: 1
> pfring_set_cluster returned 0
> <snip>
> 16 sec pkts 5 drop 0 bytes 826 | pkts 5 bytes 826 drop 0
> 17 sec pkts 0 drop 0 bytes 0 | pkts 5 bytes 826 drop 0
> 18 sec pkts 0 drop 0 bytes 0 | pkts 5 bytes 826 drop 0
> 19 sec pkts 0 drop 0 bytes 0 | pkts 5 bytes 826 drop 0
> ^CLeaving...
> 20 sec pkts 0 drop 0 bytes 0 | pkts 5 bytes 826 drop 0
>
> tcpdump -nnr instance2.pcap
> reading from file instance2.pcap, link-type EN10MB (Ethernet)
> 12:38:55.886499 IP 217.160.51.31.80 > 172.16.116.128.44229: Flags
> [S.], seq 3354284181, ack 2183306784, win 64240, options [mss 1460],
> length 0
> 12:38:55.887129 IP 172.16.116.128.44229 > 217.160.51.31.80: Flags
> [P.], seq 1:166, ack 1, win 42340, length 165
> 12:38:55.887666 IP 217.160.51.31.80 > 172.16.116.128.44229: Flags
> [P.], seq 1:260, ack 166, win 64240, length 259
> 12:38:55.888117 IP 172.16.116.128.44229 > 217.160.51.31.80: Flags
> [F.], seq 166, ack 260, win 42081, length 0
> 12:38:55.888530 IP 217.160.51.31.80 > 172.16.116.128.44229: Flags
> [FP.], seq 260, ack 167, win 64239, length 0
>
> As you can see, the first instance sees 6 packets and the second
> instance sees 5 packets. Shouldn't all 11 packets in that TCP stream
> be sent to the same instance?
>
> Thanks!
>
> Doug
>
>
> On Sun, Jun 2, 2013 at 7:11 AM, Doug Burks <[email protected]> wrote:
>
> Hi Luca,
>
> I can repeat the test with pfdump when I'm back at my computer, but is there
> something in particular you're looking for that wasn't in the pfcount output
> I provided? Shouldn't all the traffic from that one TCP stream be sent to
> one instance of pfcount?
>
> Thanks,
> Doug
>
>
> On Sunday, June 2, 2013, Luca Deri wrote:
>
>
> Hi
> You're right. We need to add it: you can c&p the code from pfcount in the
> meantime
>
> Luca
>
> On Jun 2, 2013, at 1:54 AM, Doug Burks <[email protected]> wrote:
>
> I have pfdump now but I don't see a cluster-id option. Did you mean
> pfcount? If I run 2 instances of pfcount with the same cluster-id and
> then replay a pcap with 10 packets all belonging to the same TCP
> stream, I get 5 packets being sent to each pfcount instance.
> Shouldn't all 10 packets be sent to 1 instance?
>
> First instance:
>
> sudo ./pfcount -c77 -i eth1
> <snip>
> =========================
> Absolute Stats: [5 pkts rcvd][5 pkts filtered][0 pkts dropped]
> Total Pkts=5/Dropped=0.0 %
> 5 pkts - 434 bytes [0.38 pkt/sec - 0.00 Mbit/sec]
> =========================
> Actual Stats: 5 pkts [1'000.75 ms][5.00 pps/0.00 Gbps]
> =========================
>
> Second instance:
>
> sudo ./pfcount -c77 -i eth1
> <snip>
> =========================
> Absolute Stats: [5 pkts rcvd][5 pkts filtered][0 pkts dropped]
> Total Pkts=5/Dropped=0.0 %
> 5 pkts - 834 bytes [0.62 pkt/sec - 0.00 Mbit/sec]
> =========================
> Actual Stats: 5 pkts [1'001.39 ms][4.99 pps/0.00 Gbps]
> =========================
>
> The replayed pcap is just ten packets that result from "curl
> testmyids.com":
>
> tcpdump -nnr testmyids.pcap
> reading from file testmyids.pcap, link-type EN10MB (Ethernet)
> 11:46:11.691648 IP 192.168.111.111.50154 > 217.160.51.31.80: Flags
> [S], seq 3840903154, win 42340, options [mss 1460,sackOK,TS val
> 20137183 ecr 0,nop,wscale 11], length 0
> 11:46:11.808833 IP 217.160.51.31.80 > 192.168.111.111.50154: Flags
> [S.], seq 2859277445, ack 3840903155, win 5840, options [mss
> 1460,nop,wscale 7], length 0
> 11:46:11.808854 IP 192.168.111.111.50154 > 217.160.51.31.80: Flags
> [.], ack 1, win 21, length 0
> 11:46:11.809083 IP 192.168.111.111.50154 > 217.160.51.31.80: Flags
> [P.], seq 1:166, ack 1, win 21, length 165
> 11:46:11.927518 IP 217.160.51.31.80 > 192.168.111.111.50154: Flags
> [.], ack 166, win 54, length 0
> 11:46:12.036708 IP 217.160.51.31.80 > 192.168.111.111.50154: Flags
> [P.], seq 1:260, ack 166, win 54, length 259
> 11:46:12.036956 IP 192.168.111.111.50154 > 217.160.51.31.80: Flags
> [.], ack 260, win 21, length 0
> 11:46:12.037206 IP 192.168.111.111.50154 > 217.160.51.31.80: Flags
> [F.], seq 166, ack 260, win 21, length 0
> 11:46:12.154641 IP 217.160.51.31.80 > 192.168.111.111.50154: Flags
> [F.], seq 260, ack 167, win 54, length 0
> 11:46:12.154888 IP 192.168.111.111.50154 > 217.160.51.31.80: Flags
> [.], ack 261, win 21, length 0
>
> Any ideas?
>
> Thanks,
> Doug
>
> On Sat, Jun 1, 2013 at 5:48 PM, Doug Burks <[email protected]> wrote:
>
> On Sat, Jun 1, 2013 at 10:24 AM, Luca Deri <[email protected]> wrote:
>
> Hi Doug
>
> On Jun 1, 2013, at 6:59 AM, Doug Burks <[email protected]> wrote:
>
> Hello all,
>
> I recently packaged PF_RING 5.5.3 for my Security Onion distro:
>
> http://securityonion.blogspot.com/2013/05/pfring-553-packages-now-available.html
>
> Perhaps I'm missing something, but I'm seeing some behavior I don't
> remember seeing in 5.5.2 or previous versions of PF_RING.
>
> Here are my testing parameters:
> - starting off with a good test, if I run just one instance of snort,
> I get an alert from rule 2100498 for EACH time I run "curl
> testmyids.com"
> - if I increase to two instances of snort with the same cluster-id, I
> get NO alerts when running "curl testmyids.com"
> - if I set the daq clustermode to 2, I get NO alerts when running
> "curl > _______________________________________________
>
>
> Ntop-misc mailing list
> [email protected]
> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>
>
> _______________________________________________
> Ntop-misc mailing list
> [email protected]
> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>
>
>
>
> --
> Doug Burks
> http://securityonion.blogspot.com
>
>
>
>
> --
> Doug Burks
> http://securityonion.blogspot.com
> _______________________________________________
> Ntop-misc mailing list
> [email protected]
> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>
>
>
> _______________________________________________
> Ntop-misc mailing list
> [email protected]
> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>
--
Doug Burks
http://securityonion.blogspot.com
_______________________________________________
Ntop-misc mailing list
[email protected]
http://listgateway.unipi.it/mailman/listinfo/ntop-misc
