Hi Ruben, 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.
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. 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. Btw, thanks for your feedback on the uacctd docs - point taken. Cheers, Paolo On Fri, Dec 17, 2010 at 03:17:41PM +0100, Ruben Laban wrote: > On Friday 17 December 2010 at 12:53 (CET), Ruben Laban wrote: > > I'm trying to figure out if it's possible, and if so: how, to classify > > packets as inbound or outbound based on the "actual" direction the packet > > flows and thus not relying on the source/destination ip address in the > > packet. In dynamically routed networks, a given (super)subnet can exist on > > more than one leg of a router. One could somehow tie the dynamic routing > > data into pmacct by updating the aggregrate_filter settings when the > > topology changes. This doesn't strike as a very decent or even scalable > > solution though. Based on my searches on the web, it seems (lib)pcap > > throws away any directional data before passing it on to the program using > > the data. Another thought that crossed my mind was the use of the > > source/destination mac address. But again, this doesn't scale well (even > > though I only monitor transport interfaces which tend to have a /29 or /28 > > configured (and multiple /24s routed over them)). > > I'm hoping there's a more elegant solution though. So if anyone has any > > ideas/pointers, I'm all ears (well, eyes). > > While scouring the web some more, I found that uacctd might be a decent > "alternative" to pmacctd. However documentation uacctd is quite sparse or > quite well hidden. Are there any plans to improve/extend its documentation > and/or make it easier to find? > > Regards, > Ruben Laban _______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
