multihoming by stariya


									CS691         Project Report – Study of Multi-Homing           Spring 2003




                  Sunil Bhave
               CS691, Spring 2003

Sunil Bhave                Page 1 of 10                Due Date: 05/11/2003
CS691               Project Report – Study of Multi-Homing           Spring 2003

                             Table of Contents
Introduction                                                              3

Network Routing Basics                                                    3

MultiHoming                                                               4

Border Gateway Protocol                                                   5

Advantages of Multi-homing                                                6

How to implement                                                          8

Issues                                                                    9

Conclusion                                                                10

References                                                                10

Sunil Bhave                      Page 2 of 10                Due Date: 05/11/2003
CS691                    Project Report – Study of Multi-Homing                Spring 2003


These days we can not imagine doing our job without being able to send and receive
email, or look up information on the Web. Being disconnected from the Internet hurts,
even if you don't immediately lose millions of dollars in revenue, as would be the case
with the companies that solely depend on internet for sales such as eBay or Amazon. But
the fiber and copper wires that connect you just sit there in the ground, waiting for a
backhoe or a rodent to come along, or for the moisture to finally seep through. Then there
is all the equipment, which also doesn't last forever, and which has software bugs and is
prone to configuration mistakes. A single typo can bring down a good-size part of an
Internet service provider network. Bankruptcy will do it, too. The only way to protect
yourself against all of these eventualities is to have more than one connection to the
Internet. This is called multihoming.

You are multi-homed when you have two "upstream providers". These could be other
ISPs that you exchange backup service with; large backbones such as MCI, Sprint,
UUNet, or regional backbone providers; or other local ISPs.

Before we talk about multihoming, some discussion of network routing basics is in order.

Network Routing Basics

This may seem obvious, but there are two things your provider is supposed to do for you:
(1) Bring data from the rest of the Internet to your network, and (2) Take data from your
network to the rest of the Internet.

(1) Your Provider Bringing Data to You
Providers exchange routes with each other. A route is both a description of a section of
IP address space and a "promise to accept data" for that section of IP address space.

So how does someone someplace on the Net send data to you? They send a packet to
their provider. If you are using a different provider, then their provider sends that packet
to your provider based on a "route announcement" having occurred between those two
providers. So outgoing route announcements bring data in to your network.

Either your provider "nails" your routes into their internal routing table and external
route-announcement table somehow, or you announce your routes to your provider and
then those routes go into their internal & external-announcement routing tables. Of
course, if you got your IP address space from that provider, they will not be
announcing your smaller sub-route to the rest of the Internet at the exchange points.

(2) You Sending Data to the Internet
One of your machines generates a packet of data, and it's not destined to somewhere
within your network. Where do you send it? To one of your provider. How do you make
that decision? There's a route in your "border router"(s).

Sunil Bhave                            Page 3 of 10                  Due Date: 05/11/2003
CS691                    Project Report – Study of Multi-Homing                Spring 2003

Default route: If you have a default route (also written as the route), then you are
just sending all data that you don't know what to do with the one of your providers. Even
with functional multi-homing, you may still be doing this.

Taking routes from your provider: If you have one provider, you *could* take all of
the routes on the Internet But why would you want to do that if you only have one
provider? It gives you the same net effect as if you just defaulted into that provider.


Now that we have discussed how routing works, we will now discuss the scenarios in
which multihoming can be done.

Multihoming Scenarios

Getting a second connection is just the first step. When the first connection goes down,
you will need to start using the second one. There are three ways to accomplish this:

(1) Get two independent connections and configure your equipment with two IP
addresses. When the IP address associated with one connection doesn't work anymore,
the router or server has to switch over to the other. This approach has several limitations.
Obviously, all ongoing communication sessions are disrupted by the change in IP
address. Also, this functionality isn't always available in routers, servers, or other
equipment. Finally, most applications (such as Web browsers) aren't designed to try
multiple IP addresses just in case one is down, so this approach is generally only
workable if the multihomed network only has clients and not servers.

(2) Get two connections to the same ISP. This ISP will then make sure you can use the
same IP addresses over both connections. How this is exactly configured on your side
depends on your ISP and on what your requirements are. A setup where you use two
routers, one for each connection, is of course more complex, but this way, you can
survive a router going down. In many cases, the actual configuration will be very similar
to the next option (BGP), but because you don't need a "real" AS (Autonomous Systems)
number or an independent IP address range, it is much easier and cheaper to get this off
the ground, and your ISP protects you against most configuration mistakes. Having two
connections to the same ISP has one major downside: you still have to depend on a single
ISP. Fortunately, ISP-wide network failures are very rare, but all ISPs have points of
presence or connections to certain external networks that go down from time to time. And
there is always the risk of your ISP going belly-up.

(3) Get two connections to two ISPs, but use the same IP address range over both. This
way, you are not only safe from physical problems with telco connections, but also from
ISP-wide failures and nearly all types of configuration problems that affect just a single
ISP: if one fails, you just use the other. This is done on a per-destination basis: your

Sunil Bhave                            Page 4 of 10                  Due Date: 05/11/2003
CS691                    Project Report – Study of Multi-Homing                 Spring 2003

router can figure out which destinations are reachable over which ISP, and route packets
accordingly. This works extremely well, but there is still a downside: all major routers
throughout the Internet must know over which ISPs your IP addresses are reachable at all
times. This means you have to participate in inter-domain routing using the Border
Gateway Protocol (BGP).

Border Gateway Protocol

BGP is the only widely implemented EGP (Exterior Gateway Protocol) and the only
routing protocol linking networks to one another on the Internet. BGP was first specified
in 1989 in RFC 1105. Version 4 was specified in 1994 in RFC 1654 and updated in RFC
1771. There also have been a number of documented extensions. Version 4's most
significant contribution is the ability to aggregate advertisements from multiple
contiguous routes in one routing-table entry, a.k.a. CIDR (Classless Inter-Domain
Routing). BGP4 was implemented when big routing tables began overwhelming routers.

CIDR protects you from many potential outages and instability on the Internet, and
provides great relief for address depletion by more efficiently dividing addresses.

When enabled, BGP4 establishes relationships with adjacent routers, referred to as
neighbors. Unlike OSPF (Open Shortest Path First) and EIGRP (Enhanced Interior
Gateway Routing Protocol), which will automatically discover the routing neighbors,
BGP won't exchange routing-table information until both routers have configured one
another's IP addresses and ASNs (Autonomous System Numbers) on their corresponding
interfaces. Once this is completed, the routers are considered peers.

Neighboring routers send small "keep-alive" messages to one another. If a neighbor stops
receiving keep-alive messages for a predefined "hold time," it will update its routing table
to reflect the loss in available routes. BGP also sends incremental updates when routes
become unavailable. Otherwise, the full routing tables are exchanged only when two
routers first establish or re-establish a peering relationship.

BGP is a Path Vector Protocol, which is similar to a Distance Vector Protocol, but with a
key difference. A Distance Vector Protocol chooses routes based on the hop count (or
routers traversed) and link speeds; BGP, in contrast, chooses a route that traverses the
least number of Autonomous Systems (AS). As a routing advertisement passes through
an AS, it prepends (adjusts the path length advertised) the ASN of the AS of origin to the
path of other ASes it has traversed. By default, the path with the fewest ASNs is stored in
the routing table as the optimal path to a destination network. One AS can contain
multiple routers, so it's possible the actual hop count is higher than the AS path indicates.

However, with BGP's built-in flexibility, you can enhance this default behavior. For
instance, you may want to control the path traffic takes leaving your network. When
peering with multiple neighbors in an external AS, or in different external ASes, there

Sunil Bhave                             Page 5 of 10                  Due Date: 05/11/2003
CS691                   Project Report – Study of Multi-Homing                Spring 2003

will be multiple paths to the same destination network. By default, BGP determines the
optimal path by picking the route that has traversed the fewest number of ASes.

However, BGP does not take link speed or network load into consideration when
computing paths, so the shortest path may not be the optimal one.

You can get around this by using BGP's Local-Pref attribute, which forces BGP to take a
particular next-hop route in a scenario with multiple choices. Tell the router that all, or
even some, of the routes advertised to one of your router interfaces should receive a
higher Local-Pref weight than the same routes advertised to another interface. Because
Local-Pref is always considered before the computed path-distance, the interface you
designate with the highest Local-Pref will be chosen as the route.

Controlling traffic coming back into your network is more difficult. With geographically
diverse networks, where one ISP connection is a lot closer to one part of the network than
another, you may want to use the MED (multiexit discriminator) attribute, which
specifies the path external traffic should use when destined for one of your internal
networks. Although the MED attribute is a fairly simple way to control incoming traffic,
it will work only if both Internet connections go to the same ISP because it won't be
propagated outside that ISP's AS. Prepending is another way to control incoming traffic.

BGP routing can be controlled through the community attribute that puts a predefined
code on a group or community of routes so the receiving router takes a predefined action
based on the value of the code. This code can be user-defined, but the most common is a
reserved or well-known community, called No-Export. When a BGP router sees a route
come in with the No-Export community, it will not advertise the route outside its own
AS. This can be handy for balancing incoming traffic.


Multi-homing offers several advantages, we will discuss a few here.

(1) Fault-tolerance
Fault-tolerance is probably the most important benefit in the sense that anyone investing
in a multihoming solution will at least expect to gain this. The simplest form of fault
tolerance consists of using one network connection during normal operation and should
the link become unusable, migrate traffic to another. There are many reasons why a link
might go down in the Internet, including physical wire cuts, router crashes, power
outages and configuration errors. With the Internet becoming more and more important to
both businesses and organizations, we expect that more and more people will be willing
to invest in redundant Internet connections for purposes of fault tolerance.

(2) Load sharing
Load sharing is also a very important motivation. Bandwidth demands of Internet
applications are increasing rapidly, some examples are WWW, multimedia on demand,

Sunil Bhave                            Page 6 of 10                 Due Date: 05/11/2003
CS691                    Project Report – Study of Multi-Homing                  Spring 2003

IP telephony, file transfer, video conferencing and so forth. Very high bandwidth single-
wire solutions like fiber optic cable are available, but often at prohibitively high cost.
Multiple low bandwidth connections are a viable alternative which will in many cases
create multihoming scenarios. Traffic load distribution can be realized at several levels,
from simple random load sharing, to advanced calculated load balancing.

(3) Provider selection
The third benefit, provider selection, is already present in the IPv4 Internet of today, but
is expected to become even more of an issue in the IPv6 Internet of tomorrow. It is fairly
common today for Internet users to have multiple dial-up Internet Service Providers
(ISPs) configured and alternate between them. Particularly after the concept of free or
semi-free ISPs came into existence. However, in these cases users tend to only use one
ISP at a time, thus not creating a real multihoming scenario. With connection prices
constantly dropping, this is expected to change, and there is also a trend towards high
bandwidth, always online connections such as DSL and cable Internet. In addition to
expecting fault tolerance and load sharing, users may wish to alternate between different
Internet links depending on such factors as time of day and current traffic load, in order
to optimize the cost v/s quality of service equation.

(4) Eased renumbering transition
The fourth benefit is particularly interesting because of the new mechanisms for
renumbering networks introduced with IPv6. Renumbering an IPv4 network is usually a
major chore, involving work on every individual host. The process can be made easier if
solutions such as Dynamic Host Configuration Protocol (DHCP) are deployed, but it is
never going to be as easy as it is with IPv6. During a network renumbering, hosts will
have multiple addresses, creating a multihoming scenario where benefits such as
migrating transport layer connections transparently would be very welcome.

(5) Enhanced mobility support
Mobile IP networks almost invariably create multihoming scenarios. Both in the case of
moving between heterogeneous networks such as Ethernet to wireless, or when moving
from one wireless Local Area Network (LAN) to another. Often such a change involves
an overlap period where the mobile host is attached to multiple networks with different
addresses. Mobile IP is one the areas where the most growth is expected in the coming
years, as more and more people acquire portable computers and Personal Digital
Assistants (PDAs). Naturally, a lot of research effort is therefore going into this area, and
better multihoming solutions are an important part of this.

(6) Improved regional and Local connectivity
With the redundant connection in place, the ability to receive more data locally increases,
and can be important at peak traffic times

Sunil Bhave                             Page 7 of 10                  Due Date: 05/11/2003
CS691                   Project Report – Study of Multi-Homing                Spring 2003

How to implement

Configuring BGP on one or more routers isn't hard, but you really need to know what
you're doing to avoid mistakes that will come back to haunt you when something goes
down. This is not the time you want to find out that you didn't know as much about inter-
domain routing and BGP as you thought you did. It is advisable to take training courses
to prepare you for this, the same way being a passenger prepares you for driving a car:
not to any noticeable degree. This is because those courses only focus on simply
configuring a few BGP sessions; they don't tell you what will and what will not fly in the
real world. You need to read a book or a number of articles on configuring BGP in an
Internet environment. Or you can hire someone with experience in this area to handle the
entire project (this will cost a lot); to just implement the actual BGP configuration (this
will cost a lot less); or something in between.
Once you've decided you really want to do it, follow these steps to multihome to two
different ISPs using BGP:
    1. Decide what kind of help you need: a consultant, help from your ISP, or a book
    2. Learn about IP address ranges, prefixes, and netmask notations, as well as address
        allocation and assignment policies.
    3. Decide on the type of address space you're going to use.
    4. Select (a second) ISP and get your ISPs on board with your plans, preferably in
    5. Decide on the physical infrastructure: how many routers, what goes where,
        whether the connections share a physical path, how much bandwidth you need
        from each ISP.
    6. Request an AS number and IP address space, if necessary.
    7. Select one or more routers with enough CPU capacity and memory (128MB or
        more, or you need a more complex and less optimal configuration) to handle
        BGP, and make sure you have a software feature set supporting BGP.
    8. Configure BGP and set filters to avoid improper route announcements (such as
        routes from ISP A to ISP B, and vice versa).
    9. Register your routing policy in a Routing Registry.
    10. Use looking glasses to see if your announcements are visible elsewhere on the
    11. Periodically test if everything is as it should be by temporarily disabling a
        connection and checking if you can still reach all destinations, first for one
        connection and then the other.
    12. If necessary, adjust BGP properties to balance incoming and outgoing traffic to
        match the available bandwidth.


The benefits described in advantages section do not come for free. Each benefit raises
unique challenges.

Sunil Bhave                            Page 8 of 10                 Due Date: 05/11/2003
CS691                    Project Report – Study of Multi-Homing                Spring 2003

A common trait among the problems is that many of them can be solved at different
levels, from the application to the Application Programming Interface (API) and down to
the TCP/IP stack and the protocols it implements. Some problems can be solved both at
the routing level and at the end-to-end host level, or a combination of these two. This
creates a rich field of solutions which will hopefully allow the best ones to be picked.

Routing is one of the most discussed areas because it is fundamental to other benefits.
The fear is that a profusion of multihomed sites will cause large numbers of routing table
entries to be created in the backbone of the Internet, thereby making it slower and more
expensive to run. If a site is multihomed to a single ISP, there is no problem, the
addresses will all be within the same block of aggregatable addresses, and the only extra
routing done is entirely confined to the ISP. This solution is unlikely to satisfy sites
which are really serious about fault tolerance, because after all, the ISP becomes a single
point of failure. A big problem is therefore how to route multiple addresses reliably
without causing a routing table ``explosion'' in the backbone.

A desirable property of a fault tolerant solution is to have transport layer connections
survive a failure completely transparently. There are several ways to solve this problem,
either by having routers continue to keep the same address routable after a link failure, or
by modifying APIs and protocols to handle multiple addresses. Most current APIs such as
the socket API, and connection oriented protocols such as the Transport Control Protocol
(TCP) are designed for a 1-to-1 address relationship which does not suit multihoming
scenarios well.

Multihoming solutions may have to deal with challenges such as ingress filtering . This is
a mechanism recently introduced to the Internet because of problems with Denial of
Service attacks with forged source addresses, preventing tracing and escalating damage.
Ingress filtering is performed by the ISP on packets arriving from a customer. Any
packets bearing a source address outside the range advertised for the link will be filtered
out, effectively preventing any packets with a forged source address from being sent.
Multihoming represents one scenario where packets might legitimately be sent with a
source address from a different link. Because of the widespread use of ingress filtering
today, multihoming solutions should avoid using this technique. It would be cumbersome
and expensive for both ISPs and customers to require ingress filtering to be disabled on
links to a multihomed site.

Load sharing and provider selection both depend on the same subject, namely address
selection. This problem can be divided into source and destination address selection, but
the two are closely related. A third member should be added to this set; interface
selection. For a single connection, many different permutations of this set may provide
working communication, but which is the desired one? The answer is dependent on the
bits of the destination address, the time of day, the current level of traffic and other
factors, and therefore difficult to answer. This is a good example of a problem which can
be solved both by the choice of applications, APIs or even lower levels such as the
TCP/IP protocol stack.

Sunil Bhave                            Page 9 of 10                  Due Date: 05/11/2003
CS691                   Project Report – Study of Multi-Homing               Spring 2003

All the problems listed in this section are engineering challenges which will no doubt
occupy Internet architecture engineers for a long time. Already, many solutions have
been proposed and more are sure to follow. It is important to remember that there
probably will not be one catch-all solution, rather there will be alternatives, suited to
different budgets and architectures.


As we can see, even though mutihoming is extremely useful, there are many challenges
that need to be overcome. A lot of research work has been done in this area, and I feel
that there is more scope.


There is plenty of information available on internet regarding multihoming. Following
are few references I have used.

Sunil Bhave                           Page 10 of 10                Due Date: 05/11/2003

To top