So we're now going to look at how to
handle two links to different ISPs but
with load sharing. So look at a simple
example first and then follow it up with
something a little bit more complex so
again we have the a s 100 connecting to
the upstream say s 110 and a s 120 and
as before we're going to nine stay
aggregate block out to both up streams
because our aggregate is announced of
either link should fail we still have
back up through the other operator what
we're going to do now is take the 19 and
divide it into two pieces sound familiar
it's the same principle as we saw
earlier we're going to announce 1/20 on
the link to a s 110 and we're going to
name the second slash 20 on the link to
a s 120 should either link fail the
slash 19 through the other link provides
the backup but what it also means is all
traffic for the first slash 20 will come
in through s 110 and all the traffic for
the second slash 20 will come in through
a s 120 and yes even traffic from s 120
going to the first half of the dress
space will go all the way through the
internet and a s 110 to reach s 100 and
all traffic for the second slash 20 from
a s 110 will go all the way through the
internet through s 120 to get to es-100
so that's one of the side effects of
leaking sub prefixes they're more
specific than the covering aggregate and
traffic will always follow that over the
covering aggregate let's look at router
a configuration we're now originating
the slash 19 aggregate and 1/20 and so
the prefix list allows the aggregate and
the slash 20 outbound and there's
another prefix list allowing just the
default router him similar to what we
saw in the earlier
samples router B aggregate out plus ii
slash twenty as we've seen earlier so
this is actually a very basic load share
that assumes equal traffic across the
entire address space and the idea here
really is to show you the first steps in
designing a load sharing solution we
start with a simple concept and build on
it so now we're going to look at more
controlled Lords sharing the previous
one we simply took the 19 and divided
into two pieces it doesn't really give
you much control so what we're going to
do now is combine the previous two
techniques that we learned subdividing
address space and doing s path prepense
to give us a little bit more control for
our load balancer if you look at the
diagram s100 connects to 110 or 120 as
before we're going to announce a slash
19 I create out each link as before what
we're going to do now is apply some
traffic engineering to the link between
a s 100 and a s 120 and what we're going
to do is take the 19 and pull out 1/20
sub prefix and announce that slash 20 on
the link towards a s 120 again it means
all traffic for that sub P fix will come
in through here's 120 we're also going
to announce the slash 19 aggregate
towards the s 120 with a longer s path
so if you think about it we now have two
things we can adjust we can adjust the
size of the sub prefix we're announcing
2's 120 when you start with slash 20 and
see what we need to do and we can change
the length of the a s path of the slash
19 aggregate towards the s 120 again to
suit the level of traffic if we have a
lot of traffic for the first half of the
address space and not very much for the
second
we can modify the length of a s path
prepare to push more traffic towards the
s 110 link or push more traffic towards
the s 120 link so we have now two ways
of tuning the load balancing in this
example we still need redundancy of
course and that's what our aggregates do
and of course our upstream providers
still announce the default right if you
look at router a it's a simple
configuration the default is allowed in
the aggregate is allowed out router B is
where the traffic engineering happens we
let the default in but outbound not only
do we allow our aggregate out we also
let one subnet of the aggregate in this
case a slash 20 and we have the right
map AG prepend which looks very gate and
does the pre-plant so let's look at the
prefix lists and the right map first off
the prefix list s 120 out allows the
slash 19 aggregate out as well as one of
the slash 20s so all traffic for that
slash 20 will come in through s 120 the
traffic for the other slash 20 so the
other half of the entire aggregate will
be balanced between s 110 and s 120 and
we can change this balance by using the
AG prepend right map so if we look at
that it's looking for the prefix list
aggregate on the ID band announcing and
if it finds it it's doing a double
pre-plant say s 120 will see the
aggregate coming to it with three of es
100 in the path and you can change this
you can make it a single prepend if
you're not getting enough traffic or
thus too much traffic you can make it
three times pre-planned or four times
you shouldn't need to make more than
three or four prepends more than that
there's something else wrong with the
inter connectivity further out in the
internet which in a s path prepend is
simply not going to resolve
so this example is much more commonplace
and it shows how network operators and
end sites will subdivide address space
frugally as well as using the s path
prepend concept to optimize the load
chain between different ISPs and notice
were always announcing our aggregate as
we covered earlier it's vitally
important to ensure that the aggregate
is always alliance on all external links
so the previous examples dealt with a
simple case we're load balancing inbound
traffic flow and we achieve this by
modifying outbound writing announcements
the aggregate is always announced we've
not looked at outbound traffic flow for
now we're leaving this as nearest exit
which is sufficient for most n sites
connecting to either the same upstream
provider or two different upstream
providers the next part of this series
will look at how we balance I'd ban
traffic flow as that is a little bit
more work and a little bit more
challenging for network operators to
achieve to their satisfaction.
© 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.