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-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@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-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@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-...@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 <j...@inconcepts.biz>
Sr Network Operator / Innovative Network Concepts
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list juniper-nsp@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
