Multi-homing

Multi-homing
Multi-homing is the process of having more than one connection to one or more service providers.
We are going to take a look at two different types of multi-homing: multi-homing to a
single service provider and multi-homing to multiple service providers.
Single service provider Multi-homing to a single service provider provides redundancy for your
network in case one of the connections to the service provider goes down. There are a couple of
different ways you can accomplish this. The first would be to use the same router in your network
for both connections to the service provider. This is probably the easiest way. It does introduce a
single point of failure to the service provider. The other way would be to use different routers in
Multi-homing 317
your network to make separate connections to the service provider. This is the more complicated
way. The advantage is you don’t have a single point of failure to the service provider. When multihoming
to a single service provider, you don’t need to use BGP unless routing policies are required.
Multiple service providers Even with different types of multi-homing that can occur to a single
service provider, there is still the limitation of the service provider itself being a single point of failure.
Multi-homing to multiple service providers overcomes this limitation. With multi-homing to
multiple service providers, you still have the same options of connecting to it as you do with multihoming
to a single service provider. There is an item that you need to take note of when connecting
to multiple service providers: If you are using BGP to connect to the multiple service providers and
your eBGP devices are running iBGP between themselves, there is the possibility of your AS
becoming a transit AS. This means that the service providers could end up passing traffic through
your AS. This could consume part of your bandwidth and cause congestion in your network. If
you don’t want the service providers to use your network, you need to implement BGP policies
that do not allow it. For instance, you could use the NO_EXPORT community on routes coming
in from each of the providers. This would allow your local BGP speakers to learn the routes, but
the routes would not be propagated to the other service provider. Another way would be to create
an AS path filter that allows only routes originated from your AS to be advertised out. You would
then need to apply the filters to each of the outgoing BGP sessions. These are only a couple of ways
of preventing your AS from becoming a transit AS.
So, how can you create a multi-homed environment? Actually, there are a few ways:
Default static routes Default static routes are the easiest way to configure multi-homing. All
they require are the configuration of two default routes: one pointing to each of the service provider’s
devices. You would then need to add a metric to the end of each of the static routes. Give
the lower metric to the route you want to be your primary connection. Give the higher metric
to the route you want to back up the primary. That way, if the primary connection encounters
trouble, the backup will take effect. When the primary line becomes the backup, it will resume
the role of transporting the data to the service provider. The limitation to this is that traffic may
end up taking a less optimal path to the destination.
Common IGP Another means of communicating with the provider is to use a common agreedupon
IGP. The service provider can then inject any routes into the IGP. You would then redistribute
these routes into your local IGP. By doing this, you are better able to make routing decisions
based on the best metric of the routes. The problem with this method is that you do not want too
many routes being advertised into your local IGP. Too many routes in a routing table can cause
latency in your network. Another problem with using this method is that you will still receive a
default route for all of the other routes that have not been injected into the IGP. That in turn means
that the traffic you are sending still may not take the best path to the destination.
BGP BGP allows for the greatest control of the routing decisions by your local devices. By
enabling BGP to the service provider, you are able to enforce policies on the routes you are
receiving. This enables you to better state which paths to take, ensuring that your traffic is taking
the best path to the destination. This is true only when you are accepting the full routing
table from the service provider. There are times when you will be accepting only a partial routing
table from the service provider. In this case, you are still able to enforce BGP policies on the
318 Chapter 9  Advanced Border Gateway Protocol
routes you are receiving. There isn’t a guarantee when accepting partial routing tables that your
traffic is taking the best path to the destination. The control you have over the BGP policies that
you’re able to enforce still makes the use of BGP a better choice than using a common IGP with
the service provider.