[j-nsp] KRT Queue issue (was: Re: bfd = busted failure detection :)

[David Ball]

  I'm working with ATAC tonight to get them a running kernel core dump
so they can look for root cause, but apparently disabling GRES,
committing, re-enabling GRES, and committing again, somehow can
temporarily resolve the issue (get the routes installed, I guess
?!?!).  Don't ask me how GRES has anything to do with it....

David


2010/1/6 Richard A Steenbergen <ras at e-gerbil.net>:
> On Wed, Jan 06, 2010 at 09:26:03AM -0700, David Ball wrote:
>> Ran into this again on a t640 running a 9.2SR release a couple days
>> ago.  KRT queue was 2-3k operations queued yesterday, is over 52k
>> operations queued now.  An RPD core dump was apparently the trigger
>> the LAST time this happened to us, but no core dump this time, so it's
>> starting to look a little more like the apparently random occurance
>> the rest of you have been experiencing.  It's with ATAC.
>
> We had an RPD core dump on us while upgrading to 9.3R4 on an MX960
> several weeks ago, no progress on the case thus far, but that was the
> first time we've seen something like that happen. I've been replicating
> the slow route installation issue for Juniper on a few different boxes,
> but we still haven't gathered enough information to track down the
> cause. On the first example case, almost the entire routing table took
> over 18 minutes to install on 9.5R3. As soon as we figure it out, I'll
> let you guys know. :)
>
> --
> Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
> GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
>