networking-forum.com
Community BlogCommunity Wiki * Register  * Search  * Login
View unanswered postsView active topics

All times are UTC - 6 hours [ DST ]



Post new topic Reply to topic  [ 16 posts ] 
Author Message
 Post subject: Enterprise BGP Lab
PostPosted: Thu Apr 29, 2010 1:18 pm 
Offline
Site Admin
Site Admin
User avatar

Joined: Mon Dec 06, 2004 6:46 pm
Posts: 10364
Location: McKinney, TX
Certs: CCNA
Comments for Enterprise BGP Lab.

_________________
Find networking-forum.com on Facebook, LinkedIn, Twitter, Google+,or subscribe to the site's RSS feeds.


Top
 Profile  
 
 Post subject: Re: Enterprise BGP Lab
PostPosted: Fri Apr 30, 2010 8:49 am 
Online
Post Whore
Post Whore
User avatar

Joined: Mon Jun 15, 2009 9:48 am
Posts: 2967
Location: Lynchburg VA
Certs: CC\NP\DP\IP\NA-Security\NA-Voice
awsome post :-D

_________________
Freedom to all the people. Brave, true and strong.
Freedom to all the people. Unless I think you're wrong

dhimes.com


Top
 Profile  
 
 Post subject: Re: Enterprise BGP Lab
PostPosted: Fri Apr 30, 2010 9:48 am 
Offline
Site Admin
Site Admin
User avatar

Joined: Mon Dec 06, 2004 6:46 pm
Posts: 10364
Location: McKinney, TX
Certs: CCNA
I have a few questions/comments about your BGP implementation.

Why explicitly set local preference to 100 on route map ISP-2_IN? Is that for demonstration purposes only?

Why did you create network statements for the /31 transports?

It should be noted that in a real world implementation, prepending your outbound announcement to make a path backup will most likely not take your traffic down to 0 even if you prepend 10 times. The reason is that ISPs apply a different local preference to the routes they learn depending on the relationship you have with them. They set transits low, peers to the middle, and customers high. This ensures that traffic prefers to go over the customer's (revenue) rather than a peer's (contractual/relationship based) and then at a last resort a transit provider (expense). The way to overcome this is to ask the provider what BGP communities they have in place to adjust local preference on their network and then apply that community string to the announcements you send to them. On my backup circuits or while I'm doing maintenance, I set the local preference on my provider's network to the lowest setting which generally takes traffic to 0 or very near. The only data on the wire at that point is traffic destined to a route that the provider has the most specific match for and BGP updates.

_________________
Find networking-forum.com on Facebook, LinkedIn, Twitter, Google+,or subscribe to the site's RSS feeds.


Top
 Profile  
 
 Post subject: Re: Enterprise BGP Lab
PostPosted: Sun May 02, 2010 1:23 pm 
Offline
Member
Member

Joined: Fri Nov 13, 2009 4:42 pm
Posts: 199
Certs: CCIE R&S
Ya this was a great blog post. I re-labbed it myself at home last night, and had a pretty good time with it. Nice notes Steve. I assume you are talking about the communities that the provider should have listed in their aut-num object via route registry. It always good to know different ways to accomplish the same goal. Luckily for my own personal knowledge the orielly bgp book gave alot of "real world" implementation scenarios, and the author used a tone that reflected his personal opinions on the matter, and he shared information much like you just spoke of with his audience. With the dual-nat, is it necessary to use the match interface command in the route-maps? Just wondering, I had never seen it before myself. Thanks, and again, great post.


Top
 Profile  
 
 Post subject: Re: Enterprise BGP Lab
PostPosted: Sun May 02, 2010 1:38 pm 
Offline
Member
Member

Joined: Fri Nov 13, 2009 4:42 pm
Posts: 199
Certs: CCIE R&S
:oops:
nevermind...fired the lab back up and looked at that nat route-map...took out the match interface line and got this:

OBR(config-if)#
*Mar 1 13:53:19.843: NAT: translation failed (A), dropping packet s=192.168.20.1 d=1.1.1.1
*Mar 1 13:53:19.847: NAT: translation failed (A), dropping packet s=192.168.20.1 d=1.1.1.1
*Mar 1 13:53:21.847: NAT: translation failed (A), dropping packet s=192.168.20.1 d=1.1.1.1
*Mar 1 13:53:21.847: NAT: translation failed (A), dropping packet s=192.168.20.1 d=1.1.1.1
*Mar 1 13:53:23.847: NAT: translation failed (A), dropping packet s=192.168.20.1 d=1.1.1.1
*Mar 1 13:53:30.683: NAT: expiring 93.48.61.3 (192.168.20.1) icmp 0 (0)


Top
 Profile  
 
 Post subject: Re: Enterprise BGP Lab
PostPosted: Sun May 02, 2010 5:44 pm 
Offline
Moderator
Moderator
User avatar

Joined: Mon Apr 07, 2008 10:38 am
Posts: 9437
Location: Orlando, FL
Certs: CCNP RS, CCNP DC, CCDP, CCIP
Steve wrote:
I have a few questions/comments about your BGP implementation.

Why explicitly set local preference to 100 on route map ISP-2_IN? Is that for demonstration purposes only?

Why did you create network statements for the /31 transports?

It should be noted that in a real world implementation, prepending your outbound announcement to make a path backup will most likely not take your traffic down to 0 even if you prepend 10 times. The reason is that ISPs apply a different local preference to the routes they learn depending on the relationship you have with them. They set transits low, peers to the middle, and customers high. This ensures that traffic prefers to go over the customer's (revenue) rather than a peer's (contractual/relationship based) and then at a last resort a transit provider (expense). The way to overcome this is to ask the provider what BGP communities they have in place to adjust local preference on their network and then apply that community string to the announcements you send to them. On my backup circuits or while I'm doing maintenance, I set the local preference on my provider's network to the lowest setting which generally takes traffic to 0 or very near. The only data on the wire at that point is traffic destined to a route that the provider has the most specific match for and BGP updates.


Good to have some real world input as I'm going mostly off books and lab stuff here. I do very little with BGP at work, sadly.

I explicitly set the LP low on the ISP map in case it was mapped somewhere else already (if this wasn't a lab, lol). I don't really know why I put those network statements in for the /31s. I may have had a reason at the time (late at night, so who knows), but I can't think of a purpose.

_________________
http://blog.alwaysthenetwork.com


Top
 Profile  
 
 Post subject: Re: Enterprise BGP Lab
PostPosted: Mon May 03, 2010 10:51 am 
Offline
Site Admin
Site Admin
User avatar

Joined: Mon Dec 06, 2004 6:46 pm
Posts: 10364
Location: McKinney, TX
Certs: CCNA
I use this list though you should probably consult your provider's documentation or tech support before implementing any community changes, http://onesc.net/communities/.

_________________
Find networking-forum.com on Facebook, LinkedIn, Twitter, Google+,or subscribe to the site's RSS feeds.


Top
 Profile  
 
 Post subject: Re: Enterprise BGP Lab
PostPosted: Mon May 03, 2010 11:32 am 
Offline
Senior Member
Senior Member
User avatar

Joined: Mon Jul 06, 2009 7:23 am
Posts: 454
Location: Sheffield, UK
Certs: CCNA, CCNP, CCIP, JNCIA-JUNOS, JNCIS-ENT
Vito_Corleone wrote:
I explicitly set the LP low on the ISP map in case it was mapped somewhere else already (if this wasn't a lab, lol). I don't really know why I put those network statements in for the /31s. I may have had a reason at the time (late at night, so who knows), but I can't think of a purpose.


I think the mention of why set the LP to 100, was because BGP defaults to using a local preference of 100 anyway.

_________________
Router> show single women | inc without-drama
Router>

Working From My Shed, my networking blog
http://www.workingfrommyshed.co.uk


Top
 Profile  
 
 Post subject: Re: Enterprise BGP Lab
PostPosted: Mon May 03, 2010 11:50 am 
Offline
Moderator
Moderator
User avatar

Joined: Mon Apr 07, 2008 10:38 am
Posts: 9437
Location: Orlando, FL
Certs: CCNP RS, CCNP DC, CCDP, CCIP
stuh84 wrote:
Vito_Corleone wrote:
I explicitly set the LP low on the ISP map in case it was mapped somewhere else already (if this wasn't a lab, lol). I don't really know why I put those network statements in for the /31s. I may have had a reason at the time (late at night, so who knows), but I can't think of a purpose.


I think the mention of why set the LP to 100, was because BGP defaults to using a local preference of 100 anyway.


It does, but my reasoning is that it could have been remarked somewhere else. Obviously not likely, especially in this scenario, but I figure it could be good practice.

_________________
http://blog.alwaysthenetwork.com


Top
 Profile  
 
 Post subject: Re: Enterprise BGP Lab
PostPosted: Mon May 03, 2010 1:47 pm 
Offline
Post Whore
Post Whore
User avatar

Joined: Mon Jun 11, 2007 9:43 am
Posts: 1858
Location: Irondequiot, NY
Nicely written Blog post Vito!


Top
 Profile  
 
 Post subject: Re: Enterprise BGP Lab
PostPosted: Mon May 03, 2010 2:16 pm 
Offline
Moderator
Moderator
User avatar

Joined: Mon Apr 07, 2008 10:38 am
Posts: 9437
Location: Orlando, FL
Certs: CCNP RS, CCNP DC, CCDP, CCIP
Steve wrote:
It should be noted that in a real world implementation, prepending your outbound announcement to make a path backup will most likely not take your traffic down to 0 even if you prepend 10 times. The reason is that ISPs apply a different local preference to the routes they learn depending on the relationship you have with them. They set transits low, peers to the middle, and customers high. This ensures that traffic prefers to go over the customer's (revenue) rather than a peer's (contractual/relationship based) and then at a last resort a transit provider (expense). The way to overcome this is to ask the provider what BGP communities they have in place to adjust local preference on their network and then apply that community string to the announcements you send to them. On my backup circuits or while I'm doing maintenance, I set the local preference on my provider's network to the lowest setting which generally takes traffic to 0 or very near. The only data on the wire at that point is traffic destined to a route that the provider has the most specific match for and BGP updates.


Steve, for this BGP manipulation, you're talking about being dual homed to a single provider, or dual homed to two providers? After talking to Noah (networker4034094394 on here), it seems like prepending is really the only option when you're dual homed to multiple providers. Again, my real world BGP experience is very limited, but I love learning about the protocol and how stuff works in the real world.

_________________
http://blog.alwaysthenetwork.com


Top
 Profile  
 
 Post subject: Re: Enterprise BGP Lab
PostPosted: Mon May 03, 2010 2:33 pm 
Offline
Site Admin
Site Admin
User avatar

Joined: Mon Dec 06, 2004 6:46 pm
Posts: 10364
Location: McKinney, TX
Certs: CCNA
Vito_Corleone wrote:
Steve, for this BGP manipulation, you're talking about being dual homed to a single provider, or dual homed to two providers? After talking to Noah (networker4034094394 on here), it seems like prepending is really the only option when you're dual homed to multiple providers. Again, my real world BGP experience is very limited, but I love learning about the protocol and how stuff works in the real world.


Dual (or more) homed to multiple providers. Providers perform the default actions I described before with transit, peers, and customers. If they didn't then allow you a mechanism to override that default behavior, you'd be fucked. You'd be able to influence *most* traffic with prepending but not all. And the bigger your provider is, the less traffic you'd have control over with prepending. This is something I designed for the ISP I worked at for 4 years and now use as a customer for 2 years at my current gig.

Take a look at this doc (http://www.onesc.net/communities/as2828/):

Quote:
For our BGP customers, XO has implemented a powerful, flexible system whereby we allow our customers to control - via predefined communities - the XO treatment of their announcements. These communities control XO local-preference (local-pref) of customer-announced routes within our network.

The most powerful attribute is local-preference.

In BGP, the higher the local-pref, the more preferred the route on the network. This affects XO backbone route selection only, and not the route selection made by XO peers and customers, because localpreference is non-transitive. This means it does not get passed beyond the XO network. The customer has a range of six local-preferences to which they can set their routes.


What they won't put in writing is why they treat customer routes this way and the answer is because it's the difference between revenue and an expense.

_________________
Find networking-forum.com on Facebook, LinkedIn, Twitter, Google+,or subscribe to the site's RSS feeds.


Top
 Profile  
 
 Post subject: Re: Enterprise BGP Lab
PostPosted: Tue May 04, 2010 2:05 pm 
Offline
Member
Member

Joined: Fri Nov 13, 2009 4:42 pm
Posts: 199
Certs: CCIE R&S
Thanks for the link Steve. I've been looking for something like this!


Top
 Profile  
 
 Post subject: Re: Enterprise BGP Lab
PostPosted: Sun May 09, 2010 7:27 am 
Offline
New Member
New Member

Joined: Sat Apr 24, 2010 3:38 pm
Posts: 43
Certs: CCNP/CCIP/CCDP
prepending is about the only way, short of actually shutting down a peering session, to influence which link traffic comes over for AS's that you're not connected to. If you prepend your path 10 times and still get traffic over a link other than the one you wanted, there's pretty much nothing you can do about, as the other AS's obviously have policies that are designating that link as the one to get to you.

But I'm in agreement with Steve, most of the time dropping your local pref through your provider's communities will take care of any errant traffic, and if I have to take a circuit down, I'll drop my local pref with them as low as I can and make sure traffic is coming in over my other links.

I absolutely love nlayer's community setup. They give you so much granularity, and IMHO, is the gold standard that all providers should aspire to.


Top
 Profile  
 
 Post subject: Re: Enterprise BGP Lab
PostPosted: Thu Dec 09, 2010 5:46 am 
Offline
New Member
New Member

Joined: Thu Dec 09, 2010 5:42 am
Posts: 1
Certs: CCNP
hello Sir,

What if I am going to use a private IP for my DMZ. If that will be fine?

Hope to hear from you.

Thank you.


Top
 Profile  
 
 Post subject: Re: Enterprise BGP Lab
PostPosted: Thu Dec 09, 2010 5:57 am 
Offline
CCIE #38070
CCIE #38070
User avatar

Joined: Wed Jun 18, 2008 7:49 am
Posts: 12478
Location: London, UK
Certs: CCIE ,CC-NP/IP, JNCIP-SP, JNCIS-ENT, BC-/SPNE/NP
almazanse wrote:
hello Sir,

What if I am going to use a private IP for my DMZ. If that will be fine?

Hope to hear from you.

Thank you.


Make you own thread. This has nothing to do with this topic

_________________
www.mellowd.co.uk/ccie/


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 16 posts ] 

All times are UTC - 6 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group