Fundamental questions of backbone design

Mailman List Mirror (Read Only)
1

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.

2

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

3

    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.

4

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.

5

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...

6

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

7

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...

8

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!

9

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.