So I'd now like to cover how IP address
plans will assist with planning multihoming.
An IP address planning is
actually a very important part of
multihoming especially for traffic
engineering. A lot of network operators
don't think about this or they leave the
management of their address space to a
customer sales organization or the
customer deployment organization.
When, in fact, the address block and the address
planning belongs firmly and squarely
with the network engineering and network
operations. Typical service provider
address plans are set up such that they
split the address space into four parts.
There will be address space for
end-users, the customers. There'll be
address space used to address the link
from the service provider backbone to
the end user, typically the
point-to-point link addresses.
There'll be address space used for the service
providers infrastructure, again typically
the point-to-point links that connect
the routers across the network.
And there will also be a small amount of
address space for the router loop backs.
And these four blocks make up the service provider address plan,
as you can see in the diagram below
where I have an example of a slash 21
that has been divided
between customer address space,
customer point-to-point links,
the infrastructure point-to-point links
and the loopback addresses.
Now service provider router loop backs
and backbone point-to-point
link addresses make up a small part of
the total address space. And routers do
not attract traffic. They're not browsing
the different content around the
Internet. They are simply moving packets.
Whereas customer address space attracts
traffic because the end users
are doing all the downloads and their uploads
and whatever other work
they're doing when connected
to the Internet.
The links from the ISP aggregation edge
to the customer router
needs a single slash 30 in IPv4
and a slash 64 in IPv6.
These are small requirements when
compared with the total address space.
Some service providers don't even use
addresses on these point-to-point links.
In Cisco IOS we use a feature called IP unnumbered or IPv6 unnumbered.
However, planning customer assignments is
a very important part of multihoming and
traffic engineering involves subdividing
the aggregate into pieces until the load
balancing works satisfactorily.
So we need to pay close attention
to the address space that's assigned
to the customers and to the address space,
if used, on the point-to-point link
between the service provider and the customer.
If the customer is using NAT,
then they will be NAT'ing
onto the point-to-point link address
from the service provider to them.
Now if we don't do any planning
with the IP address space
and we simply consider our address block
as a long tube
and just start filling up
the tube from the left hand side
as the diagram shows, the traffic engineering
is not really going to work here.
Imagine we have two links.
Up to now I've said Well.
Take the aggregate and answers on both
links
and then take the aggregate
and divide it into two.
Announce one piece on one link,
the other piece on the other link.
Well, if we just number the
customers sequentially from the left
then all the traffic will come into the
first half of the address space
and there will be nothing at all for the
second half.
So we have not been able to do any kind
of traffic engineering here.
In fact, the only way we can make
traffic engineering work
is subdivide the
extreme most left of our address space
and try and balance with that. And then
when we add another customer
it upsets everything and another customer
gets upset again.
In fact, this becomes so hard to manage,
it's just unmanageable.
Some operators have realized
that it's unmanageable and just simply
announce the smallest amount of address
space they can to the internet.
resulting in the serious pollution of
the internet routing table we see today.
Full of the smallest prefixes advertisable / 24 and ipv4
and / 48 and ipv6 it's not scaling for
ipv4 but still works just and it simply
will not scale at all for ipv6 with a
large number of / 48 that are feasible
out of every single / 32 that's
distributed to a network operator
instead we should be doing planned IP
addressing rather than filling up the
address space from one end of the range
we should divide the range into two
number the odd-numbered customers from
one side and the even-numbered customers
on the other side for example and then
the scheme becomes quite simple in this
21 we announce the two 21s on our two
external links we are now it's one
twenty two and one leg and the other 22
on the other link it means that traffic
for the first twenty two customers one
three five seven nine in the diagram
will come in one link and traffic for
the other customers two four six eight
ten will come in the other link so we'll
have some kind of rudimentary load
balancing here assuming each customers
doing more or less the same thing on the
internet today or you could adopt
another strategy maybe the first twenty
two is for residential customers and the
second twenty two is for commercial or
enterprise customers or some other
allocation to suit but the important
point I want to make here is IP address
planning is critically important when it
comes to doing traffic engineering for
multihoming
so this example works fine for
multihoming between two upstream
providers we could also subdivide the
address space to suit more upstreams
maybe three maybe four although as you
see trying to do the traffic balance
will get harder with more up streams we
have an important pointers don't forget
to always announce the aggregate out of
each link
© 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.