Hi Paolo, On Saturday 18 December 2010 at 14:30 (CET), Paolo Lucente wrote: > You already anticipated the answers. Libpcap great portability comes > at the expense of a nearly null integration with underlying operating > systems. Integration being instead perhaps the greatest advantage of > ULOG.
It's a shame really :-/ > With libpcap, IHMO, the best chance to infer traffic direction is, as > you said, by relying on MAC addresses. The amount of data to be tracked > down is manageable even in slightly larger deployments and is suitable > to be reloaded at runtime in pmacct; tracking changes here is the non- > elegant part of this story, ie. some cron-job can check whether anything > changed since last run but, especially in more dynamic scenarios, really > what you want is an event-driven trigger. In lack of such a thing, i can > only thing to fixed procedures or 0200.0000.0001 kind of MAC address > rewrite. In my environments MAC addresses are pretty static. Though having some scheduled check surely wouldn't hurt of course. At the moment this seems to be most viable option, because ... > ULOG is conceptually most suitable if traffic is passing through the > Linux box as it offers several ways to infer traffic direction. First, > either INPUT or OUTPUT chains of any interface can be directed to ULOG > in a flexible way (good foundation to generate sFlow or NetFlow data > out of the seen traffic); then interfaces can be split onto different > multicast groups or one can rely on the input/output interface fields > within the ULOG header. ULOG should support also a sampling facility > for scaling purposes. ...one really nasty downside of ULOG is the lack of any hooks/chains/tables *after* nat/POSTROUTING. So with ULOG it's not possible to "monitor" SNAT'ed traffic. For my upcoming deployments (which triggered this investigation), this isn't much of a problem, as it will be used on "plain" routers, without any NAT rules on it. However, since the goal is create a homogeneous environment and some nodes make (heavily) use of NAT rules. So I guess I'll focus my research on a libpcap-based approach using MAC addresses as "directional indicator". Optionally with the mmap flavour or the PF_RING flavour. One more option that's been bouncing around in the back of my head is the use of nProbe as a collector (assuming it offers what I need) and have it export sflows/netflows to sfacctd/nfacctd. Though it wouldn't surprise if I'd end up dealing with the same limitations (on either end). > Btw, thanks for your feedback on the uacctd docs - point taken. Glad to be of service ;-) Regards, Ruben Laban _______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
