Re: [pmacct-discussion] uacctd documentation
On Fri, Mar 26, 2010 at 11:41:44PM +, Paolo Lucente wrote: I see. It's just not clear whether you are using pmacctd compiled against vanilla libpcap. If this is the case, i can advice to give a try to PF_RING. The kernel module can be configured for sampling by passing the sample_rate parameter. At a glance, it would just seem fitting better your scenario. In case you want to go this way, please use the code from the CVS as the build sub-system (configure script, etc.) has been patched to recognize presence of PF_RING. This will indeed make it in the upcoming release 0.12.1. Ah - didn't realize that PF_RING could sample on it's end. I tried PF_RING previously and actually ran into worse performance than non PF_RING, but I didn't configure sampling. Looking into that though, my PF_RING installation doesn't seem to support it: [r...@hmspmacct002 ~]# modprobe pf_ring sample_rate=2000 insmod /lib/modules/2.6.18-128.1.16.el5/kernel/net/pf_ring/pf_ring.ko sample_rate=2000 FATAL: Error inserting pf_ring (/lib/modules/2.6.18-128.1.16.el5/kernel/net/pf_ring/pf_ring.ko): Unknown symbol in module, or unknown parameter (see dmesg) [r...@hmspmacct002 ~]# dmesg | tail -n 1 pf_ring: Unknown parameter `sample_rate' I rebuilt PF_RING from SVN today - it looks like the pf_ring module has and understands stuff about sample_rate. Do I miss some step to enable this functionality? Thanks for your help, Ross -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie signature.asc Description: Digital signature ___ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
Re: [pmacct-discussion] uacctd documentation
On Mon, Mar 29, 2010 at 11:21:07AM -0400, Ross Vandegrift wrote: Ah - didn't realize that PF_RING could sample on it's end. I tried PF_RING previously and actually ran into worse performance than non PF_RING, but I didn't configure sampling. Aha - at least I fixed this. Looks like there were leavings of an old version of pcap being picked up as a shared lib. PF_RING alone has dropped my CPU to 25-40%, which is quite a bit better. Still haven't found anything on the sampling though. -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie signature.asc Description: Digital signature ___ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
Re: [pmacct-discussion] uacctd documentation
Hi Ross, On Thu, Mar 25, 2010 at 09:57:05AM -0400, Ross Vandegrift wrote: Thanks for the examples! I'm having trouble with the iptables piece of the puzzle though. I suspect this is because I'm mirroring traffic to this server and the L2 destination doesn't match any address present on the server. I've tried add ebtables dnat to rewrite the destination MAC of incoming frames to the local interface address, but this doesn't work. I'm curious: if mirroring traffic to the box, why resorting to uacctd and iptables/etables? You have pmacctd (libpcap-based) readily available for such scenario. With uacctd covering the case where traffic is being cleanly routed through (or to) the Linux box. Cheers, Paolo ___ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
Re: [pmacct-discussion] uacctd documentation
On Fri, Mar 26, 2010 at 01:29:13PM +, Paolo Lucente wrote: I'm curious: if mirroring traffic to the box, why resorting to uacctd and iptables/etables? You have pmacctd (libpcap-based) readily available for such scenario. With uacctd covering the case where traffic is being cleanly routed through (or to) the Linux box. I'm curious if I can acheive better performance for generating sflow data. My plan was to use the iptables statistics module to do the sampling, to ensure that only sampled packets were being sent to userspace. Since my sampling target is around 1:2000, this has the potential to cut down on a lot of work sending packets to userspace that will be ignored. Neil at InMon suggested this as a possible tactic for more efficient sflow generation than sfacctd when looking at around 3Gb/s and 500kpps. pmacctd appears to be keeping up, but around 55-80% CPU. Traffic will continue to grow, and I'd like to see if I can't get performance better to make the system last longer. Ross -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie signature.asc Description: Digital signature ___ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
Re: [pmacct-discussion] uacctd documentation
Hi Ross, On Fri, Mar 26, 2010 at 02:46:51PM -0400, Ross Vandegrift wrote: I'm curious if I can acheive better performance for generating sflow data. My plan was to use the iptables statistics module to do the sampling, to ensure that only sampled packets were being sent to userspace. Since my sampling target is around 1:2000, this has the potential to cut down on a lot of work sending packets to userspace that will be ignored. Neil at InMon suggested this as a possible tactic for more efficient sflow generation than sfacctd when looking at around 3Gb/s and 500kpps. pmacctd appears to be keeping up, but around 55-80% CPU. Traffic will continue to grow, and I'd like to see if I can't get performance better to make the system last longer. I see. It's just not clear whether you are using pmacctd compiled against vanilla libpcap. If this is the case, i can advice to give a try to PF_RING. The kernel module can be configured for sampling by passing the sample_rate parameter. At a glance, it would just seem fitting better your scenario. In case you want to go this way, please use the code from the CVS as the build sub-system (configure script, etc.) has been patched to recognize presence of PF_RING. This will indeed make it in the upcoming release 0.12.1. Cheers, Paolo ___ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
Re: [pmacct-discussion] uacctd documentation
On Wed, Mar 24, 2010 at 05:30:23PM -0700, Stig Thormodsrud wrote: Then I add the interfaces I want to iptables. vya...@r1# iptables -t raw -nvL PREROUTING Chain PREROUTING (policy ACCEPT 30 packets, 4236 bytes) pkts bytes target prot opt in out source destination 1608 85539 ULOG all -- eth1 * 0.0.0.0/0 0.0.0.0/0 ULOG copy_range 64 nlgroup 2 queue_threshold 10 0 0 ULOG all -- eth1.101 * 0.0.0.0/0 0.0.0.0/0 ULOG copy_range 64 nlgroup 2 queue_threshold 10 4710 1027K ULOG all -- eth0 * 0.0.0.0/0 0.0.0.0/0 ULOG copy_range 64 nlgroup 2 queue_threshold 10 I happen to choose the raw table to see the packets before nat/firewall, but if you hook into netfilter in the POSTROUTING chain then you can also get the output interface in the netflow records. Hi Stig, Thanks for the examples! I'm having trouble with the iptables piece of the puzzle though. I suspect this is because I'm mirroring traffic to this server and the L2 destination doesn't match any address present on the server. I've tried add ebtables dnat to rewrite the destination MAC of incoming frames to the local interface address, but this doesn't work. I'd expect these frames to show up in the FORWARD chain in either ebtables or iptables, but if I add ACCEPT rules that match anything on the interface the counters never increment. tcpdump and sfacctd confirm that traffic is arriving. Thanks, Ross -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie signature.asc Description: Digital signature ___ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
Re: [pmacct-discussion] uacctd documentation
Ross Vandegrift wrote: Hello, Is there any documentation describing the setup required for uacctd? I'd like to check this out, but can't quite figure out all the steps I need to do in order to get things working. Thanks, Ross Below is an example of uacctd that I'm running: vya...@r1# cat /etc/pmacct/uacctd.conf ! autogenerated by /opt/vyatta/sbin/vyatta-netflow.pl daemonize: true promisc: false pidfile: /var/run/uacctd.pid imt_path: /tmp/uacctd.pipe uacctd_group: 2 refresh_maps: true pre_tag_map: /etc/pmacct/int_map aggregate: tag,src_mac,dst_mac,vlan,src_host,dst_host,src_port,dst_port,proto,tos,flows syslog: daemon plugins: memory,nfprobe[10.1.0.21-2055] nfprobe_receiver[10.1.0.21-2055]: 10.1.0.21:2055 nfprobe_version[10.1.0.21-2055]: 9 nfprobe_engine[10.1.0.21-2055]: 0:0 Then I add the interfaces I want to iptables. vya...@r1# iptables -t raw -nvL PREROUTING Chain PREROUTING (policy ACCEPT 30 packets, 4236 bytes) pkts bytes target prot opt in out source destination 1608 85539 ULOG all -- eth1 * 0.0.0.0/0 0.0.0.0/0 ULOG copy_range 64 nlgroup 2 queue_threshold 10 0 0 ULOG all -- eth1.101 * 0.0.0.0/0 0.0.0.0/0 ULOG copy_range 64 nlgroup 2 queue_threshold 10 4710 1027K ULOG all -- eth0 * 0.0.0.0/0 0.0.0.0/0 ULOG copy_range 64 nlgroup 2 queue_threshold 10 I happen to choose the raw table to see the packets before nat/firewall, but if you hook into netfilter in the POSTROUTING chain then you can also get the output interface in the netflow records. cheers, stig ___ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
