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-
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 a
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.
>> 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
___
> 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 lon
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
_
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!
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
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 def
> 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?
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
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 Guid
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 li
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 session
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 ... sorr
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
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 do
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
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
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
> 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 perfo
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 connecti
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
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
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
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
-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
> thi
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 router
> 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. T
t
[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
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?
C
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
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.h
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 sessio
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?
35 matches
Mail list logo
