Re: [c-nsp] Change BGP default-originate to IGP?

2012-10-10 Thread Tom Lanyon
Thanks for the tips, we'll have a play with some of the options suggested 
around originating the default.

On 05/10/2012, at 11:52 AM, Anton Kapela wrote:
 also +1 to inter-border router ibgp sessions over some other layer2
 path/port pair/etc -- one should always have that, unless you can't
 for some strange reason.


On 27/09/2012, at 11:24 PM, David Prall wrote:
 As well could put a GRE Tunnel or VLAN between the two ASR's and run iBGP
 between the two. You control the path between the two routers, so the tunnel
 can be over a jumbo frame capable path.


I'm glad a iBGP session between the ASRs over a GRE tunnel was mentioned, as 
that's exactly what we have running and I was questioning whether this was a 
bad practice or not...

Thanks,
Tom


___
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] Change BGP default-originate to IGP?

2012-10-10 Thread David Prall
-Original Message-
From: Tom Lanyon [mailto:tom+c-...@oneshoeco.com] 

I'm glad a iBGP session between the ASRs over a GRE tunnel was mentioned, as
that's exactly what we have running and I was questioning whether this was a
bad practice or not...

Thanks,
Tom

[dprall] It's the Duct Tape of Networking

David

--
http://dcp.dcptech.com





___
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] Change BGP default-originate to IGP?

2012-10-04 Thread Anton Kapela
On Thu, Sep 27, 2012 at 8:56 PM, Tom Lanyon tom+c-...@oneshoeco.com wrote:
 On 28/09/2012, at 4:03 AM, Christian Meutes wrote:
 The best way is here really to inject the defaults via ISIS.

 Great - that's my current thinking too.  I just wanted to double-check that 
 this was reasonable and I wasn't missing something!

Another option -- manually delay originating any bgp routes from the
ASR's to the 4900's with adjusted MRAI, to something, say 1.5x longer
than 'usual case' convergence:

http://www.cisco.com/en/US/docs/ios/iproute_bgp/command/reference/irg_bgp3.html#wp1105562

also +1 to inter-border router ibgp sessions over some other layer2
path/port pair/etc -- one should always have that, unless you can't
for some strange reason.

-Tk
___
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] Change BGP default-originate to IGP?

2012-09-27 Thread Adam Vitkovsky
So if I understood it correctly you are concerned that the router will start
to originate the default prior to receiving full BGP table from its upstream
right?
The simplest solution would be to place a static default route pointing to
the upstream -so in case of the above happens the router wouldn't blackhole
till it gets the full feed. 
Or you can base the condition of default advertisement on several prefixes
from all around the place instead of just one -but trying to match e.g. 10
prefixes from 400k well...
The problem with this though is that on IOS you can't AND the match ip
address statements under the route-map only OR -applies to all the match
statements of the same kind. 
So you could use static routes for the list of desired prefixes each with a
high AD -redistribute them into bgp with specific community and match for
the prefixes+community in non-exist map. 
So once you'll get all the prefixes from BGP -only after all cease to exist
in the bgp table with the specific community of yours -the router will start
to advertise the default route. 

adam
-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Tom Lanyon
Sent: Thursday, September 27, 2012 4:58 AM
To: David Prall; cisco-nsp
Subject: Re: [c-nsp] Change BGP default-originate to IGP?

Is there a specific order in which BGP updates are sent/exchanged/processed?

The concern I have with tracking upstream routes is that the route tracked
would need to be one of the last routes received (if not the last) to ensure
that the router has full visibility.  This seems quite non-deterministic and
so potentially fraught with 'weirdness'.

Thanks,
Tom

On 27/09/2012, at 12:19 PM, David Prall wrote:
 Why not use selective advertisement of the default based on receiving 
 a specific route from your carrier or an upstream you know to be stable.
 
 http://www.cisco.com/en/US/docs/ios/12_3/iproute/command/reference/ip2
 _n1g.h
 tml#wp1037042
 
 David


___
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] Change BGP default-originate to IGP?

2012-09-27 Thread Blake Dunlap
Another option is to lock the static default route to a tracked object, and
based that object on eem scripting or something similar which has a built
in delay after the bgp peer reaches X prefix count.

It's definitely more creaky though. Something you should keep in mind is
you're going to have some blackholing regardless of what you do, due to the
return path experiencing the same issue as it propagates out. It's just a
question of what levels you are comfortable with.

-Blake

On Thu, Sep 27, 2012 at 3:40 AM, Adam Vitkovsky adam.vitkov...@swan.skwrote:

 So if I understood it correctly you are concerned that the router will
 start
 to originate the default prior to receiving full BGP table from its
 upstream
 right?
 The simplest solution would be to place a static default route pointing to
 the upstream -so in case of the above happens the router wouldn't blackhole
 till it gets the full feed.
 Or you can base the condition of default advertisement on several prefixes
 from all around the place instead of just one -but trying to match e.g. 10
 prefixes from 400k well...
 The problem with this though is that on IOS you can't AND the match ip
 address statements under the route-map only OR -applies to all the match
 statements of the same kind.
 So you could use static routes for the list of desired prefixes each with a
 high AD -redistribute them into bgp with specific community and match for
 the prefixes+community in non-exist map.
 So once you'll get all the prefixes from BGP -only after all cease to exist
 in the bgp table with the specific community of yours -the router will
 start
 to advertise the default route.

 adam
 -Original Message-
 From: cisco-nsp-boun...@puck.nether.net
 [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Tom Lanyon
 Sent: Thursday, September 27, 2012 4:58 AM
 To: David Prall; cisco-nsp
 Subject: Re: [c-nsp] Change BGP default-originate to IGP?

 Is there a specific order in which BGP updates are
 sent/exchanged/processed?

 The concern I have with tracking upstream routes is that the route tracked
 would need to be one of the last routes received (if not the last) to
 ensure
 that the router has full visibility.  This seems quite non-deterministic
 and
 so potentially fraught with 'weirdness'.

 Thanks,
 Tom

 On 27/09/2012, at 12:19 PM, David Prall wrote:
  Why not use selective advertisement of the default based on receiving
  a specific route from your carrier or an upstream you know to be stable.
 
  http://www.cisco.com/en/US/docs/ios/12_3/iproute/command/reference/ip2
  _n1g.h
  tml#wp1037042
 
  David


 ___
 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/

___
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] Change BGP default-originate to IGP?

2012-09-27 Thread David Prall
As well could put a GRE Tunnel or VLAN between the two ASR's and run iBGP
between the two. You control the path between the two routers, so the tunnel
can be over a jumbo frame capable path. I would still do a selective
advertisement for the default, so that traffic doesn't need to traverse the
both routers, but this would stop the blackholes for routes unlearned.
Especially if it is the upstream that is having issues, instead of the
direct connection.

David

--
http://dcp.dcptech.com


-Original Message-
From: Adam Vitkovsky [mailto:adam.vitkov...@swan.sk] 
Sent: Thursday, September 27, 2012 4:41 AM
To: 'Tom Lanyon'; 'David Prall'; 'cisco-nsp'
Subject: RE: [c-nsp] Change BGP default-originate to IGP?

So if I understood it correctly you are concerned that the router will start
to originate the default prior to receiving full BGP table from its upstream
right?
The simplest solution would be to place a static default route pointing to
the upstream -so in case of the above happens the router wouldn't blackhole
till it gets the full feed. 
Or you can base the condition of default advertisement on several prefixes
from all around the place instead of just one -but trying to match e.g. 10
prefixes from 400k well...
The problem with this though is that on IOS you can't AND the match ip
address statements under the route-map only OR -applies to all the match
statements of the same kind. 
So you could use static routes for the list of desired prefixes each with a
high AD -redistribute them into bgp with specific community and match for
the prefixes+community in non-exist map. 
So once you'll get all the prefixes from BGP -only after all cease to exist
in the bgp table with the specific community of yours -the router will start
to advertise the default route. 

adam
-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Tom Lanyon
Sent: Thursday, September 27, 2012 4:58 AM
To: David Prall; cisco-nsp
Subject: Re: [c-nsp] Change BGP default-originate to IGP?

Is there a specific order in which BGP updates are sent/exchanged/processed?

The concern I have with tracking upstream routes is that the route tracked
would need to be one of the last routes received (if not the last) to ensure
that the router has full visibility.  This seems quite non-deterministic and
so potentially fraught with 'weirdness'.

Thanks,
Tom

On 27/09/2012, at 12:19 PM, David Prall wrote:
 Why not use selective advertisement of the default based on receiving 
 a specific route from your carrier or an upstream you know to be stable.
 
 http://www.cisco.com/en/US/docs/ios/12_3/iproute/command/reference/ip2
 _n1g.h
 tml#wp1037042
 
 David


___
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] Change BGP default-originate to IGP?

2012-09-27 Thread Christian Meutes
The best way is here really to inject the defaults via ISIS.

On 27.09.2012, at 04:04, Tom Lanyon tom+c-...@oneshoeco.com wrote:

 Hi list,
 
 In an enterprise network I have a core of 4900Ms with a few ASR1ks hanging 
 off to handle upstream connectivity.  As an example:
 
 Upstream1 - [ASR1k]--[4900M]--[4900M]--[ASR1k] - Upstream2
||
||
ServersWorkstations, etc
 
 
 The ASRs and 4900Ms are running BGP and ISIS with full tables on the ASRs and 
 mostly just defaults on the 4900Ms.  The ASRs are originating defaults via 
 BGP but on reload they are blackholing traffic whilst BGP converges.
 
 I've seen that OSPF and ISIS have 'wait-for-bgp' overload bits available and 
 have been questioning whether switching to an IGP-generated default with 
 wait-for-bpg is the correct solution here.  Any thoughts?
 
 Thanks,
 Tom
 
 
 ___
 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] Change BGP default-originate to IGP?

2012-09-27 Thread Tom Lanyon
On 28/09/2012, at 4:03 AM, Christian Meutes wrote:
 The best way is here really to inject the defaults via ISIS.

Great - that's my current thinking too.  I just wanted to double-check that 
this was reasonable and I wasn't missing something!

Tom


___
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] Change BGP default-originate to IGP?

2012-09-26 Thread Tom Lanyon
Hi list,

In an enterprise network I have a core of 4900Ms with a few ASR1ks hanging off 
to handle upstream connectivity.  As an example:

Upstream1 - [ASR1k]--[4900M]--[4900M]--[ASR1k] - Upstream2
||
||
ServersWorkstations, etc


The ASRs and 4900Ms are running BGP and ISIS with full tables on the ASRs and 
mostly just defaults on the 4900Ms.  The ASRs are originating defaults via BGP 
but on reload they are blackholing traffic whilst BGP converges.

I've seen that OSPF and ISIS have 'wait-for-bgp' overload bits available and 
have been questioning whether switching to an IGP-generated default with 
wait-for-bpg is the correct solution here.  Any thoughts?

Thanks,
Tom


___
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] Change BGP default-originate to IGP?

2012-09-26 Thread David Prall
Why not use selective advertisement of the default based on receiving a
specific route from your carrier or an upstream you know to be stable. 

http://www.cisco.com/en/US/docs/ios/12_3/iproute/command/reference/ip2_n1g.h
tml#wp1037042

David

--
http://dcp.dcptech.com

-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Tom Lanyon
Sent: Wednesday, September 26, 2012 10:04 PM
To: cisco-nsp
Subject: [c-nsp] Change BGP default-originate to IGP?

Hi list,

In an enterprise network I have a core of 4900Ms with a few ASR1ks hanging
off to handle upstream connectivity.  As an example:

Upstream1 - [ASR1k]--[4900M]--[4900M]--[ASR1k] - Upstream2
||
||
ServersWorkstations, etc


The ASRs and 4900Ms are running BGP and ISIS with full tables on the ASRs
and mostly just defaults on the 4900Ms.  The ASRs are originating defaults
via BGP but on reload they are blackholing traffic whilst BGP converges.

I've seen that OSPF and ISIS have 'wait-for-bgp' overload bits available and
have been questioning whether switching to an IGP-generated default with
wait-for-bpg is the correct solution here.  Any thoughts?

Thanks,
Tom


___
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] Change BGP default-originate to IGP?

2012-09-26 Thread Tom Lanyon
Is there a specific order in which BGP updates are sent/exchanged/processed?

The concern I have with tracking upstream routes is that the route tracked 
would need to be one of the last routes received (if not the last) to ensure 
that the router has full visibility.  This seems quite non-deterministic and so 
potentially fraught with 'weirdness'.

Thanks,
Tom

On 27/09/2012, at 12:19 PM, David Prall wrote:
 Why not use selective advertisement of the default based on receiving a
 specific route from your carrier or an upstream you know to be stable. 
 
 http://www.cisco.com/en/US/docs/ios/12_3/iproute/command/reference/ip2_n1g.h
 tml#wp1037042
 
 David


___
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/