I actually like both of these ideas, for different reasons. I wrote a
bit inline.
On 12/12/13, 5:35 PM, Olivier Benghozi wrote:
Hi all,
I was thinking of some features that may be interesting (at least I think they
may be interesting for us, so they may be also for some other people).
We use nfacctd with a bgp session to put together netflow and bgp information
to a database, only for inbound traffic.
1: what about a feature to prevent any db insertion before a BGP session
established within the first minutes of nfacctd life? That would prevent empty
AS/BGP related fields in the database. Something like a ldp-synchronization
hold-time xx seconds that junos/cisco/others implement for their IGP.
For the exact reason you mention, I like this idea a lot. With the
present system this data, especially in mongodb (I care less about stuff
I use in memory tables as I can just filter that out easily) gets some
period of bad data until things decide to reconnect (sometimes takes a
bit) and we send a full table (usually pretty quick).
2: what about a feature to shorten or compress the stuff inserted in
src_as_path, regarding prepended ASes? Obviously incoming traffic is not linked
to the as_path to the source, but it's still interesting to see which kind of
link you use to see it. In those conditions, prepended ASes are meaningless in
this direction; what about removing prependings in this field ? Or what about
replacing prependings by something like AS[55] for a 55 times prepended AS
(something that would be easy to remove at the select)?
I don't particularly care that much about excluding prepends exactly but
it does help solve another issue in that the current limit of 128 bytes
on the keys is too short for some of the (rather silly) prepends we see
right now. This would effectively solve that issue. I like the idea of
what you suggest to still denote the presence of a prepend (and the
count) I think all of this would have to be an option, but, perhaps
something like:
1234_5678_5678
becomes:
1234_5678R2 meaning "repeats twice"?
That said, my primary concern with regards to why this is useful is
simply to work around the paths I see presently where pmacct can't
display the full path because of the 128 character limit. (I see about
37 such paths presently). If that could be solved more easily, it serves
my needs just as well.
I have been meaning to delve a bit deeper into the pmacct source code,
some of this (especially the 2nd one) might make a nice project.
-Adam
_______________________________________________
pmacct-discussion mailing list
http://www.pmacct.net/#mailinglists
