Fundamental questions of backbone design

Anurag Bhatia me at anuragbhatia.com
Thu Oct 24 10:49:30 UTC 2013


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 at netflight.com>wrote:

> On Fri, Oct 18, 2013 at 2:46 PM, <Valdis.Kletnieks at 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



More information about the NANOG mailing list