Hi Damian,

Are you running BGP? Would it be feasible for you to past BGP feed(s)
into pmacct (granted you run a recent 0.12 release or can upgrade to
that)? Idea is you can attach BGP standard communities to IP prefixes
as they are advertised or re-distributed into your network. Because
comunities are supported as primitives in pmacct (and you can filter
what you want to see and what should be thrashed instead), you might
even avoid the whole 'id2' section.

Just an idea. In case BGP is not an option: total number of mappings
defined isn't an issue. In this sense, to store 2K entries you should
make use of the pre_tag_map_entries directive (and set it above 2K).
Not very nice to see but it works and should be straightforward to
automate.

It's important though to keep the walks through the maps as short as
possible; so,

id=1 ip=X jeq=user_X
id=1 ip=Y jeq=user_Y
...
id=1 ip=Z jeq=user_Z
!
id=<userid> ip=X filter='...' label=user_X jeq=traffic_type_X
id=<userid> ip=Y filter='...' label=user_Y jeq=traffic_type_Y
...
id=<userid> ip=Z filter='...' label=user_Z jeq=traffic_type_Z
!
id2=1 ip=X filter='...' label=traffic_type_X jeq=next
...
id2=1 ip=Y filter='...' label=traffic_type_Y jeq=next
...
id2=1 ip=Z filter='...' label=traffic_type_Z jeq=next
...

Cheers,
Paolo


On Wed, Jul 21, 2010 at 11:33:38AM +1200, Damian Kissick wrote:
> 
> [ ... ]
> 
> 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

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

Reply via email to