Well we are running M40 and seeing very slow BGP convergence times, that this thread seems to describe well.
We first noticed this after we upgraded to 8.0 A fix would be nice :-) Richard A Steenbergen wrote: > On Fri, Feb 02, 2007 at 04:13:27AM -0500, Richard A Steenbergen wrote: >> You know I haven't had any free time to run real tests or anything, but I >> noticed a significant increase in BGP convergence time when upgrading from >> JUNOS 7.2/7.3 (and I think some 7.4) to 7.6. When you make a policy >> change, the routes take several minutes (from 2 to 7) to install. If you >> do a show route you can see the new routes sitting in + and the old routes >> sitting in - for minutes, RPD is spinning its heels at 100% cpu, and the >> packets continue to forward over the old path while it is processing. > > Ok so, after about a dozen people contacted me privately to confirm that > they were seeing similar issues that hadn't been fully acknowledged, I ran > off and did a little testing to replicate the issue. The one thing I can > definitely confirm right now is that it only appears to affect M160 (or at > least, not M5-M40). > > On an RE-2.0 on a single switch board platform, performance is about what > you would expect from a 7+ year old routing engine running modern code on > a modern routing table. It syncs a full table inbound (from empty) on an > otherwise unused RE-2.0 in just under 7 minutes, and it processes a switch > of best path and installed routes on a full table is just barely under 2 > minutes (policy-statement with then local-preference only, no other > processing). However, on an M160 the switch of best path which leads to > installing new routes in the HW takes between 8-15 minutes in my tests. I > haven't yet had time to go through every version one at a time to find > exactly where there starts, but the behavior is definitely evident. > > The following is based on absolutely nothing except my random guess as to > what is happening, so someone please let me know if I'm warm or cold. It > seems that the easiest way to replicate the state of new route showing up > as "+" and the old route showing up as "-" is to intentionally break > connectivity between the RE and PFE (easy with an m40 :P). My guess is > that this is a kind of transactional FIB installation system, where the RE > doesn't update its RIB to reflect that the new route has been installed > until the switch board processes it and confirms it (and allowing it to > retry the install if necessary), to prevent Customer Enragement Feature > with Juniper's move towards distributed forwarding tables on the Gibson > architecture. Whatever is going on with the M160 on RE-2.0 however, it is > significantly slower. Maybe this just wasn't sufficiently regression > tested on the M160 platform, or maybe it is just a natural effect of > having 4 switch boards which all need to be updated, but it is very > noticable. The offical Juniper line seems to be "just upgrade your REs", > but it would be nice if we had an alternate option. > > So, two things. The most obvious question is, is there a way to turn this > behavior off or revert it to the previous behavior (if infact my guess as > to the cause is correct :P)? The next question is, I noticed in the > release notes for 8.2 that there is a new option to support indirect > next-hops which may significantly reduce the number of FIB updates. My > take on this feature is that you are changing from installing BGP route -> > physical next-hop to BGP route -> BGP next-hop and BGP next-hop -> > physical next-hop, so that when you make a routing change to the BGP > nexthop you only have to update the 1 entry instead of the potentially > thousands of entries for the BGP route itself (which I kinda thought > Juniper had done since forever :P). Am I correct in that interpretation, > or is there something else going on there? > -- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. Any offers or quotation of service are subject to formal specification. Errors and omissions excepted. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Lumison, nplusone or lightershade ltd. Finally, the recipient should check this email and any attachments for the presence of viruses. Lumison, nplusone and lightershade ltd accepts no liability for any damage caused by any virus transmitted by this email. -- -- Virus scanned by Lumison. _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
