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: j...@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 [mpet...@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 <j...@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: j...@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.nordd...@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 >
