[j-nsp] MX80 BGP performance after reboot

[joel jaeggli]

On 2/13/13 10:42 PM, Caillin Bathern wrote:
> Couldn't RPD just reduce the TCP window size for BGP sessions to reduce
> the rate at which it can receive routes from neighbouring routers?
> This would mean that your FIB would always be synched to your RIB and
> other routers would not blackhole by sending traffic to the router in
> question (who's FIB is lagging behind its RIB), no?

as an aside,

When we're doing a maintence we generally let the router converge with 
our route-reflectors prior to bringing up the transit/peer neighbors. so 
that routes learned from the transits are replacing existing fib routes. 
that also has a salubrious interaction with our loose rpf check. 
spontaneous reboots aren't quite adjustable like that.
>
> -----Original Message-----
> From: juniper-nsp-bounces at puck.nether.net
> [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Paul Stewart
> Sent: Tuesday, 12 February 2013 12:43 PM
> To: 'Juniper NSP'
> Subject: Re: [j-nsp] MX80 BGP performance after reboot
>
> I was there for that lightning talk (and very recently seen that
> "feature"
> actually happening) but what's getting described here by the OP doesn't
> seem to be the same.... maybe I'm misunderstanding.
>
> Paul
>
> -----Original Message-----
> From: juniper-nsp-bounces at puck.nether.net
> [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Jeff Wheeler
> Sent: February-11-13 6:59 PM
> To: Juniper NSP
> Subject: Re: [j-nsp] MX80 BGP performance after reboot
>
> On Mon, Feb 11, 2013 at 6:15 PM, Sebastian Wiesinger
> <juniper-nsp at ml.karotte.org> wrote:
>> I noticed that a MX80 takes quite a long time after reboot to put all
>> routes into the KRT. Is that normal for that box? It takes around 10
>> minutes after BGP is established to get all the routes into the KRT
> Yes, the routes taking a long time to install is "normal,"
> unfortunately.  I feel like it has got worse since 10.4 but that might
> be my imagination.
>
> I am sorry I missed Richard Steenbergen's lightning talk at NANOG, which
> was something like "if you want your routers to install routes, call
> Juniper and reference PR#<whatever> because they do not want to fix this
> bug."
>
> I am hopeful that the move away from a single Junos release strategy to
> some segregation among different products will allow Juniper to be more
> flexible in how they allocate development resources to different
> platforms.
>
> If I had to guess, I'd say the ddos-related log messages you are reading
> are related to excessive need to generate ttl_exceeded packets because
> of routing loops while BGP is announcing to neighboring routers but the
> routes are not actually installed in the FIB yet.
> Even if I am wrong about the specifics here, I am certain it is only a
> symptom of the problem which is unrelated to the ddos-protection
> feature.
>
> --
> Jeff S Wheeler <jsw at inconcepts.biz>
> Sr Network Operator  /  Innovative Network Concepts
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> --
> Message  protected by MailGuard: e-mail anti-virus, anti-spam and
> content filtering.http://www.mailguard.com.au/mg
>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>