The first example we'll work with is
using the full BGP table from both
upstream providers let's have a look at
the diagram.
We're on AS100 and we want to
multi-home between the two AS130 and AS140
and we want to receive routes from
both app streams and try and balance I plan traffic.
So if we send our aggregate
towards AS130, then AS130's customers
will see that aggregate. So traffic from
AS130's customers to AS100 will follow
the green arrow into AS100 so if incoming
traffic goes that way we would want
outgoing traffic to follow the return
path we don't really wanted to go router D
through AS140 through the whole
world wide internet through the transit
provider of a s 130 back to s 1 thirties
customers that's a long way around
what we want is returned traffic from a
s 102 customer five to go back through
the direct link to a s 130 for this we
need to get routing information about s
130 and its customers from a s 130 so
let's look at the router C configuration
we've asked a s 130 to send us the Fuu
BGP table now the full BGP table doesn't
mean accept any old thing coming from
the upstream we should actually filter
what we hear from them to allow all
prefixes apart from special use and
basically the non-routable prefixes the
example shows ipv4 there's a similar set
for an ipv6 full route BGP session
outbound we only send our aggregate
example also shows a write map called a
s130 load share that's not built into
the router that's actually something we
have to configure
and we show a potential example for a
s130 on this slide the s130 load share
roadmap looks for prefixes matching a s
path list 10 an es pathless 10 basically
has two entries the first one's saying
anything originated by a s 130 and
that's a s 130 with pre pens of 130 or
any prefix originated by 130 and 130
immediate neighbors so say customer 5 is
using BGP there a s would match the
second line of that access list 10 and
this also would match prefix originated
by a s 130 strands the provider so we've
matched prefixes and what we're going to
do is set local preference to 120 the
prefixes do not match this s path then
we move on to the second line and the
second line says any prefixes we learn
from a s 130 should be set local
preference 80 so we're making this path
unimportant so in summary prefixes
originated by a s 130 and a s 130 is
immediate neighboring guesses will be
set with local preference 120 and
everything else will be set local
preference 80 so this is saying traffic
to a s 130 and its immediate neighbor
should go out through router see
everything else will go out through
router D let's look at write a DS
configuration again we're getting the
full BGP table from s 140 upstream and
we're filtering what's coming in to make
sure that RFC 6890 prefixes and their
friends are not permitted into the
network that's the special use prefix list.
Outbound we send just our aggregate.
So the summary of all this is router si
will accept full rights from one-thirty
tag prefixes originated by 131 30s
neighboring guesses with local
preference 120 traffic to those guesses
will go over the 130 link the remaining
prefix is a tag with local preference 80
and traffic to all other guesses will go
over the link to a s 140 the router D
configuration is the same as that for
router C but without the right map
setting the preferences which means all
prefixes coming in from router D will
stay with the local preference default
value of 100 so let's summarize this in
a table because this table will be
useful when we look at the next example
looking at partial rights at the time of
recording the Fuu BGP table was about
650,000 prefixes and so 650,000 prefixes
coming from a s 140 tagged with local
preference 100's 130 well let's say we
had 30,000 prefixes coming from 130 and
130
in mediate neighbors and we've tagged
those with local preference 120 the
remaining 620,000 will be tagged with
local preference 80 with a grand total
of 1.3 million paths as received by the
two routers so four routes from both up
streams is actually quite expensive it
needs lots of memory and CPU we need to
set local preferences at least on the
peering with one upstream and we need to
work out which prefixes we want to set
local preference on and this is only an
example real life will need improved
fine tuning it very much depends on the
connectivity between the up streams
their customers who their transit
providers are and the rest of the
Internet
and of course the previous example
doesn't consider inbound traffic but
we've covered that in earlier examples.
© Produced by Philip Smith and the Network Startup Resource Center, through the University of Oregon.
Attribution-NonCommercial 4.0 International (CC BY-NC 4.0)
This is a human-readable summary of (and not a substitute for) the license. Disclaimer. You are free to: Share — copy and redistribute the material in any medium or format Adapt — remix, transform, and build upon the material The licensor cannot revoke these freedoms as long as you follow the license terms. Under the following terms: Attribution — You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use. NonCommercial — You may not use the material for commercial purposes. No additional restrictions — You may not apply legal terms or technological measures that legally restrict others from doing anything the license permits.