Hello everyone I have some fundamental questions about backbone design. Feel free to point me to any discussions/presentation material related to these questions. 1. As I understand it's (sort off) common practice to give highest localpref to customer routes then peering and finally transit. Does this works well or you see issues with people who have 10+ prepends on some peering routes calling you to not send traffic via those circuits? Does it makes sense to put a rule to avoid routes 2-3 AS path away when changing local preference? 2. If I have more peering capacity and relatively less capacity between my own PoPs and I start injecting routes in my IGP then how to prevent change of choking of backbone? Is it standard practice to have more capacity on backbone then peering links? Or I have to inject less routes in IGP - say a few % of total routes? 3. How can I maintain use of routes I am learning from various other networks (transit+peers+customer) across my IGP? Is BGP community tagging good way out? 4. How is iBGP Vs OSPF for IGP? I keep on hearing that OSPF is good & lot more faster in changing routes during a breakdown as compared to slow hold time based iBGP session. Is there's more clear comparison of limitations of both when designing? Appreciate your time & help. Thanks. -- Anurag Bhatia anuragbhatia.com Linkedin <http://in.linkedin.com/in/anuragbhatia21> | Twitter<https://twitter.com/anurag_bhatia> Skype: anuragbhatia.com
Le 18/10/2013 20:03, Anurag Bhatia a écrit :
Hello everyone
I have some fundamental questions about backbone design. Feel free to point me to any discussions/presentation material related to these questions.
1. As I understand it's (sort off) common practice to give highest localpref to customer routes then peering and finally transit. Does this works well or you see issues with people who have 10+ prepends on some peering routes calling you to not send traffic via those circuits? Does it makes sense to put a rule to avoid routes 2-3 AS path away when changing local preference?
Most often, the (``traditionally'' business driven) classification that you mention is honored and subtler differences considered (only) in cases where LOCAL_PREFerence is the same for some candidate routes to a destination. There's no ``protocol law'' ruling this, it's all your choice, that you may base on cost, performance, or any other type of metrics that you feel relevant... For example, you may want -- as you say -- honor the hints from neighbors (even transitively) to route over ``less prepended paths'' (if available) to their networks. But it's up to you, and I'd suggest keeping a focus on performance, path stability, neighbours reactivity in case of failure, or some such (if you can afford it) as a metric. Else...
2. If I have more peering capacity and relatively less capacity between my own PoPs and I start injecting routes in my IGP then how to prevent change of choking of backbone? Is it standard practice to have more capacity on backbone then peering links? Or I have to inject less routes in IGP - say a few % of total routes?
What routes do you inject into your IGP? Generally, it's nice to keep IGP being merely a logical view of your graph of links, and keep foreign/other routes in (i)BGP. Then, you need to take a look at the distribution of your peering sessions over your sites with respect to your customer sessions. Etc, etc,... Backbone capacity versus peering capacity, depends on your mix of peers, customers, providers...
3. How can I maintain use of routes I am learning from various other networks (transit+peers+customer) across my IGP? Is BGP community tagging good way out?
See above, if I understand your question correctly.
4. How is iBGP Vs OSPF for IGP? I keep on hearing that OSPF is good & lot more faster in changing routes during a breakdown as compared to slow hold time based iBGP session. Is there's more clear comparison of limitations of both when designing?
Get in touch off-list, if you feel like? Cheers, mh
Appreciate your time & help.
Thanks.
On 2013-10-18 20:03, Anurag Bhatia wrote:
1. As I understand it's (sort off) common practice to give highest localpref to customer routes then peering and finally transit. Does this works well or you see issues with people who have 10+ prepends on some peering routes calling you to not send traffic via those circuits? Does it makes sense to put a rule to avoid routes 2-3 AS path away when changing local preference?
Hi, You may try a different trick on peering routes. You rather don't peer with the tier 1 networks, so you may filter out (or assign a low localpref to) all prefixes received from peering partners which contain in as-path some well known asn's, like let's say 174, 1299, 3356 and so on. Such routes are most likely leaked and traffic via those paths will be either blackholed or, in the best case, going via not really optimal path.
2. If I have more peering capacity and relatively less capacity between my own PoPs and I start injecting routes in my IGP then how to prevent change of choking of backbone? Is it standard practice to have more capacity on backbone then peering links? Or I have to inject less routes in IGP - say a few % of total routes?
You may always prefer peering routes local to the PoP (giving them the highest localpref). This way you will not carry so much traffic on your backbone. -- Grzegorz Janoszka
On Oct 18, 2013, at 1:15 PM, Grzegorz Janoszka <Grzegorz@Janoszka.pl> wrote:
You may always prefer peering routes local to the PoP (giving them the highest localpref). This way you will not carry so much traffic on your backbone.
Just imagine what paths would look like if everyone followed that advice. Yuck. I'd say that approach makes sense for cash and bandwidth strapped providers, but its not necessarily looking out for the best interests of your customers.
On Fri, 18 Oct 2013 23:33:16 +0530, Anurag Bhatia said:
localpref to customer routes then peering and finally transit. Does this works well or you see issues with people who have 10+ prepends on some peering routes calling you to not send traffic via those circuits?
OK. I admit being perplexed. Under what conditions will somebody have that many prepends and you *still* end up routing via that path if you have another path available? I guess if they were silly and prepended themselves 10 times and then announced the result to the upstreams of *both* paths you have available...
On Fri, Oct 18, 2013 at 2:46 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Fri, 18 Oct 2013 23:33:16 +0530, Anurag Bhatia said:
localpref to customer routes then peering and finally transit. Does this works well or you see issues with people who have 10+ prepends on some peering routes calling you to not send traffic via those circuits?
OK. I admit being perplexed. Under what conditions will somebody have that many prepends and you *still* end up routing via that path if you have another path available?
I guess if they were silly and prepended themselves 10 times and then announced the result to the upstreams of *both* paths you have available...
Uh...this actually happens a fair amount, to the point that I have a standard "less-than-X-AS-PATH" restriction in my localpref adjustments to explicitly prevent it. Think about it; if network A prepends 10x to network B, and not at all to network C; but network B is a free peer of mine, and network C is a transit network I pay money to; following the typical convention of "routes learned from network B get localpref'd to 5000, routes learned from transit are localpref'd at 1000", you'd end up pushing the traffic along the 10x prepended pathway. If you're a network with low splay, it's less likely, as the more intervening networks there are in the mix, the less likely the long path is to propagate to you; but if you're a high-splay network, there's a really good chance you're going to see both the long path and the short path across different categories of links, with different localpref assignments. A good approach to preventing that is to look at a histogram of AS-PATH lengths in your network, and establish a cutoff point, generally around your 95th percentile; path lenths less than that are "real" paths, above that are "backup, non-preferred" paths, and then use that cutoff in your policy arsenal: replace: as-path 1-OR-LESS ".{0,1}"; replace: as-path 2-OR-LESS ".{0,2}"; replace: as-path 3-OR-LESS ".{0,3}"; replace: as-path 4-OR-LESS ".{0,4}"; replace: as-path 5-OR-LESS ".{0,5}"; replace: as-path 6-OR-LESS ".{0,6}"; replace: as-path 7-OR-LESS ".{0,7}"; replace: as-path 8-OR-LESS ".{0,8}"; replace: as-path 200-OR-MORE ".{200,}"; replace: policy-statement SET-FREE-PEER { term AS-DEPTH-5-OR-LESS { from as-path 5-OR-LESS; then { community add C-Y-FREE-PEER; local-preference 2600; accept; } } term AS-DEPTH-LONGER-THAN-5 { then { community add C-Y-FREE-PEER; local-preference 100; accept; } } /* we will never get here, but put for readability/futureproofing */ then reject; } (pre-defining a range of potential AS-PATH lengths in your policy description tree makes it easier to adjust up or down, as your splay factor increases or decreases over time.) And no, you can't quite paste this exactly into your router directly, but it should give you an idea of how you might control the impact long AS-PATHs have on your routing tables. Matt
On Sat, 19 Oct 2013 12:43:49 -0700, Matthew Petach said:
Think about it; if network A prepends 10x to network B, and not at all to network C; but network B is a free peer of mine, and network C is a transit network I pay money to; following the typical convention of "routes learned from network B get localpref'd to 5000, routes learned from transit are localpref'd at 1000", you'd end up pushing the traffic along the 10x prepended pathway.
Thanks. Due to the way our private peering works, the only routes we learn from our "network B"'s are ones that wouldn't prepend because they want to talk to us over the peer. So all our prepends show up via our C's. And I was insuffiently caffienated to consider the case that we'd see prepends on our B side...
Hi Matthew Very cool! That is exactly I was looking for. I was uncomfortable in using 10+ prepend routes while ofcourse interested in tweaking localpref as everyone done based on peers & their status (transit/downstream/peering) etc. Thanks. On Sun, Oct 20, 2013 at 1:13 AM, Matthew Petach <mpetach@netflight.com>wrote:
On Fri, Oct 18, 2013 at 2:46 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Fri, 18 Oct 2013 23:33:16 +0530, Anurag Bhatia said:
localpref to customer routes then peering and finally transit. Does this works well or you see issues with people who have 10+ prepends on some peering routes calling you to not send traffic via those circuits?
OK. I admit being perplexed. Under what conditions will somebody have that many prepends and you *still* end up routing via that path if you have another path available?
I guess if they were silly and prepended themselves 10 times and then announced the result to the upstreams of *both* paths you have available...
Uh...this actually happens a fair amount, to the point that I have a standard "less-than-X-AS-PATH" restriction in my localpref adjustments to explicitly prevent it.
Think about it; if network A prepends 10x to network B, and not at all to network C; but network B is a free peer of mine, and network C is a transit network I pay money to; following the typical convention of "routes learned from network B get localpref'd to 5000, routes learned from transit are localpref'd at 1000", you'd end up pushing the traffic along the 10x prepended pathway.
If you're a network with low splay, it's less likely, as the more intervening networks there are in the mix, the less likely the long path is to propagate to you; but if you're a high-splay network, there's a really good chance you're going to see both the long path and the short path across different categories of links, with different localpref assignments.
A good approach to preventing that is to look at a histogram of AS-PATH lengths in your network, and establish a cutoff point, generally around your 95th percentile; path lenths less than that are "real" paths, above that are "backup, non-preferred" paths, and then use that cutoff in your policy arsenal:
replace: as-path 1-OR-LESS ".{0,1}"; replace: as-path 2-OR-LESS ".{0,2}"; replace: as-path 3-OR-LESS ".{0,3}"; replace: as-path 4-OR-LESS ".{0,4}"; replace: as-path 5-OR-LESS ".{0,5}"; replace: as-path 6-OR-LESS ".{0,6}"; replace: as-path 7-OR-LESS ".{0,7}"; replace: as-path 8-OR-LESS ".{0,8}"; replace: as-path 200-OR-MORE ".{200,}";
replace: policy-statement SET-FREE-PEER { term AS-DEPTH-5-OR-LESS { from as-path 5-OR-LESS; then { community add C-Y-FREE-PEER; local-preference 2600; accept; } } term AS-DEPTH-LONGER-THAN-5 { then { community add C-Y-FREE-PEER; local-preference 100; accept; } } /* we will never get here, but put for readability/futureproofing */ then reject; }
(pre-defining a range of potential AS-PATH lengths in your policy description tree makes it easier to adjust up or down, as your splay factor increases or decreases over time.)
And no, you can't quite paste this exactly into your router directly, but it should give you an idea of how you might control the impact long AS-PATHs have on your routing tables.
Matt
-- Anurag Bhatia anuragbhatia.com Linkedin <http://in.linkedin.com/in/anuragbhatia21> | Twitter<https://twitter.com/anurag_bhatia> Skype: anuragbhatia.com
Hi Valdis Checkout routing table at NIXI and you will get idea what I am referring to w.r.t. prepended routes. http://www.nixi.in/lookingglass.php Thanks! On Sat, Oct 19, 2013 at 3:16 AM, <Valdis.Kletnieks@vt.edu> wrote:
On Fri, 18 Oct 2013 23:33:16 +0530, Anurag Bhatia said:
localpref to customer routes then peering and finally transit. Does this works well or you see issues with people who have 10+ prepends on some peering routes calling you to not send traffic via those circuits?
OK. I admit being perplexed. Under what conditions will somebody have that many prepends and you *still* end up routing via that path if you have another path available?
I guess if they were silly and prepended themselves 10 times and then announced the result to the upstreams of *both* paths you have available...
-- Anurag Bhatia anuragbhatia.com Linkedin <http://in.linkedin.com/in/anuragbhatia21> | Twitter<https://twitter.com/anurag_bhatia> Skype: anuragbhatia.com
participants (6)
-
Anurag Bhatia -
Dan Rohan -
Grzegorz Janoszka -
Matthew Petach -
Michael Hallgren -
Valdis.Kletnieks＠vt.edu