Date: Sat, 04 Apr 2015 12:12:42 +0100 (BST) From: William Waites <wwaites@tardis.ed.ac.uk> To: glebius@FreeBSD.org Cc: freebsd-net@freebsd.org Subject: Re: ng_netflow and BGP Message-ID: <20150404.121242.1559454934762438716.wwaites@tardis.ed.ac.uk> In-Reply-To: <20150403143821.GY64665@FreeBSD.org> References: <20150401.115048.1362042954044146751.wwaites@tardis.ed.ac.uk> <20150403143821.GY64665@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
----Security_Multipart(Sat_Apr__4_12_12_42_2015_989)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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@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.
----Security_Multipart(Sat_Apr__4_12_12_42_2015_989)--
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNATURE-----
iQIcBAABCgAGBQJVH8cqAAoJEHhNnKzjwx5/L/wQAL/GKCZRKXzYj3Jy44sOPeLz
GDewXEDQRYWHHgsk7sAHQJqx/2lH+RusUTDB4yQVdwQHCu8KfEqj1rFgEaHg0Lkd
+2gUhAoORvEcKMl0j185jn/rp97ub7eULDfy0ZiVnD9iq8Rc4+1nGaoYlivJXCGe
vFyzdrsFQn/9/RXdoJ4MAZYt5Og6REEJMAAqC/ntkIP7BguUmS0T/r0O6bi1QiFv
o0iF1ocdcCRAiuG1NUnpEkRp+AfIQdryssH33VPOaM+4bkKesdsJfrg5zx6D/m34
FzUVP8xtJi3I5yYyAYh7WbcuWC8Yg9cWMdS/Wu+VZ1/Wty5o+u0aNbJPqnzz0thB
MwMP2BCl3Otwz6lq490Gel7My0Z1e6VDLu8CUR49pDDYsqKhb3W41FkKMMNXLkxp
AEYJI+64x1Nkio990cm7qOi6ds2T4q7BqsmTWdUfzIm/f5KVyXp3V4TbQzOX6GuQ
+b//GPS7Xh/8kF1SzJY1BYfOa/1UX33C7reZE+lHp/37QjGtQeo0ox6w796EDZ9D
mq/3Ybl1Jyi16bXlPPt1WlTp+eCtp0tvBCsNo7+tTKs3vljRhJTrKGRZ7K6p79Ad
M0/yWmV6u8XnNV1uGK8nuifK9gNvF88K6DeUYJAGtnIZUPZ/qcdqtmUsGR7KMIsn
X9bZYXKkKYem0q/ELYa3
=Sa+n
-----END PGP SIGNATURE-----
----Security_Multipart(Sat_Apr__4_12_12_42_2015_989)----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150404.121242.1559454934762438716.wwaites>