[j-nsp] iBGP convergence time
pekkas at netcore.fi
Mon Feb 5 07:29:29 EST 2007
On Fri, 2 Feb 2007, Richard A Steenbergen wrote:
> On Thu, Feb 01, 2007 at 09:07:05AM +0100, Gniewko wrote:
>> It takes about 3 minutes for m7i_2 to receive 200k of prefixes. But, as
>> soon as I change AS to my public number (both sides of course) have to
>> wait almost 20 minutes. During this long period, CPU on m7i_2 is quite
>> Could You please give me a hint what could be the source of this
> 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.
> scientific testing all the new code seems to be significantly slower. At
> first I had blames this on a particularly nasty build of 7.6 with other
> bugs, but the other day I upgraded a similarly loaded box to 8.1 and
> noticed the same issues. Anyone else seeing the same thing? Short of
> someone slipping in some for(;;) screw_customer(); code to motivate RE
> upgrades I can't explain it. :)
A week or so ago I noticed something similar on 7.5SR, on T320
router(s). The routes were also sitting in "+" in the order of 3-5
minutes for 200K routes (inbound eBGP + 5 iBGP peers). I recall that
earlier similar changes have been almost instantaneous.
I didn't look at the CPU usage level then. In RRD graphs there is a
CPU spike, but it might well be from during the actual route
processing and advertising as well.
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
More information about the juniper-nsp