Cheers for the response Paolo, Here's some background: User traffic arrives at different routers, depending on the type of connection these customers have. I am tagging traffic by user id and what type of traffic (local, national or international) The user id is pretty straightforward - the first section of my pretag.map is a series of the following mappings:
id=<userid> ip=<agentip> filter='host <user IP>' jeq=traffic_type ... id=<userid> ip=<agentip> filter='net <user subnet>' jeq=traffic_type ... The more creative section is traffic labelling for local, national and international... ! Local Networks (a list of our own network ranges) id2=1 ip=<agentip> filter='net <local network>' label=traffic_type jeq=next id2=1 ip=<agentip> filter='net <local network>' stack=+ jeq=next ... ! National Networks (list from APNIC with local networks excluded) id2=10 ip=<agentip> filter='net <national network>' stack=+ jeq=next ... id2=10 ip=<agentip> filter='net <national network>' stack=+ The logic behind these mappings: - A flow to or from a user's IP hits the agent_id rule and then jumps to the local/national mappings where it will always hit at least one local network and setting id2 to 1. - If it hits local network rules again (i.e. local-local traffic) it will end up with an id2 of 2. - If it hits national network rules, it will end up with id2 of 11 - At the end, if it is international, it will have only hit one rule so it will be id2 = 1 This all works swimmingly for at least my current test setup where I have the following configuration: aggregate[hourly]: src_host, dst_host, tag, tag2 pre_tag_filter[hourly]: -0 sql_history_roundoff[hourly]: h sql_history[hourly]: 1h sql_refresh_time[hourly]: 300 sql_table[hourly]: acct_hourly sql_optimize_clauses[hourly]: true So finally to the crux of the original question; on the single-router setup, netflow on the appropriate ingress and egress interfaces works and all the traffic is marked appropriately with a userid (tag) and traffic type (tag2). But I know that upon adding the additional routers for the other traffic users, I will currently have to duplicate the id2 mappings for each netflow agent's IP. I am trying to find a way around that to keep the pretag.map efficient (or maybe ~500 networks x 4 netflow agents for 2000 mappings is not actually too bad?) One solution that I am contemplating is to move away from netflow and enable sflow on our core switches which would keep the required duplication of mappings down. Or, in the same way our current system collects traffic data, use mirror ports (on the core switches) and then use the pmacctd daemon instead. I suspect I am overlooking some more obvious solutions so I really appreciate pointers on this and if you or anyone sees other issues or better design tips for this, then I welcome the feedback. Cheers, - Damian > Hi Damian, > > To confirm wildcarding of the agent is not supported. You can multiplex > values onto a tag by employing a combination of 'jeq' and 'stack' keys. > > Perhaps having more contextual information on what you want to achieve > would help. > > Cheers, > Paolo > > > On Tue, Jul 20, 2010 at 01:11:22PM +1200, Damian Kissick wrote: > >> As I understand it, the 'ip' key is mandatory for netflow pretag.map >> entries. I have this working fine for a single netflow agent but apart >> from duplicating the rules for additional agents, is there a way to >> wildcard or have multiple values for a single 'ip' key or some other >> strategy? >> -- Damian Kissick Actrix Networks Ph. 0800 ACTRIX #408 Fax. +64 4 801 5335 http://www.actrix.co.nz _______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
