Re: Fundamental questions of backbone design

[Matthew Petach <mpetach () netflight com>]

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