We are seeing the same on M10i's RE-850 after upgrading to 7.6R2.6 and also M7i's (same software and RE).
A fix would be nice indeed. cheers On Mon, Feb 19, 2007 at 02:25:55PM +0000, Ian MacKinnon wrote: > 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 > -- andy [EMAIL PROTECTED] ----------------------------------------------- Never argue with an idiot. They drag you down to their level, then beat you with experience. ----------------------------------------------- _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp