So this section is going to look at how
we go about configuring policy within
BGP for the multihoming examples that we
will be discussing going forwards.
There are several examples, several different
scenarios, and we're going to look at the
policy language we use in Cisco IOS to
demonstrate how these examples are implemented.
And assumptions are these:
we're going to use prefix lists
throughout filtering prefixes and we're
going to use Cisco's filter lists for
filtering announcements based on the AS
numbers. Cisco IOS route maps are going
to be used to apply policy and we're
going to try as much as we can not to
stray from those three basic principles.
We can use route maps for filtering
prefixes and for filtering based on AS
numbers as well but I consider this a
little bit more advanced configuration
and will only really touch on those
features much later on in this series.
For now we're going to keep things as
simple as possible to make the
multihoming examples as understandable
for our viewers. The policy tools we have
are actually quite straightforward
they're not many. We've got local
preference to look at item and traffic flows.
We've got MED which most of us
still call "metric" for inbound traffic flows.
And this is for local scope, in
other words, between two adjacent
autonomous systems. We've got the AS path
prepend which again is for influencing
inbound traffic flows but as for
internet scope you do an AS path prepend
in your autonomous system, it will be
visible over most of the internet.
We also will subdivide our aggregates the
address space that we have is announced
to the Internet as an aggregate and one
of the strong traffic engineering tools
is to subdivide the aggregate.
So we'll look at how
to do that to influence inbound traffic
flows as well. And finally we'll look at
using BGP communities. BGP communities
are extremely useful for specific
inter-provider peering, both for
influencing inbound and outbound traffic flows.
When we originate prefixes we
make a few assumptions.
The first assumption is that we announce
our address block to the Internet.
In fact the regional registries and many of the
Internet service providers and long-time
internet experts always recommend that
we always announce our assigned address
block to the internet on every single
external peering. There are some
operators today who do not do this and
this causes a lot of challenges with
doing proper traffic engineering and
providing good redundancy for
connectivity in the internet. So all
these examples will always announce
the address block out every external
link. We can also announce sub prefixes
and this is the traffic engineering part
the reachability of these sub prefixes
is not guaranteed, however. minimal
allocations for ipv4 today is a slash 24
for v6 is a slash 48 for an end site and
a slash 32 for a network operator.
Several network operators will filter
the registry blocks based on the
registries published minimum allocation
boundaries. Several ISPs will filter the
rest of address space according to the
IANA assignments. Some people call this
activity "net police". There isn't really
any "net police" but the activity of
operators filtering announcement seen on
internet today is considered by many
people as good operational practice and
by other people as a kind of irritation
to them trying to operate their network
infrastructure. And I want to look at the
net police prefix list issues. Now this
is intended to punish ISPs who pollute
the routing table with specifics rather
than announcing aggregates. As I said
earlier there's no such thing as a net
police. Nobody runs the internet. Nobody
controls the internet. Nobody's the
internet police force but operators are
conscious of the size of the routing
table in v4 and the growing size of the
routing table in v6 and the impact that
that has on the network infrastructure
and operations. So some of this prefix
filtering, well-intentioned in the core
of the Internet, actually can harm
legitimate multihoming at the internet's
edge and it can impact regions where the
cost of domestic backbone is prohibitive
or even if the domestic backbone is
unavailable. The net police filters are
also quite hard to maintain and it does
require updating when the registries start
allocating from new address blocks.
Especially in the last decade or so of
ipv4 runouts with the registries
allocating from address space from new
IANA /8 address blocks. It has caught
quite a few network operators out as they
receive blocks from these new /8s.
The registries amongst others did their
part to ensure that these new
assignments were actually routable
but it was still causing issues as the
internet grew.
So it really would be my recommendation
not to do over aggressive
filtering unless the consequences are understood
and that you as the network operator
actually are prepared to keep the list current.
There been many many cases
over the last 15 20 years of operators
putting in filters and then forgetting
about them. And as with staff turnover
and so forth, new staff coming in not
understanding why parts of Internet
ceased being reachable. Purely caused by
legacy filters that people either
didn't understand or were too afraid to
touch. In fact Team Cymru has come to
the assistance of many network operators
by offering what's called a bogon BGP feed
where they will provide a BGP feed
to the network operator containing all
the prefixes v4 and v6 which should not
be announced or usable on the public internet.
And network operators have used
this bogon BGP feed to ensure that
they only have legitimate prefixes
within the BGP table.
Registries publish the minimum allocation sizes
per v4 /8 block and per their v6 allocations.
And you can find the latest information on
each of the five regional registries
websites. Do also note many operators
will filter legacy v4 address space
based on the legacy sizes: the legacy
Class A, Class B and even Class C sizes.
So subdividing some of the legacy
address space smaller than those legacy
sizes may cause reachability issues as
well. Therefore it's really important to
make sure that you as the network
operator always announce your assigned
or allocated address block on all
external links.
© 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.