nanog mailing list archives

Re: Fundamental questions of backbone design


From: Anurag Bhatia <me () anuragbhatia com>
Date: Thu, 24 Oct 2013 16:19:30 +0530

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


Current thread: