On Wed, Aug 31, 2011 at 02:17:57PM -0500, kevin brintnall wrote:
> Hi,
>
> I've looked for a mailing list for OpenBGPD but come up empty. If there's
> a better place to report this, please let me know.
No this is fine.
> I'm using OpenBGPD as a fairly large route collector. In total, about 75
> neighbors announcing ~21 million prefixes. This is
Hmm. That's not bad :)
> openbgpd-4.9.20110612_1 running on FreeBSD (latest from ports collection).
> # bgpctl show ip bgp memory
> RDE memory statistics
> 456227 IPv4 unicast network entries using 17.4M of memory
> 912454 rib entries using 55.7M of memory
> 42436670 prefix entries using 2.5G of memory
> 3270891 BGP path attribute entries using 374M of memory
> 102926 BGP AS-PATH attribute entries using 4.6M of memory,
> and holding 3270891 references
> 10722 BGP attributes entries using 419K of memory
> and holding 9317049 references
> 10721 BGP attributes using 123K of memory
> RIB using 3.0G of memory
>
> I find that during start-up, the CPU of the "route decision engine"
> process is steady between 90-100%. During this time, "bgpctl" hangs.
> This lasts at least 45 minutes.
>
> I believe most of the CPU is spent in "path_lookup()", traversing the
> linked list in pathtable.path_hashtbl[]. I think a suitable fix would be
> to increase the hash table sizes (rde.c:152):
Is this just a "believe" or is there some profiling output behind this?
I know that when many sessions open at the same time it will lock the RDE
for a long time. It is something that I shold finally invest some time in
to solve.
> u_int32_t peerhashsize = 64;
> u_int32_t pathhashsize = 1024;
> u_int32_t attrhashsize = 512;
> u_int32_t nexthophashsize = 64;
>
> It seems like it would also make sense to have these variables exposed to
> the user somehow. Maybe optional config knobs like this:
>
> hashsize peer 64
> hashsize path 1024
> hashsize attr 512
> hashsize nexthop 64
>
> In addition, we could use the hash as an easy check for inequality. This
> would optimize the check for path_compare() where we only care about
> equality. There are a couple cases like this:
>
> - if (peer == asp->peer && path_compare(aspath, asp) == 0)
> + if (peer == asp->peer && path_equal(aspath, asp))
>
> int path_equal(struct rde_aspath *a, struct rde_aspath *b)
> {
> if (a->hash != b->hash)
> return 0;
> else
> return path_compare(a, b) == 0;
> }
Yes that makes sense.
> This change should probably be coupled with a better hash calculation.
Again, is this just a gut feeling or is there statistical data behind this
statement that shows that the current hash is performing badly...
> Finally, I was surprised to see double the prefix entry count. I carry
> 21M routes (add up the last column of "bgpctl show"). Yet, the output
> above shows 42M "prefix entries". I do not modify the prefixes at all; my
> rule set contains only "deny to any; allow from any".
Yes that seems strange. For a quick fix try setting "softreconfig in no".
Also run "bgpd -nv" to see if some other setting may cause altering of
prefixes.
--
:wq Claudio
