Hi Paolo, Thanks for the quick response. I just downloaded the code and it looks like it would be fairly easy for me to add the input interface into the netflow record. I'll let you know if I get it working.
The output interface would be nice too, but I know that a lot more complicated to get at since the routing decision hasn't happen yet. I noticed the FAQ mentions using either libpcap-mmap or PF_RING to get better performance than pcap. Has there been any consideration of ULOG and iptables? I wonder if that could hook into it after the route lookup had occurred and the output interface was known. I'm hoping to look into using PF_RING or something with higher performance than pcap soon. I'm also hoping to add src|dst_as. It would be easy with the new bgp peer code you've added in 0.12.0rc1, but in my case the router is generally already running quagga's bgpd with one or more peers, so I wouldn't want to duplicate a full bgp feed. I was considering have quagga generate a file in the format for use with the "networks_file" configuration direction. Any thoughts on that idea? I'd imagine I'd need to add some signal to indicate to pmacctd to reread the networks file. Thanks, stig > Hi Stig, > > As of now, there is no way to populate the input interface field > in the NetFlow record. Of course, this can be easily implemented > as pmacctd can listen on only one interface at time (whereas if > nfprobe is re-exporting something received from sFlow or NetFlow > the input interface information is already there). > > It could be as simple as a new directive in the configuration > with you setting the appropriate value. Let me know how this > sounds. > > Things get tricky for the output interface instead - as that > can change dynamically, given that multiple interfaces are > available. Two approaches come to my mind at these regards: > > * extend the networks_file directive to include the extra info; > while straightforward to implement, this can easily result in > a cumbersome approach - expecially if implemented on a router: > no real-time feeling that traffic re-routed through another > interface, for example. > > * get involved with the underlying Operating System APIs in > order to retrieve the output interface information. The big > cons is that as the implementation can very likely tend to > be OS specific. > > Anybody interested willing to comment? Any third way i might > have missed? > > Cheers, > Paolo > > > On Mon, Aug 03, 2009 at 04:01:12PM -0700, Stig Thormodsrud wrote: > > I've been searching the mail archives for info on this topic and found a > > thread suggesting to running an instance of pmacctd per interface (using > > the ifindex as the engine_id) and use the nfprobe plugin to export all > > instances to nfacctd on localhost. Then in nfacctd I added a > pre_tag_map > > to map the engine_id to an "id" tag. For nfacctd I was using the memory > > plugin and able to see the different interfaces in the "id" field. This > > all seem to work ok, but I really don't want all the netflow data on the > > router, but rather exported to a netflow collector. So then I tried to > > add a nfprobe plugin to the nfacctd to get it off the router, but the > > external collector only seems to see flows from one interface and all > the > > engine_id are reset to 0. > > > > The next thing I tried was to have each interface/instance of pmacctd > use > > the nfprobe to export to an external collector (again using engine_id > per > > ifindex). This seemed to work better, but I'm still wondering if there > is > > a way to actually set the input interface in the netflow record going > out > > from nfprobe? > > > > Thanks, > > > > stig > > > _______________________________________________ > pmacct-discussion mailing list > http://www.pmacct.net/#mailinglists _______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
