Re: [c-nsp] Faster BGP Failover

[Asbjorn Hojmark - Lists]

On Thu, 20 Oct 2011 21:51:40 +0200, you wrote:

 I agree that it should be default these days (it is in XR & NX-OS),

>>> Honestly, if you guys were to get into changing the defaults, I
>>> think "no ip proxy-arp" should really be top of the list ;o)

>> That too is off by default in XR and NX-OS.

> For ASR 9000 the doku and my life-configuration says "proxy-arp" is
> off by default.

Yeah, I meant that proxy ARP is off by default in the modern OSs.

-A

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Faster BGP Failover

[Tim Kleefass]

On 20.10.2011 8:36 PM, Asbjorn Hojmark - Lists wrote:
>>> I agree that it should be default these days (it is in XR & NX-OS),
> 
>> Honestly, if you guys were to get into changing the defaults, I
>> think "no ip proxy-arp" should really be top of the list ;o)
> 
> That too is off by default in XR and NX-OS.

For ASR 9000 the doku and my life-configuration says "proxy-arp" is off
by default.

Cheers,
Tim
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Faster BGP Failover

[Phil Mayers]

On 10/20/2011 07:36 PM, Asbjorn Hojmark - Lists wrote:

I agree that it should be default these days (it is in XR&  NX-OS),



Honestly, if you guys were to get into changing the defaults, I
think "no ip proxy-arp" should really be top of the list ;o)


That too is off by default in XR and NX-OS.


Great. All I've got to do now is drop a few hundred thousand on a 
forklift upgrade to a new platform, and I'll save myself a couple of 
hundred lines in the NVGEN!


Seriously - it's good they changed it. But I will not accept they can't 
change defaults in IOS. The move to 15.0 was a perfect (missed) 
opportunity to change the defaults to something sane.

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Faster BGP Failover

[Asbjorn Hojmark - Lists]

>> I agree that it should be default these days (it is in XR & NX-OS),

> Honestly, if you guys were to get into changing the defaults, I
> think "no ip proxy-arp" should really be top of the list ;o)

That too is off by default in XR and NX-OS.

-A

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Faster BGP Failover

[Tim Franklin]

> in most cases we rather not change defaults (yes, I know, there have
> been too many cases where we did, incl. without notice)

Wonder of hindsight I know, but the recent bump of *3* major version numbers 
would have been a really good place to clean out a whole bunch of defaults that 
are no longer best-practice (or even sane).  "IOS 15 - now *fully* classless 
out of the box" would have been fantastic, but I understand this makes some 
Enterprise people cry ;)
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Faster BGP Failover

[Nick Hilliard]

On 14/10/2011 05:17, Oliver Boehmer (oboehmer) wrote:
> in most cases we rather not change defaults (yes, I know, there have
> been too many cases where we did, incl. without notice),

that 18 month period where "mop enabled" was turned on still leaves me
scratching my head.

Nick
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Faster BGP Failover

[Gert Doering]

Hi,

On Fri, Oct 14, 2011 at 08:31:26AM +0100, Phil Mayers wrote:
> Honestly, if you guys were to get into changing the defaults, I think 
> "no ip proxy-arp" should really be top of the list ;o)

+2173

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


pgpq3c2R9SLLU.pgp
Description: PGP signature
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Faster BGP Failover

[Phil Mayers]

On 10/14/2011 05:17 AM, Oliver Boehmer (oboehmer) wrote:


I agree that it should be default these days (it is in XR&  NX-OS), but
so should be lower spf/lsa-throttle timers.


Honestly, if you guys were to get into changing the defaults, I think 
"no ip proxy-arp" should really be top of the list ;o)

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Faster BGP Failover

[Peter Rathlev]

On Fri, 2011-10-14 at 12:02 +0800, Mark Tinka wrote:
> > The "Usage Guidelines" for IOS 12.2 Routing
> > Protocols do not mention any, but there must be a reason
> > why it's not default. Or isn't there?
> 
> Well, we haven't any problems with it. 

And I now see that 15.1(2)S has it enabled by default.

http://www.cisco.com/en/US/docs/ios/iproute_pi/command/reference/iri_pi1.html#wp1013065

Guess it was just a matter of time then. :-)

-- 
Peter


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Faster BGP Failover

[Oliver Boehmer (oboehmer)]

 
> On Thu, 2011-10-13 at 23:35 +0800, Mark Tinka wrote:
> > On Thursday, October 13, 2011 10:27:00 PM Kevin Hodle wrote:
> > > ip routing protocol purge interface
> >
> > A knob that's a must on all our IOS routing devices.
> 
> Are there no downsides to this at all? Does that depend on platform?
The
> "Usage Guidelines" for IOS 12.2 Routing Protocols do not mention any,
> but there must be a reason why it's not default. Or isn't there?

in most cases we rather not change defaults (yes, I know, there have
been too many cases where we did, incl. without notice), and in some
smaller-scaled untuned OSPF network scenarios the RIB purge actually has
some benefits (could take up a floating static ~5 secs quicker, for
example in a spoke node with a backup). so changing the default has some
implications.
I agree that it should be default these days (it is in XR & NX-OS), but
so should be lower spf/lsa-throttle timers.

oli

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Faster BGP Failover

[Mark Tinka]

On Friday, October 14, 2011 05:08:26 AM Peter Rathlev wrote:

> Are there no downsides to this at all?

None that I have seen. Been running it since it came out.

> Does that depend
> on platform?

Not sure.

We use on the NPE-G1/G2 with SRE.

The command is present in IOS XE, but when we deploy it is 
doesn't appear in the running configuration. Maybe that 
means it's on by default.

We use it on the ME3600X, although in 12.2(52)EY*, the 
command has a nasty habit of being disabled after reboots. 
You can simply put it back (CSCtk67412).

We use on the 3560G switch with 12.2(52)SE or later.

It's not supported in IOS XR, probably because that has PIC.

> The "Usage Guidelines" for IOS 12.2 Routing
> Protocols do not mention any, but there must be a reason
> why it's not default. Or isn't there?

Well, we haven't any problems with it. 

Cheers,

Mark.


signature.asc
Description: This is a digitally signed message part.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Faster BGP Failover

[Peter Rathlev]

On Thu, 2011-10-13 at 23:35 +0800, Mark Tinka wrote:
> On Thursday, October 13, 2011 10:27:00 PM Kevin Hodle wrote:
> > ip routing protocol purge interface
> 
> A knob that's a must on all our IOS routing devices.

Are there no downsides to this at all? Does that depend on platform? The
"Usage Guidelines" for IOS 12.2 Routing Protocols do not mention any,
but there must be a reason why it's not default. Or isn't there?

http://www.cisco.com/en/US/docs/ios/12_2/iproute/command/reference/1rfindp1.html#wp1053743

-- 
Peter


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Faster BGP Failover

[Mark Tinka]

On Thursday, October 13, 2011 10:27:00 PM Kevin Hodle wrote:

> ip routing protocol purge interface

A knob that's a must on all our IOS routing devices.

Mark.


signature.asc
Description: This is a digitally signed message part.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Faster BGP Failover

[Kevin Hodle]

As others have mentioned, your total time to re-converge is bounded by
a number of different variables, and there are multiple aspects to
consider. With regards to rapid failure detection, BFD is the optimal
solution and most competent service providers will run BFD with you on
transit eBGP sessions if you really push them for it. For optimizing
convergence *after* a failure is detected, you will get the biggest
'bang for your buck' with Cisco's prefix independent convergence (PIC)
feature, which takes advantage of a hierarchical RIB design allowing
next-hop pointers for many  BGP RIB entries to be quickly
reprogrammed, as opposed to the flattened RIB structure where total
time to update RIB structures after a failure can be dramatic.
Unfortunately this functionality has only emerged *natively* in IOS
XR. More recent IOS releases for the 7600 series claim to support BGP
PIC, however from what I understand because of architectural
limitations, this is more of a hack and its usefulness is probably
limited.

... That said, depending on your IOS version, you could potentially
optimize the time required to purge all RIB entries whose next-hop
becomes invalid, the configuration knob:

ip routing protocol purge interface

This allows for most routing protocols to be signaled directly after a
link failure and gives them a shortcut to purge all RIB entries they
associate with the downed interface. Without this, the normal behavior
is for IOS to trigger the RIB update process to perform a full table
walk to remove entries with invalidated next-hops.  This delay can be
significant depending on hardware and total RIB size.

Cheers,
Kevin

On Tue, Oct 11, 2011 at 10:25 AM, Vincent Aniello
 wrote:
> What can be done to reduce the amount of time it takes BGP to detect the 
> failure of an Internet connection and start routing traffic through another 
> Internet connection?
>


-- 

 :: :: Kevin Hodle | http://www.linkedin.com/in/kevinhodle
 :: :: PGP Key ID  | fingerprint
 :: :: 0x803F24BE  | 1094 FB06 837F 2FAB C86B E4BE 4680 3679 803F 24BE

"Elegance is not a dispensable luxury but a factor that decides
between success and failure. "
-Edsger Dijkstra


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Faster BGP Failover

[Robert Raszuk]

Failure detection is only the first step in BGP reconvergence - and if
you have two links to different ISPs, reconvergence times will be in the
order of minutes anyway, so tuning down fault detection from "30s" to "1s"
will not make failover instant anyway.


Very interesting discussion ... sorry for late reading, but I was in 
long haul transit :)


Few observations ... There are few components ...

- preparation
- detection
- reaction

Let me explain.

- preparation ... it really means that you should have a backup path in 
place via different exit point (or multiple local paths what may not be 
easy). If your other exit is via different ASBR I do recommend at the 
current state of the technology to use Diverse-Path on RR to send backup 
path towards the best path's ASBR. This is shipping feature in cisco 
*well yes I am biased .. I have designed that one :)* When all routers 
talk add-paths you could switch to that.


- detection ... reducing hold time in BGP is a bad idea. if the goal is 
to converge in 1-3 sec max I recommend (if BFD is not an option - even 
single side BFD) use a very unknown IOS feature called "Object 
Tracking". It is a piece of excellent code written by cisco EMEA 
developers which can invalidate your next hop based on periodic ping 
(every time X) to peering ASBR. Very cool tool.


- reaction ... yes PIC is the best way. You preprogram to FIB backup 
paths then just at the failure time switchover to backup not per net but 
per next hop speed at any BGP switching node ... assuming no intra-as 
tunneling. If there is tunneling you just need to switch once.


Best,
R.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Faster BGP Failover

[Mark Tinka]

On Thursday, October 13, 2011 02:52:52 PM Gert Doering 
wrote:

> I wrote that a few days ago already: if you want really
> fast reconvergence, use two links to the *same* ISP, and
> BFD-with-BGP on that.

Yes, that's one of the reasons we didn't go with it, because 
it seemed to make more sense if our customer had multiple 
links to us, rather than one to us and another to another 
ISP.

Cheers,

Mark.


signature.asc
Description: This is a digitally signed message part.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Faster BGP Failover

[Gert Doering]

Hi,

On Wed, Oct 12, 2011 at 10:12:45PM -0500, Ryan Wilkins wrote:
> My question is why would you not consider it?  

Failure detection is only the first step in BGP reconvergence - and if
you have two links to different ISPs, reconvergence times will be in the
order of minutes anyway, so tuning down fault detection from "30s" to "1s"
will not make failover instant anyway.

Mix "lame ISP" into the mix, like the "we spend more time on peering wars 
than on improving our network" one, and there's other approaches that will
improve reliability far more than BFD.


I wrote that a few days ago already: if you want really fast reconvergence, 
use two links to the *same* ISP, and BFD-with-BGP on that.

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


pgp8Bryn9wRyM.pgp
Description: PGP signature
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Faster BGP Failover

[Mark Tinka]

On Thursday, October 13, 2011 11:12:45 AM Ryan Wilkins 
wrote:

> My question is why would you not consider it?

In all fairness, we started using BFD when it dropped about 
4 years ago or more. Then, the majority of our routers were 
7200's, and we didn't want to overload the CPU with BFD 
hellos to infrastructure that wasn't ours.

Same reason we generally disable IETF Graceful Restart 
toward eBGP sessions, especially since it's moot - but I 
digress.

Perhaps, for us, the reason is still the same - reducing 
overhead as much as possible on edge boxes that generally 
tend to be quite busy. More so if it's a software box.

I suppose if we move to platforms that implement BFD in 
hardware (I know Juniper have a so-called Distributed PPM 
[Periodic Packet Management] protocol that allows BFD, CFM, 
LFM and LACP, RSTP, MSTP, e.t.c., to run in hardware on 
their M7i, M10i, M120, M320, MX, T and TX Matrix routers and 
EX switches), then we may be open to reconsidering its use 
outside of our core infrastructure.

We do have tons of Juniper kit in the network, running in 
the edge where PPM is enabled by default in hardware, but 
haven't had customers asking for BFD for eBGP.

I know the ASR9000 doesn't implement BFD in hardware today, 
but uncertain about other platforms in Cisco's stable, 
particularly the newer ones.

Cheers,

Mark.


signature.asc
Description: This is a digitally signed message part.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Faster BGP Failover

[Ryan Wilkins]

My question is why would you not consider it?  I support a couple ISPs and am 
considering asking AboveNet and Cogent to run BFD with one of the ISPs where 
there are two BGP sessions established to each upstream already.  Everything 
I've read seems to indicate that BFD decreases the failover time and with less 
resources than using low timers on BGP to do the same thing.  I also have a 
customer with two wireless links to the same ISP, one 1 Gbps link that quits 
working when it rains heavily and a 300 Mbps link that doesn't quit in the 
heavy rains come.  I've configured the customer to run BGP (default route) with 
BFD for failover purposes and it works beautifully.  I just trying to 
understand why ISPs wouldn't or shouldn't do this.  Any insights?


On Oct 12, 2011, at 9:14 PM, Mark Tinka  wrote:

> On Wednesday, October 12, 2011 09:20:53 PM Vincent Aniello 
> wrote:
> 
>>> From a technical perspective they aren't, but I have
>>> never seen an ISP offer BFD.
> 
> We generally don't offer customer's BFD over eBGP sessions. 
> Then again, in the last 4 years or so, we've probably only 
> had one request, and that didn't go through because the 
> customer's router didn't have the requisite code.
> 
> We are, however, considering running BFD for eBGP with one 
> of our customers that sends IPTv traffic into our Multicast 
> network for onward delivery to their subscribers. Of course, 
> IPTv is a much more sensitive application where we could 
> make the exception, but otherwise wouldn't look at deploying 
> it with ordinary customers.
> 
> Mark.
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Faster BGP Failover

[Mark Tinka]

On Wednesday, October 12, 2011 09:20:53 PM Vincent Aniello 
wrote:

> >From a technical perspective they aren't, but I have
> >never seen an ISP offer BFD.

We generally don't offer customer's BFD over eBGP sessions. 
Then again, in the last 4 years or so, we've probably only 
had one request, and that didn't go through because the 
customer's router didn't have the requisite code.

We are, however, considering running BFD for eBGP with one 
of our customers that sends IPTv traffic into our Multicast 
network for onward delivery to their subscribers. Of course, 
IPTv is a much more sensitive application where we could 
make the exception, but otherwise wouldn't look at deploying 
it with ordinary customers.

Mark.


signature.asc
Description: This is a digitally signed message part.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Faster BGP Failover

[Vincent Aniello]

> Why do you believe that BFD and Internet connection is mutually exclusive?

>From a technical perspective they aren't, but I have never seen an ISP offer 
>BFD.

--Vincent


Disclaimer: Any references to Pipeline performance contained herein are based 
on internal testing and / or historic performance levels which Pipeline expects 
to maintain or exceed but nevertheless does not guarantee.  Congested networks, 
price volatility, or other extraordinary events may impede future trading 
activities and degrade performance statistics. Pipeline is a member of FINRA 
and SIPC.

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Faster BGP Failover

[Phil Mayers]

On 12/10/11 11:27, Mikael Abrahamsson wrote:

On Tue, 11 Oct 2011, Vincent Aniello wrote:


I do not believe that BFD is an option since these are Internet
connections.


Why do you believe that BFD and Internet connection is mutually exclusive?

I wish more ISPs would use BFD on their IX connections, even if it was
only 1s/3s setting (quite conservative and works even on BFDonRP based
platforms), compared to 180s today it's a huge improvement.



In fairness, vendor idiocy ("Cisco have removed BFD on SVIs on the 
6500") probably doesn't help; it's damn annoying that BFD isn't 
pervasive. It's a great solution for e.g. fast HSRP failover too.

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Faster BGP Failover

[Mikael Abrahamsson]

On Tue, 11 Oct 2011, Vincent Aniello wrote:

I do not believe that BFD is an option since these are Internet 
connections.


Why do you believe that BFD and Internet connection is mutually exclusive?

I wish more ISPs would use BFD on their IX connections, even if it was 
only 1s/3s setting (quite conservative and works even on BFDonRP based 
platforms), compared to 180s today it's a huge improvement.


--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Faster BGP Failover

[Javier Henderson]

On Oct 11, 2011, at 3:12 PM, Keegan Holley wrote:

> 2011/10/11 Devon True 
> 
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>> 
>> On 10/11/2011 1:41 PM, Keegan Holley wrote:
>>> BGP timers are negotiated to the lowest value so even if your
>>> carrier doesn't like it they won't be able to stop you.  This will
>>> also save you the trouble of opening a ticket or requesting that
>>> this be done.
>> 
>> Unless the carrier specified a minimum hold time allowed.
>> 
>> router(config-router)#timers bgp 10 10 ?
>> <0-65535>  Minimum hold time from neighbor
>> 
>> 
>> 
> Interesting.  I would assume there would be a command for this. I've never
> had 10/30 not work in practice though so I suppose the limit is this or
> lower.

The minimum neighbor hold time is optional. If specified it has to be less than 
or equal to the interval specified for the "holdtime" argument (default for 
that is 180 seconds).

-jav




___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Faster BGP Failover

[Keegan Holley]

2011/10/11 Devon True 

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 10/11/2011 1:41 PM, Keegan Holley wrote:
> > BGP timers are negotiated to the lowest value so even if your
> > carrier doesn't like it they won't be able to stop you.  This will
> > also save you the trouble of opening a ticket or requesting that
> > this be done.
>
> Unless the carrier specified a minimum hold time allowed.
>
> router(config-router)#timers bgp 10 10 ?
>  <0-65535>  Minimum hold time from neighbor
>  
>
>
Interesting.  I would assume there would be a command for this. I've never
had 10/30 not work in practice though so I suppose the limit is this or
lower.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Faster BGP Failover

[Gert Doering]

HI,

On Tue, Oct 11, 2011 at 05:02:45PM +, Vincent Aniello wrote:
> > Can you be a bit more specific about the config?
> 
> We have two routers, the first router has two Internet connections,
> ISP A and ISP B.  The second router has a backup connection to ISP
> A.  All three connections take a full BGP routing table and the
> two routers peer with each other via iBGP.  The connections to the
> ISPs are Ethernet.  We recently had a failure of ISP B and the
> Ethernet interface stayed up, but the BGP peer went down, which is
> what prompted this question.

Actually this is really what BFD was invented for: fast low-weight
hellos to make sure that the link is still operational, and if not,
quick signalisation to the routing protocols (here: BGP) that it's
broken.

The fact that ISPs currently don't usually offer BFD doesn't mean it
couldn't or shouldn't be done.  It just means customers are not asking
often enough.

(OTOH, even if your BFD/BGP session would notice in 0.5 seconds that 
the link failed, it would still take a few minutes for The Whole 
Internet to reconverge - so don't expect miracles from global BGP.  
If you want *fast* failover, get two links to the same ISP, and use 
BGP+BFD there - only local convergence needed, not global)

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


pgpFy5wvPWW8H.pgp
Description: PGP signature
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Faster BGP Failover

[Devon True]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/11/2011 1:41 PM, Keegan Holley wrote:
> BGP timers are negotiated to the lowest value so even if your 
> carrier doesn't like it they won't be able to stop you.  This will 
> also save you the trouble of opening a ticket or requesting that 
> this be done.

Unless the carrier specified a minimum hold time allowed.

router(config-router)#timers bgp 10 10 ?
  <0-65535>  Minimum hold time from neighbor
  

- -- 
Devon
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6UhKoACgkQWP2WrBTHBS/2sACfQHeL7YDNwzfMfSZbbbRkezAG
BBAAnjWAgpS8D68lxYKu4vbpL2g0O/7X
=hoU5
-END PGP SIGNATURE-
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Faster BGP Failover

[Keegan Holley]

2011/10/11 Vincent Aniello 

> > Can you be a bit more specific about the config?
>
> We have two routers, the first router has two Internet connections, ISP A
> and ISP B.  The second router has a backup connection to ISP A.  All three
> connections take a full BGP routing table and the two routers peer with each
> other via iBGP.  The connections to the ISPs are Ethernet.  We recently had
> a failure of ISP B and the Ethernet interface stayed up, but the BGP peer
> went down, which is what prompted this question.
>

Do you know how fast this needs to be? The best answer is probably to just
shorten your timers.  Providers aren't running BFD with customers as far as
I know.  You should be able to set them to 10/30 , or 5/20.  BGP timers are
negotiated to the lowest value so even if your carrier doesn't like it they
won't be able to stop you.  This will also save you the trouble of opening a
ticket or requesting that this be done.


> > This is presumably an eBGP session across a local interface?
>
> Correct.
>
> > What platform & IOS version?
>
> 7206 routers running the 12.4T IOS train.
>
> Thanks.
>
> --Vincent
>
>
>
> Disclaimer: Any references to Pipeline performance contained herein are
> based on internal testing and / or historic performance levels which
> Pipeline expects to maintain or exceed but nevertheless does not guarantee.
>  Congested networks, price volatility, or other extraordinary events may
> impede future trading activities and degrade performance statistics.
> Pipeline is a member of FINRA and SIPC.
>
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Faster BGP Failover

[Vincent Aniello]

> Can you be a bit more specific about the config?

We have two routers, the first router has two Internet connections, ISP A and 
ISP B.  The second router has a backup connection to ISP A.  All three 
connections take a full BGP routing table and the two routers peer with each 
other via iBGP.  The connections to the ISPs are Ethernet.  We recently had a 
failure of ISP B and the Ethernet interface stayed up, but the BGP peer went 
down, which is what prompted this question.

> This is presumably an eBGP session across a local interface?

Correct.

> What platform & IOS version?

7206 routers running the 12.4T IOS train.

Thanks.

--Vincent



Disclaimer: Any references to Pipeline performance contained herein are based 
on internal testing and / or historic performance levels which Pipeline expects 
to maintain or exceed but nevertheless does not guarantee.  Congested networks, 
price volatility, or other extraordinary events may impede future trading 
activities and degrade performance statistics. Pipeline is a member of FINRA 
and SIPC.

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Faster BGP Failover

[Chuck Church]

As long as your neighbor doesn't mind more frequent hellos, there's no
reason you can't lower the hello and hold timers.  My 2821 with a couple
full views has run hello 5, hold 20 seconds for years, no issues.

Chuck

-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Vincent Aniello
Sent: Tuesday, October 11, 2011 11:26 AM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] Faster BGP Failover

What can be done to reduce the amount of time it takes BGP to detect the
failure of an Internet connection and start routing traffic through another
Internet connection?

We've already reduced the BGP hold-time to 90 seconds.  Can the hold-time be
reduced further without causing other problems?  I do not believe that BFD
is an option since these are Internet connections.  Are there any other
options for reducing the failover time?

Thanks.

--Vincent



Disclaimer: Any references to Pipeline performance contained herein are
based on internal testing and / or historic performance levels which
Pipeline expects to maintain or exceed but nevertheless does not guarantee.
Congested networks, price volatility, or other extraordinary events may
impede future trading activities and degrade performance statistics.
Pipeline is a member of FINRA<http://www.finra.org/> and
SIPC<http://www.sipc.org/>.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Faster BGP Failover

[Phil Mayers]

On 11/10/11 16:54, Seth Mattinen wrote:

On 10/11/11 8:50 AM, Phil Mayers wrote:

On 11/10/11 16:25, Vincent Aniello wrote:

What can be done to reduce the amount of time it takes BGP to detect
the failure of an Internet connection and start routing traffic
through another Internet connection?


Can you be a bit more specific about the config?

This is presumably an eBGP session across a local interface?

What platform&  IOS version?

eBGP sessions should, IIRC, be immediately torn down by the fast
external fallover feature.



If it's an Ethernet though that won't do much since the link is likely
always staying up/up.


That depends entirely on the topology. If there's an intermediate 
network device, then yes. But that's a bad configuration, and should be 
avoided if at all possible, for exactly that reason.


Obviously point-to-point ethernet will fail the link almost immediately 
if either end goes down.

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Faster BGP Failover

[Seth Mattinen]

On 10/11/11 8:50 AM, Phil Mayers wrote:
> On 11/10/11 16:25, Vincent Aniello wrote:
>> What can be done to reduce the amount of time it takes BGP to detect
>> the failure of an Internet connection and start routing traffic
>> through another Internet connection?
> 
> Can you be a bit more specific about the config?
> 
> This is presumably an eBGP session across a local interface?
> 
> What platform & IOS version?
> 
> eBGP sessions should, IIRC, be immediately torn down by the fast
> external fallover feature.
> 

If it's an Ethernet though that won't do much since the link is likely
always staying up/up.

~Seth
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Faster BGP Failover

[chip]

Might want to take a look at BGP PIC.  It won't necessarily help with
failure detection but can greatly speed convergence to get traffic
onto a working path quicker.
http://www.cisco.com/en/US/docs/ios/iproute_bgp/configuration/guide/irg_bgp_mp_pic_ps10890_TSD_Products_Configuration_Guide_Chapter.html

*NOTE* I havent' configured it, but have been looking at it.

--chip

On Tue, Oct 11, 2011 at 11:25 AM, Vincent Aniello
 wrote:
> What can be done to reduce the amount of time it takes BGP to detect the 
> failure of an Internet connection and start routing traffic through another 
> Internet connection?
>
> We've already reduced the BGP hold-time to 90 seconds.  Can the hold-time be 
> reduced further without causing other problems?  I do not believe that BFD is 
> an option since these are Internet connections.  Are there any other options 
> for reducing the failover time?
>
> Thanks.
>
> --Vincent
>
>
>
> Disclaimer: Any references to Pipeline performance contained herein are based 
> on internal testing and / or historic performance levels which Pipeline 
> expects to maintain or exceed but nevertheless does not guarantee.  Congested 
> networks, price volatility, or other extraordinary events may impede future 
> trading activities and degrade performance statistics. Pipeline is a member 
> of FINRA and SIPC.
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>



-- 
Just my $.02, your mileage may vary,  batteries not included, etc

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Faster BGP Failover

[Phil Mayers]

On 11/10/11 16:25, Vincent Aniello wrote:

What can be done to reduce the amount of time it takes BGP to detect
the failure of an Internet connection and start routing traffic
through another Internet connection?


Can you be a bit more specific about the config?

This is presumably an eBGP session across a local interface?

What platform & IOS version?

eBGP sessions should, IIRC, be immediately torn down by the fast 
external fallover feature.


Fast detection of iBGP session is a bit more involved, and requires the 
"neighbor fall-over" command.

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] Faster BGP Failover

[Vincent Aniello]

What can be done to reduce the amount of time it takes BGP to detect the 
failure of an Internet connection and start routing traffic through another 
Internet connection?

We've already reduced the BGP hold-time to 90 seconds.  Can the hold-time be 
reduced further without causing other problems?  I do not believe that BFD is 
an option since these are Internet connections.  Are there any other options 
for reducing the failover time?

Thanks.

--Vincent



Disclaimer: Any references to Pipeline performance contained herein are based 
on internal testing and / or historic performance levels which Pipeline expects 
to maintain or exceed but nevertheless does not guarantee.  Congested networks, 
price volatility, or other extraordinary events may impede future trading 
activities and degrade performance statistics. Pipeline is a member of 
FINRA and SIPC.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/