On Mon, Mar 12, 2012 at 02:27:23PM +0400, Alexander V. Chernikov wrote: > On 12.03.2012 13:25, Oleg wrote: > >Hi, all. > > > >I have some experience with bird under heavy cpu load. I had a > >situation when bird do frequent updates of kernel table, because > >of bgp-session frequent down/up (because of cpu and/or net load). > >I waited about 5-10 minutes for birdc started, when i wanted to > >reconfigure bird with configure soft command from birdc(ssh and > >other interactive programs works well). After i changed bird.conf > >in such a way that i get from upstream 0.0.0.0/0 instead of full view > >birdc worked fine and bird cpu load lowered(before, bird load cpu about > >30-89%). > >What can i do in such situtation in future for birdc normal work? > Adding/removing kernel routes is a complex task, results in main > process waiting for system call is completed. > > It is very costy and one (developer) possibility is to add > additional thread which does kernel interaction.
I think that a separate thread can solve this nuisance. > We workaround this by installing IGP routes only (which does not > help for border router) Unfortunately, this is a border router. > You can try to reduce MAX_RX_STEPS to 1 in sysdep/unix/io.c, this > will help a bit for new route installation (2 minutes instead of 5), Thanks! I'll try it. > but at the moment answer seems to be "don't export all routes to > kernel". You can filter all that is >=/20, for example, to provide > reasonable load balancing with much less routes in OS kernel. In simple configuration with one upstream this works fine, but what in more complex configurations? Can i lose some networks? Or can i get poor ping, because of /24 prefix, for example, is better than /20 that contain it? > >And additional two questions: > >Does bird immediately push routes info in kernel table, if it receive routes > >updates from bgp-peer or it wait for the next kernel table scan? > Kernel protocol (just as any other protocol) receives route updates > immediately after they are announced to the routing table by BGP > protocol instance. In the came callback kernel update (for the > single route) is prepared and called. So, in a such situation a simply increasing of a scan time value doesn't help as i understand.