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, but gracefully b
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
ge-
> 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
9
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
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
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 eBGP. I know for a while so
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
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 chang
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
> provider B. We use MPLS with a L3VP
Hey,
This is a complex problems and there are quite a few parts to consider.
Let's assume you want to optimize how fast you choose the right best exit
after a failure. The opposite ( how fast the internet chooses the best entry
point into your network after a failure ) is usually not that easy
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 "internet".
> Everything happens ins
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 might not leave the most optima
12 matches
Mail list logo
