Real Time Traffic Flow Measurement - anybody working on it?

Through the stimulating discussion we had under ``IP Acounting Idea for 2.5'', it appears that a separate Traffic Flow Measure- ment and Accounting sub-system would be useful. See:
<http://logi.cc/linux/CounterReset/>

If anybody is working on Real Time Traffic Flow Measurement (RTFM) please reply.

I would also like to know if there are any objections to providing a RTFM interface in the kernel (as an optional module).

FYI:

Considerable work has already been done on RTFM in general and for other systems:

        <http://www2.auckland.ac.nz/net//Internet/rtfm/>
        <http://www.caida.org/>

Relevant RFCs include: 2720 ... 2724

Thanks

Manfred Bartz

Can't say i'm actively working on it but I've emailed Nevil to see if he knows of any RTFM work that is being done on Linux.

Although here's some observations:

Userspace pcap meters (such as NeTreMet) can measure traffic IP stack doesn't even see (useful for a probe on a span port for instance) - can also meter other protocols.

An obvious kernel improvement for userspace meters like NeTraMet would be to give libpcap's pcap_read a kernel interface that can return more than one packet at a time (the libpcap interface has this capability). The current linux libpcap implementation incurs a read syscall per packet.

An additional feature for network devices that could support it (not sure if this is feasible) would be to switch to an 'interrupt when packet buffer full' when in promiscuous mode.

A libpcap comment lists a bug in packet socket that means you need to read the entire packet to get the packet length (which I assume means meters like NeTraMet are forced to set the snaplen really high) - which is a performance penalty if your just want to read headers but also need the packet length.

from libpcap-0.6.2/pcap-linux.c

/*
* XXX: According to the kernel source we should get the real
* packet len if calling recvfrom with MSG_TRUNC set. It does
* not seem to work here :(, but it is supported by this code
* anyway.
* To be honest the code RELIES on that feature so this is
really
* broken with 2.2.x kernels.
* I spend a day to figure out what's going on and I found out
* that the following is happening:
*
* The packet comes from a random interface and the packet_rcv
* hook is called with a clone of the packet. That code
inserts
* the packet into the receive queue of the packet socket.
* If a filter is attached to that socket that filter is run
* first - and there lies the problem. The default filter
always
* cuts the packet at the snaplen:
*
* # tcpdump -d
* (000) ret #68
*
* So the packet filter cuts down the packet. The recvfrom
call
* says "hey, it's only 68 bytes, it fits into the buffer"
with
* the result that we don't get the real packet length. This
* is valid at least until kernel 2.2.17pre6.
*
* We currently handle this by making a copy of the filter
* program, fixing all "ret" instructions with non-zero
* operands to have an operand of 65535 so that the filter
* doesn't truncate the packet, and supplying that modified
* filter to the kernel.
*/

~mc

Hi,

It's already there - the turbo packet interface (PACKET_RX_RING sockopt). Very nice and fast. Direct transfer to mmapped memory.

With the RX_RING you can poll a memory location in the mmapped memory to detect whether there are new packets. You basically only perform a system call (poll/select) if there's nothing more to do.

Ciao, ET.

Hey cool. Now we've come to a point where we agree. If you want to do serious accounting, iptables is not the subsystem of your choice.

As you've pointed out on your very enthusiastic homepage:

* Mixing fundamentally different functionalities like security and
* accounting in a firewall is not a good idea anyway. It leads to overly
* complex firewall code (potentially thousands of rules just for
* accounting) and unreliable accounting (f.e. when the firewall rules get
* reloaded).

No, not at all. I'd like to help developing an RTFM meter for linux. I guess we don't actually need to keep seperate flow information, but could attach it to the netfilter connection tracking.

Live long and prosper
- Harald Welte / [email protected]                http://www.gnumonks.org
============================================================================
GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M- 
V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*)