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 <[email protected]>wrote: > On Fri, Oct 18, 2013 at 2:46 PM, <[email protected]> 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
