route converge time

Jeff Tantsura jeff.tantsura at ericsson.com
Sat Nov 28 21:59:49 UTC 2015


In that case multihop BFD (if supported on both sides) would really help.

Regards,
Jeff

> On Nov 28, 2015, at 11:37 AM, Matthew Petach <mpetach at netflight.com> wrote:
> 
> One thing I notice you don't mention is whether your
> BGP sessions to your upstream providers are direct
> or multi-hop eBGP.  I know for a while some of the
> more bargain-basement providers were doing eBGP
> multi-hop feeds for full tables, which will definitely
> slow down convergence if the routers have to wait
> for hold timers to expire to flush routes, rather than
> being able to direct detect link state transitions.
> 
> Matt
> 
> 
> On Sat, Nov 21, 2015 at 5:44 AM, Baldur Norddahl
> <baldur.norddahl at gmail.com> wrote:
>> Hi
>> 
>> I got a network with two routers and two IP transit providers, each with
>> the full BGP table. Router A is connected to provider A and router B to
>> provider B. We use MPLS with a L3VPN with a VRF called "internet".
>> Everything happens inside that VRF.
>> 
>> Now if I interrupt one of the IP transit circuits, the routers will take
>> several minutes to remove the now bad routes and move everything to the
>> remaining transit provider. This is very noticeable to the customers. I am
>> looking into ways to improve that.
>> 
>> I added a default static route 0.0.0.0 to provider A on router A and did
>> the same to provider B on router B. This is supposed to be a trick that
>> allows the network to move packets before everything is fully converged.
>> Traffic might not leave the most optimal link, but it will be delivered.
>> 
>> Say I take down the provider A link on router A. As I understand it, the
>> hardware will notice this right away and stop using the routes to provider
>> A. Router A might know about the default route on router B and send the
>> traffic to router B. However this is not much help, because on router B
>> there is no link that is down, so the hardware is unaware until the BGP
>> process is done updating the hardware tables. Which apparently can take
>> several minutes.
>> 
>> My routers also have multipath support, but I am unsure if that is going to
>> be of any help.
>> 
>> Anyone got any tricks or pointers to what can be done to optimize the
>> downtime in case of a IP transit link failure? Or the related case of one
>> my routers going down or the link between them going down (the traffic
>> would go a non-direct way instead if the direct link is down).
>> 
>> Thanks,
>> 
>> Baldur
>> 



More information about the NANOG mailing list