The next example we're going to look at
is the case where we have a customer or
endsite
multi-homed between two ISPs who are
members of an internet exchange point.
this is quite a common situation
where the end user network is
multi-homed
for redundancy purposes or for load
balancing purposes
the diagram shows the situation
and we have to look and see what the
traffic engineering considerations
are required for this particular setup
the issues we need to address include
transit
in other words which path does incoming
transit traffic take
to the end side which path does outgoing
transit traffic
take from the n site we also need to
consider the peering situation
how does peering traffic from other
exchange part members get to the end
site
and what about traffic from the n side
to other ixp members
each isp will consider the end site to
be their customer
and would like to have their customers
traffic transit
their link to the customer
let's look at the route announcements
first
as100 would announce its address block
to both
upstreams s120 and as130 will both tag
high local preference on the
announcement they receive from as100
and therefore traffic from es120 and
130 respectively will go over their
respective direct links
es120 and es130 will announce es100s
address block
onwards to their upstreams and to the
rest of the internet
and the global internet will choose the
path to as100 according to
best path rules
s120 and as130 will also announce es100s
routes
to the exchange points right server and
to the ixp members they peer with
and we'll follow the peering priorities
discussed earlier
es120 will hear 100's writes from the
direct connection
and set local preference 250.
es120 will hear as100's routes across
the exchange point
and set local preference 170.
if you remember from the earlier we set
higher priority for direct bgp customer
routes
over the same routes heard from across
an exchange point
or the transit link and es130 will do
exactly the same thing
in steady state traffic from as120 or
as130
to their customer will traverse the
direct transit
link the diagram shows how this will
work
the green arrow shows incoming traffic
from the global internet
either going through as120 upstream
or as130 upstream to get to as100
an outgoing traffic will use either or
both of the upstream links through
as120 or as130 to the global internet
what about if we now look at a failure
mode
what happens if the link from as120 to
as100
breaks it could be shut down it could be
a physical failure
or there could be some issue with the
border router in as100
the diagram shows the link being broken
s120 will still see a path to as100
but this path will now be across the
exchange point
to airs 130 and then using es130s link
to the customer as100 which means that
traffic from as120 to as100
crosses the exchange point and as130
traffic from as100 will go to as120 via
as130
and the exchange point
if we look at the whole traffic flow
including traffic from the global
internet
we will see that traffic to the internet
will exit via
as130 upstream link it will go from
as100 to as130
and straight out the link to the global
internet
traffic from the internet though will
enter via as120
and as130 but the latter path will
likely be higher volume due to the
shorter airs path length visible on the
global internet
traffic 2 as120 crosses the ixp
via as130 and traffic from as120 will
cross the ixp
via as130 the diagram
shows the traffic flow with the
color-coded arrows
we have some of the observations about
this failure mode if as130 implements
packet filtering by source address on
the peering link
then this will seriously affect the
connectivity experienced by as100
incoming traffic from the internet via
as120
and the exchange point will be dropped
multi-home customers of ixp members will
result in this unusual traffic flow we
saw earlier
and this is a side effect of the
customer having redundant connections to
the upstream providers
and there's nothing wrong with it and
it's one reason why it is very important
for a network operator to set higher
local preference on routes heard
directly from a bgp customer versus the
same rights heard via peering or transit
links
failure to set the local preference
properly could result
in peer or transit traffic going over
the exchange point
rather than over the direct links
customer traffic engineering could also
cause transit traffic
during the failure case to transit as120
across the ixp
and then via as130 to the customer
for example the customer could have
asked as130
to announce its address space to the
global internet with a large preprint
as shown in the diagram the global
internet will then see best path
to as130 via as120
across the exchange point across es130
and down to as100
outbound traffic would still go directly
s100 to as130
out to the global internet
this would have seemed a little bit
unusual from the internet point of view
but again as a perfectly normal
situation
given the failure mode that we're
currently sitting in
another situation that could happen is
if as120
tags routes it hears from its exchange
point peers
with the no export community
as we've learned elsewhere in the series
the bgp no export community means
do not advertise this prefix to ebgp
peers
so when the link to its as100 customer
fails as100's prefix will be withdrawn
from the bgp announcements made by as120
to the internet
during steady state the best path to
as100 is on the direct link
but when the direct link fails the bgp
announcement disappears
and the only remaining path is via the
exchange point
but this prefix will be tagged no export
and means it will be withdrawn from bgp
announcements made by
as120 to the internet so the diagram
shows
the resulting traffic flow incoming
traffic from the global internet
will come in via as130 upstream link
outgoing traffic will go out through
as130's upstream link
so this is a common scenario for when a
customer is multi-homed onto members of
an exchange
point steady-state traffic flow works as
expected
and if either customer transit link
fails then it's quite likely that
incoming transit traffic will cross the
exchange point
it's not unusual nor is it a problem
if you want to avoid having transit
traffic crossing the ixp
then tag the routes heard from the ixp
peers with no export
direct customer routes will only be
announced to transits
when the direct link to the customer is
active
as soon as the direct link to the
customer fails the only bgp paths heard
will be across the exchange point
they'll be tagged with no-export and
therefore no longer announced to the
global internet.
© 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.