The previous examples dealt with load
sharing of inbound traffic and this is
of primary concern at the Internet edge.
But what about outbound traffic?
We've left it as nearest exit which is fine
for simple cases but quite often it's
not sufficient for many network
operators. Transit ISPs strive to
balance traffic flows in both directions
to balance link utilization and indeed
try and keep most traffic flows
symmetric last thing a transit provider
wants is having traffic going all the
way around the globe out one direction
and coming back in the other and some
edge network operators will try and
balance link utilization and keep
traffic flow symmetric as well and this
has been known as traffic engineering
since the early days of the internet now
balancing outbound traffic requires
inbound routing information and the
common solution and a used solution in
quotes is really the fool routing table
so often in my career I have seen
upstream providers say sure we will help
you do your traffic engineering here you
need the full BGP table and it needs to
run on this router at a minimum which
has been very challenging for a lot of
network operators especially those in
the more emerging parts of the internet
in fact the full routing table is rarely
necessary why do we need to use such a
large hammer to solve what is a
relatively small problem in fact keep it
simple
is often easier and financially a lot
cheaper than carrying multiple copies of
the full routing table there are myths
out there
let's look at three of the most common
ones the first one is that you need to
fool
routing table to multi-home of course
folks who sell router memory would like
you to believe this and it's really only
true if you're a transit provider if
you're providing transit quite usually
you'll have end customers who wish to do
traffic engineering like the sort we're
talking about here and in fact the full
routing table could be a significant
hindrance to multihoming we spend more
time trying to juggle the large number
of prefixes we see in the v4 table an
increasing number of prefixes we see in
the v6 table then actually try to make
sure we can move packets the second myth
is that we need a big router to multi
home router size is all about data rates
not about running BGP if you saw what we
were running BGP on in the early
internet you'd wonder how any of them
tonight actually worked in reality to
multi-home your router needs to have two
interfaces one internal one external be
able to talk BGP to at least two peers
be able to handle the BGP attributes
we've been talking about and handle a
few prefixes in reality a router that is
used for multihoming can be quite a
simple and quite a small unsophisticated
device and the third myth my favorite
one is BG piece complex in the wrong
hands it might well be but actually
starting off with simple principles bgp
is actually quite simple to understand
and this part of this series is to try
and help you see that bgp is actually
simple to follow simple to configure and
construct so let's look at some of the
strategies we might use first off we
want to take the prefixes we need to aid
our traffic engineering and to do this
let's look at the traffic flow data for
example on Cisco it's called net flow
looking at the traffic flow for pop
pila sites will give the operator a very
good idea but the destinations that
end-users are using whether it's
uploading data it is a content provider
or downloading data if it's an end-user
browsing the familiar social media and
Internet videos also prefixes originated
by immediate neighbors and their
neighbors will do more to aid
load-balancing than prefixes from
autonomous systems which are many hops
away geographical closeness is much more
important than those destinations on the
other side of the planet
there are many autonomous systems
between you and those on the other side
of the planet and the interconnectivity
between those autonomous systems is
changing all the time whether by design
or by accident so concentrate on local
destinations and we're also going to use
default routing as much as possible if
the destination doesn't matter to us why
do we need to care the prefix for it
let's rely on our upstream provider if
we don't know how to get to it let our
upstream provider work out that for us
if we do want to use the full routing
table we can nothing wrong with that but
let's try and be a little bit careful
about juggling the large number of v4
prefixes we see today we're going to
look at some examples in the following
clips the examples include one upstream
and one local peer and upstream
connecting to local exchange point and
some of the detail around that and
finally two up streams and how we manage
the outbound traffic engineering in that
scenario we need to use BGP and we need
to use a public autonomous system number
and all the examples we're going to
assume that the local network has their
own address block,
in this case a /19 of v4 address space.
© 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.