route converge time

Sun Nov 29 03:45:28 UTC 2015

Route update via new policy could be more cpu intensive than dropping prefixes caused by session shutdown.

Best regards

Jürgen Jaritsch
Head of Network & Infrastructure

ANEXIA Internetdienstleistungs GmbH

Telefon: +43-5-0556-300
Telefax: +43-5-0556-500

E-Mail: jj at anexia.at
Web: http://www.anexia.at

Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt
Geschäftsführer: Alexander Windbichler
Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601

-----Original Message-----
From: Matthew Petach [mpetach at netflight.com]
Received: Sonntag, 29 Nov. 2015, 2:21
CC: nanog at nanog.org [nanog at nanog.org]
Subject: Re: route converge time

Or, better yet, apply a REJECT-ALL type policy
on the neighbor to deny all inbound/outbound
prefixes; that way, you can keep the session
up as long as possible, but gracefully bleed
traffic off ahead of your work.

Matt

On Sat, Nov 28, 2015 at 3:46 PM, Jürgen Jaritsch <jj at anexia.at> wrote:
> Hi,
>
> Why you not simply shut down the session upfront (before you turn down the link)?
>
> Best regards
>
>
> Jürgen Jaritsch
> Head of Network & Infrastructure
>
> ANEXIA Internetdienstleistungs GmbH
>
> Telefon: +43-5-0556-300
> Telefax: +43-5-0556-500
>
> E-Mail: jj at anexia.at
> Web: http://www.anexia.at
>
> Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt
> Geschäftsführer: Alexander Windbichler
> Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601
>
>
> -----Original Message-----
> From: Baldur Norddahl [baldur.norddahl at gmail.com]
> Received: Sonntag, 29 Nov. 2015, 0:39
> To: nanog at nanog.org [nanog at nanog.org]
> Subject: Re: route converge time
>
> Hi
>
> The IP transit links are direct links (not multihop). It is my impression
> that a link down event is handled with no significant delay by the router
> that has the link. The problem is the other router, the one that has to go
> through the first router to access the link the went down.
>
> The transit links are not unstable and in fact they have never been down
> due to a fault. But we are a young network and still frequently have to
> change things while we build it out. There have been cases where I have had
> to take down the link for various reasons. There seems to be no way to do
> this without causing significant disruption to the network.
>
> Our routers are 2015 hardware. The spec has 2M IPv4 + 1M IPv6 routes in FIB
> and 10M routes in RIB. Route convergence time is specified as 15k
> routes/second. 8 GB ram on the route engines.
>
> Say transit T1 is connected to router R1 and transit T2 is connected to
> router R2.
>
> I believe the underlying problem is that due to MPLS L3VPN the next hop on
> R2 for routes out through T1 is not the transit provider router as usual.
> Instead it is the loopback IP of R1. This means that when T1 goes down, the
> next hop is still valid and R2 is unable to deactivate the invalid routes
> as a group operation due to invalid next hop.
>
> I am considering adding a loopback2 interface that has a trigger on the
> transit interface, such that a shutdown on loopback2 is triggered if the
> transit interface goes down. And then force next hop to be loopback2. That
> way our IGP will signal that the next hop is gone and that should
> invalidate all the routes as a group operation.
>
> Regards,
>
> Baldur
>