Re: route converge time

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

RE: route converge time

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 t

Re: route converge time

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 wrote: > > One thing I notice you don't mention is whether your > BGP sessions to your upstream providers are direct > or multi-hop

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

Re: route converge time

t; > -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

RE: route converge time

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

Re: route converge time

On Sat, Nov 28, 2015 at 10:45 PM, Jürgen Jaritsch wrote: >> From: Matthew Petach [mpet...@netflight.com] >> >> 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,

Re: route converge time

Would be helpful if you let us know what platform you're running on. Assuming a Cisco, make sure next-hop-tracking not disabled (enabled by default on modern IOS), then at "BGP Prefix Independent Convergence", so your BGP process isn't walking the entire RIB to see which next-hops it needs to

Re: route converge time

What types of routers are you currently using? On Sat, Nov 21, 2015 at 7:44 AM, Baldur Norddahl 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 >

Re: route converge time

Baldur Norddahl writes: > Hi > > 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

route converge time

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

Re: route converge time

On Sat, Nov 21, 2015 at 8:44 AM, Baldur Norddahl wrote: > 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

RE: route converge time

@nanog.org Subject: route converge time 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