netflow v5 - src AS/dst AS

[Gleb Smirnoff]

On Wed, Feb 01, 2006 at 07:54:05PM +0200, Nickola Kolev wrote:
N> As you can see from the subject, I'd like to set up a PC-based netflow
N> v5 probe, capable of exporting information about specific source and
N> destination ASes for the purpose of accounting. Regretfully, I
N> didnt come to any solution, mostly because the kernel FIB, eventhough
N> injected with a full BGP routing table, doesnt carry any BGP specific
N> information (such as next-hop AS, src AS, dst AS, etc.). This is
N> normal, because, at least the way I can explain it to myself, the BGP
N> speaking daemons, be it Zebra/Quagga, Xorp or OpenBGPd are userspace
N> programs and probably dont have a way to inject such information into
N> the kernel FIB, that's why keep it in its own structures.
N> 
N> My question is does any of you know of a way to achieve some sort of
N> interaction between the BGP-speaking daemon (e.g. Quagga) and the
N> various netflow probes to export Netflow v5 data, including
N> src/dst AS information.
N> 
N> Maybe some netgraph module besides ng_netflow, which I tried, but of no
N> avail.

When I initially wrote ng_netflow, I have made a quick hack to kernel and
zebra to make this possible. It was just a prove of concept, so I even didn't
save the hack.

I have once raised the question about route entries in kernel carrying
additional extended route attributes. For example routing protocol
specific ones, like AS path. However, I experienced a strong opposition
and unwillingness to see this in FreeBSD. You can find this in the mailing
list archives.

We have the following plans for the future, which I hope are agreed by all
developers. We are going to extend route entries with a 32-bit opaque tag.
This idea is already being worked out in OpenBSD. The routing daemons
should be able to set this tag to some value, defined by their configuration.
These tags can be used for many different things, including packet filtering
and shaping.

When this is done I will make ng_netflow(4) insert this tag (its 16-bit part)
into AS fields of the exports. This will allow us to supply any kind of
information in exports. Once the administrator has configured the routing
daemon to put the AS numbers in the opaque tag, he gets ng_netflow(4) filling
in AS numbers.

You see, this requires some change to kernel and more changes to routing
daemon. Probably under routing daemon I mean OpenBGPd, not zebra or quagga.
I don't believe the latters will include FreeBSD specific things in their
code. The OpenBGPd comes from OpenBSD, a much more friendly system than Linux.
There is a slow process of porting it to FreeBSD. I think once this is done
we can include out changes in it, or ask OpenBSD developers to do this. The
same way as pf(4) is maintained in OpenBSD and FreeBSD.

-- 
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE