I was notified about this rather long thread by Paul Jakma about OpenBGPD
and I think I have to clarify a few things.
Paul is talking a lot about memory requirements and uses the numbers of
a bug report to compare OpenBGPD with quagga.
Now lets see (quoting a mail from Paul):
> Here's Quagga on a FreeBSD 4 box at a webhosting facility:
>
> 6192 root 2 0 117M 117M select 59:52 12.65% 12.65% bgpd
> 6071 root 2 0 57332K 56936K select 1:25 0.00% 0.00% zebra
>
> 160MB total. 117MB for bgpd. The 57MB for zebra will remain mostly
> constant once you have a full feed, regardless of how many BGP
> sessions/announcements you get.
Let's have a look at an OpenBGPD router I run here:
[EMAIL PROTECTED]:~> date && bgpctl show rib mem && ps axl | grep bgp
Tue Mar 7 13:41:36 CET 2006
RDE memory statistics
181517 IPv4 network entries using 5.5M of memory
1765919 prefix entries using 53.9M of memory
327780 BGP path attribute entries using 21.3M of memory
279726 BGP AS-PATH attribute entries using 8.2M of memory,
and holding 327780 references
7737 BGP attributes entries using 181K of memory
and holding 287989 references
7736 BGP attributes using 132K of memory
RIB using 89.2M of memory
0 22134 1 0 2 20 6640 6992 poll Is ?? 122:00.69 bgpd: paren
75 24494 22134 0 2 20 2004 2304 poll I ?? 98:27.76 bgpd: sessi
75 9754 22134 0 2 20 149980 148440 poll I ?? 470:53.67 bgpd:
route
This box has 15 sessions 8 of them I consider full views the other ones
don't have less than 175k prefixes. This is on a:
cpu0: VIA Samuel 2 ("CentaurHauls" 686-class) 665 MHz
cpu0: FPU,DE,TSC,MSR,CX8,MTRR,PGE,MMX
real mem = 534294528 (521772K)
avail mem = 480649216 (469384K)
If I count correctly I get 150MB memory usage and some sessions are up
since more than 8 weeks. Yes, this box has soft-reconfig in disabled but
it would not matter anyway because there is no filtering done.
The difference between the 89.2M of the show rib mem output and the ~150MB
ps output comes from a) non accounted memory and b) malloc overhead. Currently
I have the feeling that b) is bigger than a) but that's just a guess.
Another urban legend is the coolness of "dynamic route refresh".
OpenBGPD does announce the route refresh capability and supports request
from other peers but we do not have the button to make a refresh request
ourself. There is a simple reason why. Because "route refresh" as in RFC
2918 is totaly useless. As Paul realized in a later mail:
> So you can initiate route-refresh and capture the updates, even without
> soft-reconfig.
>
> You can't tell though exactly when the 'refresh' ends, unfortunately.
> There is a feature in BGP for this, "End of RIB", which could
> potentially used to signal "Finished sending you my refresh" but it's
> tied in with the BGP Graceful-Restart RFC at the moment (unfortunately).
Now that's great you don't know when the refresh is finished. It is even
worse you don't know if it worked at all in the first place.
The End-of-RIB marker introduced in the BGP Graceful-Restart proposal
should have bin in RFC 2918 from the beginning.
We consider the use of RFC 2918 as a substitution of real inbound soft
reconfiguration as unusable until the named issues have been solved.
Adding a knob to bgpctl to issue a refresh request is not a big issue.
--
:wq Claudio
_______________________________________________
networking-discuss mailing list
[email protected]
