|
(Disponibile solamente in inglese.)
General
The term Multihoming is usually used to describe the situation where a network connects to the
Internet via two or more different Internet Service Providers (ISPs). A network that has a single
Internet connection is said to be single-homed.
In this document the term customer is used quite loosly to describe a network that is
connected to the rest of the Internet via the ISP(s). In other words, the terms customer and
provider imply nothing more than the relative position with respect to the global Internet.
The customer network may of course be an ISP itself, and may even have it's own customers who
are multi-homed.
Note that Multihoming is not the same situation as a network having two or more connections
to a single ISP. Multiple connections to IP-Plus are described in a separate document.
Multihoming can be challenging task. It requires a well-defined routing policy, and then the
imlementation of that policy using the BGP4 routing protocol. There are many hidden complications
due to the limitations of the BGP4 protocol itself, and due to the modern Classless Inter-Domain
Routing system (CIDR) now in use on the Internet.
The most important advice to customers of Swisscom who are considering Multihoming is to think
very carefully about what what they want to achieve. In very many cases it turns out that a
customer's goals are either not possible at all or are not worth the time and effort.
Possible reasons for Multihoming
Backup. A customer to whom the ability to reach the entire global Internet is very important
(for example, one who is an ISP himself) may want to be multi-homed so that he can still reach
the Internet even if one of his primary ISP has a problem.
Load-sharing. Usually, a customer who is multi-homed primarily for backup reasons will be
reluctant to pay a backup ISP for a connection which is only used if the primary ISP fails -
he will typically also try to share his traffic between the ISPs during normal operation.
Improved regional or local connectivity. A customer may connect obtain his global Internet
connectivity from one primary ISP, but also connect to other ISPs in order to reach important
local or regional networks to which the primary ISP does not have good connectivity.
IP addressing
The modern Internet uses a hierarchical IP addressing and routing architecture called CIDR
(Classless Inter-Domain Routing). This means that the IP addresses assigned to an end-user are
dependent on the physical (topological) position in the Internet. Before CIDR, addresses were
permanently assigned to end-user organisations, and were portable - one could use the same
addresses with any ISP. Unfortunatly, this led to an explosion in the size or the routing tables
in the Internet, and CIDR was introduced to correct the situation.
Under CIDR, large blocks of IP addresses are allocated to ISPs, who then assign them to
end-users. The ISPs do not advertise a route to each and every customer, but a single route to
the entire block, thus reducing the size of the routing tables (or at least slowing the rate of
growth). However, a consequence of CIDR is that end users have to change IP address when they
change providers. While CIDR saved the Internet (before CIDR, collapse of the routing system was
expected during 1994), it has generally made the whole system less flexible.
Currently, the Internet is still in a transition phase - there are still very many networks
with old- style provider-independent (PI) addresses, but an increasing number with CIDR-based
provider-aggregated (PA) addresses. However, as the size of the routing table continues to grow,
some large backbone ISPs are introducing prefix-length route-filters which block routes to small
ranges of PI addresses (small being generally defined as less than 32 contiguous C-class
addresses) So while it may seem that PI addresses are more desirable for an end-user than PA
addresses, it is not possible to guarentee global Internet reachability with a small block of
PI addresses.
IP Addressing and Multihoming
Customers with small blocks of PI addresses. In this case all of the ISPs announce routes to
the customers PI address block to the global routing system. However, none of the ISPs can
guarentee global connectivity, because the routes may be blocked elsewhere in the Internet
by prefix-length filters.
Customers with PA addresses. In this scenario the multi-homed customer has PA addresses from one
of the ISPs (ISP A). Normally the customer wants global connectivity through both ISPs, in which
case ISP A announces a single 'aggregate' route to the entire block of PA addresses assigned by
RIPE to ISP A, plus a more specific route to
the address range assigned to the customer. ISP B
announces only the more specific route. Routers normally prefer more specific routes, so the
traffic will follow the more specific routes back to the customer. Whether the traffic chooses
the route via ISP A or ISP B will depend on the routing policies of the various transit ISPs and
networks along the path. In zones of the Internet where the more specific routes are not present
because of prefix- length filters the traffic will follow the aggregate route to ISP A, until it
enters a region where it encounters the more specific routes. A variant would be for the customer
to get global connectivity through ISP A and local connectivity through ISP B - ISP A only
announces the aggregate route and ISP B announces the more-specific route only to a restricted
region of the Internet.
Customers with large blocks of PI addresses. If the customer has at least a block of 32
contiguous C-class networks which are announced as a single route to all of the ISPs, or he has a
B-class network, then in this case there are no address or routing restrictions on Multihoming.
(Actually, there are some backbone providers with filters on routes to blocks of 64 or even 128
C-class networks, but it is expected that all ISPs will move to a common accepted size of 32
C-class networks in the next few months.)
Asymmetric routing
The BGP4 protocol allows a customer to specify which ISP should be used to send IP packets to
specific destinations in the Internet - this is the routing policy. However, those destinations
will usually have their own routing policies, so it is quite possible that return packets will
use a different path. Though it is possible for a network to influence the path used by return
traffic, it is not possible to specify it. This asymmetric routing is not necessarily a severe
problem, and it is possible to live with it. However, if possible it should be avoided. For
example, if the outward and return paths have very different capacities it will lead to overall
poor performance. It also makes it difficult to troubleshoot routing problems because the
traceroute tool cannot be used.
Routing policies and router specification
Normally a typical customer can have a so-called default routing policy. In this case the
customer specifies a default network, which is the network to which he wants all packets sent
when his routers do not have an explicit route for the destination in their routing tables.
All he then needs to accept from his primary ISP (via the BGP protocol) is a route to this
default network. From his various secondary ISPs he can then choose to accept a limited set of
routes - for example routes to those networks which are well connected to the secondary ISPs.
This basic policy can be extended: the customer might also accept a route to his default network
from the secondary ISPs. If he configures his router(s) to give these secondary default routes
a lower weight than the primary route, his traffic will normally flow to the primary ISP, but
will be automatically switched to the secondary ISP if the primary fails. On the other hand, if
the customer wants good connectivity to destinations which are well-connected to the primary ISP,
then he might choose to accept explicit routes to these destinations from the primary ISP.
This type of Multihoming does not necessarily require high-end routers. The routing can be done
by simply having a default route to a primary ISP, then accepting a limited number of explicit
routes from the other ISPs. Such a scenario can be implemented with routers such as Cisco 2600
series.
One drawback with default routing is that it is prone to asymmetric routing and routing loops.
Under certain circumstances a customer may require full routing, that is, the entire Internet
routing table of several thousand entries in his router(s). This might be the case if he is
trying to share his traffic to the entire Internet between multiple ISPs, since he will need at
least a large proportion of the full routing table from at least one ISP in order to make a
decision about which ISP should be sent a particular packet.
Full routing requires high-performance routers (for example Cisco 7200 series or better) equipped
with extra RAM memory. Normally 128 Mbytes is specified, but under certain circumstances less
memory than this can be used with full routing.
Multihoming with IP-Plus® Internet Services
If a customer decides that multihoming is a practical option, then this is available to him as
part of the IP-Plus Internet service. Swisscom has two standard multihoming configurations:
- Swiss Routes/Default Routing
- Global Connectivity/Swiss Routes: Swisscom announces the customer's routes globally. The
customer does not receive the full global routing table from Swisscom, but only networks
included in the Swiss Routes. This option is available as standard at all IP-Plus POPs, and
can be done with low-end routers.
- Global Connectivity/Full Routing: On the Swisscom side, this is implemented in exactly the
same way as the Global Connectivity/Swiss Routes option. The BGP session propogates the full
Internet routing table to the customer. This type of connection requires a high-end router with
at least 128 MByte of RAM.
The following special considerations also apply:
- If a multihomed customer requires PA addresses from Swisscom, the normal address
assignment rules apply.
- Multihomed customers are permitted to announce specific routes to Swisscom PA addresses to
their other ISPs. Swisscom will accept these routes when they are re-announced to Swisscom from
other ISPs. (Not all ISPs do this - if your multihoming strategy requires this, then we advise
you to check)
- If a multihomed customer has PA addresses from another ISP, Swisscom will announce the
specific routes to these addresses, but the customer must understand that the global routing of
his addresses is not dependent on Swisscom alone - connectivity to regions of the Internet behind
prefix-length filters depends on the other ISP. Therefore Swisscom alone cannot guarentee global
connectivy.
- If a multihomed customer has PA addresses and then cancels the connection to the ISP that
assigned the PA addresses, so that he is single-homed to Swisscom, then he must renumber to
Swisscom PA addresses.
- If the customer has a range of PI addresses less than 32 contiguous C-class networks, he must
understand that global Internet connectivity is not guarenteed.
- The customer must have his own autonomous system number. If he does not yet have one,
Swisscom can apply for one on his behalf.
- Multihoming is not available with the IP-Plus Internet managed router option. The customer
must have his own router running the BGP4 protocol. The customer is responsible for the
definition and maintenance of his routing policy and the router configuration. (Swisscom can
offer consulting services for this)
- The customers routing policy must be implemented totally within the customers network.
Swisscom cannot change its own routing policy in order to realise policy goals of customers.
- Swisscom reserves the right to change it's routing policy (for example to optimise load
sharing or connectivity) without informing the customer.
- Swisscom applies both AS-path filters and IP address filters to BGP routing announcments
from multihomed customers. These filters are built using the information that the customer has
entered into the RIPE routing policy database. They are NOT updated automatically. If a customer
wants to announce routes to new autonomous system numbers or IP address ranges, he must first
update the RIPE database, and then alert Swisscom to the changes. Swisscom NOC will then update
the filters based on the new RIPE database entries.
|