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@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@netflight.com] Received: Sonntag, 29 Nov. 2015, 2:21 CC: nanog@nanog.org [nanog@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@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@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@gmail.com] Received: Sonntag, 29 Nov. 2015, 0:39 To: nanog@nanog.org [nanog@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