Hi Timo,

Thanks for providing the use-cases, they sound valid to me. Also, you
are right saying it's no big deal to implement these new keys as they
would be mostly similar to the existing ones. I would make one exception
which did not raise from your email: the potential need for IP addresses
(in the IPFIX flow) to be masked with a given netmask for comparison
against a prefix in the map - such support is not there today, so it
would be extra work, but it does not sound as a biggie (and if you do
not feel you need it, it could be deferred until later when there is
need for it from you or somebody else). 

If we are in-sync, i guess we can pass to private email for two things:
1) get from you some sample data that i can replay in lab and 2) agree
some timelines. Or alternatively, should you feel to be in the position
of contribute some code, that would be fantastic.

Paolo 

On Wed, Mar 01, 2017 at 04:25:26PM +0100, Timo Lindhorst wrote:
> Hi Paolo,
> 
> thanks for your response.
> 
> > All of that should fall in the pre_tag_filter domain but I can
> > anticipate you none of the fields you are mentioning (ie.
> > post_nat_src_host, src_host_country or nat_event) are currently
> > supported. What would be your use-case? Feel free to say here or via
> > unicast email.
> 
> We are collecting IPFIX NAT event records from a gateway device
> containing the 5 tupel, post_nat_src_host, post_nat_src_port,
> nat_event, and some counters. In this setup, I have two use cases:
> 
> 1) While we are receiving both create events (nat_event=4) and destroy
> (nat_event=5), I only want to persist the destroy events in DB, as
> those carry all the information required. Hence, my intention was
> to somehow filter for nat_event=5.
> 
> 2) In addition to that, depending on the NAT IP address, different
> retention policies apply. Hence, I want to filter for post_nat_src_host
> to be in a given a.b.c.d/e network and pass to a dedicated plugin,
> e.g. to persist in dedicated DB table.
> 
> If I got you right, this is supposed to be done by using a pre_tag_map
> to tag the records and do the filtering by pre_tag_filter on the given
> tag. However, support for the particular attributes (post_nat_src_host,
> nat_event) to be used as match in pre_tag_map needs to be implemented.
> I guess, this would be straight forward, as it would be similar to the
> existing matches (dst_as, dst_mac, ...), right?
> 
> Thanks in advance
> Timo
> 
> 
> 
> 
> > On Tue, Feb 28, 2017 at 01:54:14PM +0100, Timo Lindhorst wrote:
> >> Hi,
> >> 
> >> we're currently digging into pmacct and friends and I'm quite happy
> >> about its feature set and extensibility.
> >> 
> >> Now, I face a probably not so uncommon use case, which I'm not able
> >> to find a simple solution for:
> >> 
> >> The `aggregate_filter` key allows to filter flows before passing them
> >> to a plugin. The filter syntax is supposed to be a pcap-filter:
> >> aggregate_filter[inbound]: dst net 192.168.0.0/16
> >> 
> >> However, is there a way to filter for non-pcap attributes, like
> >> src_host_country or nat_event? In my present case, I like to filter
> >> the post_nat_src_host to be in a given network, but I don't see
> >> a way to do this with aggregate_filter and pcap syntax.
> >> 
> >> The documentation for aggregate_filter says:
> >> > This directive can be used in conjunction with 'pre_tag_filter'
> >> > (which, in turn, allows to filter tags).
> >> Hence, I guess it should be possible to filter for tags. However,
> >> trying `tag 1` as filter results in a "syntax error".
> >> 
> >> I appreciate any help or hint how to approach this.
> >> 
> >> Thanks in advance
> >> Timo
> >> 
> >> 
> >> 
> >> 
> >> 
> >> --
> >> Dipl.-Ing.-Inf. Timo Lindhorst
> >> 
> >> email: timo.lindho...@travelping.com
> >> phone: +49-391-819099-236
> >> 
> >> ----------------------- enabling your networks ----------------------
> >> 
> >> Travelping GmbH                     phone:  +49-391-81 90 99 0
> >> Roentgenstr.  13, 39108 Magdeburg   fax:    +49-391-81 90 99 299
> >> Koernerstr. 7-10, 10785 Berlin      email:  i...@travelping.com
> >> GERMANY                             web:    http://www.travelping.com
> >> 
> >> Company Registration: Amtsgericht Stendal        Reg No.:   HRB 10578
> >> Geschaeftsfuehrer: Holger Winkelmann          VAT ID No.: DE236673780
> > > ---------------------------------------------------------------------

_______________________________________________
pmacct-discussion mailing list
http://www.pmacct.net/#mailinglists

Reply via email to