Re: [j-nsp] Krt queue issues

[Tim Vollebregt <tim () interworx nl>]

Hi,

What we do nowadays as some workaround, is configuring a default route towards a core router on 8 x 10G before 
maintaining an MX box. Which will be installed before BGP sessions come up, this will cause some packet loss during 
burst hour outages but is fine during maintenance hours. 

I've seen cases where it took up to 30 minutes before the full table was installed correctly in the PFE's.

Currently this issue/bug is holding back our Juniper deployments. As far as I know Juniper created a project group for 
this bug, and so far they were able to reproduce the issue. Looks like the issue is being taken serious from now.

Tim

On Oct 3, 2012, at 11:50 PM, Naslund, Steve wrote:

> I think route retention might help in the event the table was cleared or
> routing process restarted but I don't that it will help with a boot
> because the table structures are being built as part of the system
> initialization.  In reality, I would expect the static routes to get
> installed very early as soon as the routing process comes up.  Since you
> will need a route to your BGP neighbor (even though it may be directly
> connected, it is still a route), routing has to be up BEFORE BGP
> establishes and by definition your static routes will have to be up
> before your BGP routes are ready.  How well your router responds to
> traffic during an initial boot and during a 300,000 route update is
> another story.  My experience with very large routers and tables is that
> you will have a hard time guaranteeing user traffic will pass with very
> much performance during an event like a full table rebuild.  Luckily
> with the bandwidth we have these days and the CPU power on the routers,
> it does not take that long to pull in a full internet table and begin
> handling traffic.
>
> Steven Naslund
>
> -----Original Message-----
> From: Jensen Tyler [mailto:JTyler () fiberutilities com] 
> Sent: Wednesday, October 03, 2012 9:45 AM
> To: nanog () nanog org
> Subject: RE: [j-nsp] Krt queue issues
>
> Look into Static route retain. Should keep the route in the forwarding
> table.
>
> From Jniper site
> <<<
> Route Retention
>
> By default, static routes are not retained in the forwarding table when
> the routing process shuts down. When the routing process starts up
> again, any routes configured as static routes must be added to the
> forwarding table again. To avoid this latency, routes can be flagged as
> retain, so that they are kept in the forwarding table even after the
> routing process shuts down. Retention ensures that the routes are always
> in the forwarding table, even immediately after a system reboot.
> > > >
>
> Thanks,
>
> Jensen Tyler
> Sr Engineering Manager
> Fiberutilities Group, LLC
>
>
> -----Original Message-----
> From: juniper-nsp-bounces () puck nether net
> [mailto:juniper-nsp-bounces () puck nether net] On Behalf Of Benny Amorsen
> Sent: Wednesday, October 03, 2012 8:32 AM
> To: Jared Mauch
> Cc: Saku Ytti; juniper-nsp () puck nether net
> Subject: Re: [j-nsp] Krt queue issues
>
> Jared Mauch <jared () puck nether net> writes:
>
> > As far as the fallback 'default' route, if you are purchasing transit 
> > from someone, you could consider a last-resort default pointed at 
> > them. You can exclude routes like 10/8 etc by routing these to discard
> > + install on your devices.
>
> That only helps if the default gets installed first, though. If the
> default has to wait at boot in the krt-queue behind the 300k+
> Internet-routes, I have not really gained anything...
>
> I suppose it is likely that a static default would be installed before
> the BGP sessions even come up.
>
>
> /Benny
> _______________________________________________
> juniper-nsp mailing list juniper-nsp () puck nether net
> https://puck.nether.net/mailman/listinfo/juniper-nsp