ng_netflow and BGP

[William Waites]

Hi Gleb!

    > The issue is open since I've written the ng_netflow node. You
    > would agree that keeping the ASN information in kernel, just for
    > the sake of exporting it out, is rather strange.

I agree with this.

    > But the proper solution, I think, is to do prefix -> ASN
    > matching at the collector.

I don't think I agree with this. The reason is, once the flow data has
left the router, a lot of context is lost. In principle, we might also
collect other things like localpref, MED, next hop and so forth. All
of this information is in the routing daemon, it knows why it
installed one route and not another in the kernel, and what the extra
metadata about that route was. If the collector has to try and
reconstruct this, there will be corner cases when it does not work
properly.

I can think of a few such corner cases. One is with inconsistent
origin ASNs which can be legitimately used for anycast prefixes, a
famous one being the 6to4 automatic tunneling network, but also
things like local DNS and NTP servers that may use a well known
(within a confederation) address that is announced by multiple
ASNs.

The problem with putting this after ng_netflow is that (for V9)
ng_netflow has already decided what the template is, so adding in any
extra information means mangling the template which doesn't seem like
a good idea. I guess a middle ground is to use V5 which doesn't have
templates and a proxy on the router that augments this and sends V9.

At the same time, as I said, I agree that most of this does not belong
in the kernel. Maybe a solution is to move much of what ng_netflow
does out of the kernel and to arrange so that packet headers get sent
to a userland daemon that speaks with the routing daemon and generates
the flow data.

I also do not like requiring the collector to maintain complete
routing tables. To me, its job should be simple -- take the flow data
and write it to disk. Not try to reconstruct complicated things about
what the routing daemon may have been thinking. In our case the extra
RAM requirements also hurt -- we are a shoestring operation so keeping
a copy of the tables of each border router (so we have enough
information to do the reconstruction according to the source of the
flow data) seems wasteful.

Cheers,
-w
--
William Waites <wwaites at tardis.ed.ac.uk>  |  School of Informatics
   http://tardis.ed.ac.uk/~wwaites/       | University of Edinburgh
       http://www.hubs.net.uk/            |      HUBS AS60241

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-net/attachments/20150404/3dd11ce6/attachment.sig>