----- Forwarded message from Paul Jakma <paul@clubi.ie> ----- From: Paul Jakma <paul@clubi.ie> To: Arife Vural <arife@ripe.net> Subject: Re: RIPE RIS / Quagga Date: Wed, 8 Mar 2006 13:53:18 +0000 (GMT) Mail-Followup-To: paul@hibernia.jakma.org On Wed, 8 Mar 2006, Arife Vural wrote:

We run Quagga 0.96.5. I think we have that version more than a year.

Wow. :) I think it has an IPv6 attribute related DoS btw. At least, the SIXXS ghosthunter had to upgrade to 0.98 because someone was injecting something into global IPv6 that took down old 0.96ish bgpd's.

Until now, we did not have any big performance problem related with Quagga. We have to run mySQL and DBinsert on route collectors in addition to Quagga to insert data into DB. We had a memory leak in DBinsert process, it was eating up the all memory and was killing the deamons including bgpd. We kind of get round that problem. Now, bgpd seems to be quite OK.

:)

We have problem only on RRC03 (AMS-IX). It's the biggest route collector. It has peering session about 130. Only thing, I observe is the bgpd response time. It is bit slow. It takes a while (less than a minute) to configure a session.

Interesting.

But be honest, I do not know how bgp traffic is effected with this slowness. We do not have tool to check the consistency of BGP updates. Until now, I have not heard any comment from our users about complaining the consistency of the data.

Consistency is probably good. What you may notice is that sometimes sessions drop for no apparent reason (typically co-inciding with the telnet interface being unresponsive). This we have, I think, fixed.

We have looking glass here, please have a look at and decide which RRC will be a good example for you, than I will try to provide you the performance graph of that RRC.

The ones I'm interested in are: RRC01 (Linx) RRC03 (AMS-IX) I'm particularly interested in the following outputs:

From bgpd's telnet interface: - 'show memory bgp' - 'show memory lib' - 'show ip bgp sum' (at the time above are taken) From your operating system (in whatever way): - the total memory usage of bgpd

That would be *very* informative. We intend to try bgpd on a diet - there's some low-hanging fruit and I think we can easily reduce usage by 10% or so. Output from RRC01 and RRC03 would be very useful in determining where else "dieting" would have biggest effect on bgpd (both RRC's if possible -> so we can see how objects scale with number of sessions / prefixes / paths). That would be *great* if you could provide that. :)

I just checked the performance graphs some of them are missing, but I'm sure we can find one that will be useful for you. We use Orca tool to get performance graphs I hope it would be useful for you.

Very neat.

This is the "show thread cpu" from RRC03.

rrc03> show thread cpu Runtime(ms) Invoked Avg uSecs Max uSecs Type Thread 2165490.000 7184 301432 36150000 T bgp_dump_interval_func 1537621.376 35511 43299 4710000 T bgp_scan 3676941.376 60175283 61 4570000 E bgp_event 229430.000 384 597473 3850000 T bgp_holdtime_timer 1900803.568 142918849 13 36150000 RWTEX TOTAL

Interesting, bgp_dump_interval_func() took the longest. We should probably run it as a child process, if possible.

If you like to see the output of the other RRCs, please let me know.

BTW, we do not run zebra daemon.

I would have thought so. Avoids bulk of the performance problems too.

About using the new version, I think we are bit conservative. Until, we have problem or a security issue, we are happy to using old version.

Ok.

BTW 2, I have a question for you. Is there any plan about implementing 32bit AS number in Quagga?

Yes, the internal AS_PATH parsing code was partially rewritten late last year to make the internal representation of AS_PATHs indepedent of the wire format, specifically in order to make it ready (internally) for 4-byte ASNs. Ie the internal format is now just a change of a typedef away from 4-byte ASNs. (We also have, with that rewrite, an extensive set of AS_PATH code exercising unit tests to verify nothing breaks). Didn't yet get as far as adding support for the 4-byte capability or its required attributes, or the transition mechanism of NEW_AS_PATH (and unit tests to verify them). Later this year hopefully. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: You will be dead within a year. ----- End forwarded message ----- -- Arife Vural SED, RIPE NCC