See more Multihoming articles on AOD.

Powered by
TTSReader
Share this page on
Article provided by Wikipedia


( => ( => ( => Multihoming [pageid] => 641227 ) =>

Multihoming is the practice of connecting a "host or a "computer network to more than one network. This can be done in order to increase reliability or performance, or to reduce cost.

Contents

Introduction[edit]

A typical host or end-user network is connected to just one network. In many circumstances, it can be useful to connect a host or network to multiple networks, in order to increase reliability (if a single link fails, packets can still be routed through the remaining networks), to improve performance (depending on the destination, it may be more efficient to route through one network or the other) and to decrease cost (depending on the destination, it may be cheaper to route through one network or the other).

Variants[edit]

There are several different ways to perform multihoming.

Host multihoming[edit]

A single host may be connected to multiple networks. For example, a mobile phone might be simultaneously connected to a "WiFi network and a "3G network, and a desktop computer might be connected to both a home network and a "VPN. A multihomed host usually is assigned multiple addresses, one per connected network.

Classical multihoming[edit]

In classical multihoming,[1][2] a network is connected to multiple providers, and uses its own range of addresses (typically from a "Provider Independent (PI) range). The network's edge routers communicate with the providers using a "dynamic routing protocol, typically "BGP, which announces the network's address range to all providers. If one of the links fail, the dynamic routing protocol recognises the failure within seconds or minutes, and reconfigures its "routing tables to use the remaining links, transparently to the hosts.

Classical multihoming is costly, since it requires the use of address space that is accepted by all providers, a public "Autonomous System (AS) number, and a dynamic routing protocol. Since multihomed address space cannot be aggregated, it causes growth of the global routing table.[3]

Multihoming with multiple addresses[edit]

In this approach, the network is connected to multiple providers, and assigned multiple address ranges, one for each provider. Hosts are assigned multiple addresses, one for each provider.[4]

Multihoming with multiple addresses is cheaper than classical multihoming, and can be used without any cooperation from the providers (e.g. in a home network) but requires additional technology in order to perform routing:[5]

Caveats[edit]

When multihoming is used to improve reliability, care must be taken to eliminate any "single point of failure (SPOF):

By increasing the number of interfaces and links being used and making routing less deterministic, multihoming complicates network administration["citation needed].

IPv4 multihoming[edit]

Classical multihoming is the dominant technique for IPv4. This requires that a network have its own public IP address range and a public "Autonomous System (AS) number.

While multihoming with multiple addresses has been implemented for IPv4,[6] it is not generally used, as host implementations do not deal well with multiple addresses per interface which requires the use of "virtual interfaces".[7]

It is also possible to implement multihoming for IPv4 using multiple "NAT gateways.[8]

IPv6 multihoming[edit]

Both classical multihoming and multihoming with multiple addresses may be used in IPv6.

Classical multihoming[edit]

"Provider Independent Address Space (PI) is available in IPv6.[9] This technique has the advantage of working like IPv4, supporting traffic balancing across multiple providers, and maintaining existing TCP and UDP sessions through cut-overs. Critics say that the increased size of "routing tables needed to handle multi-homing in this way will overwhelm current router hardware. Proponents say that new hardware will be able to handle the increase due to cheaper memory, which drops in price according to "Moore's law. Proponents also say this is the only viable solution right now, and the "worse is better philosophy supports the idea that it is better to deploy an imperfect solution now than a perfect solution after it is too late.

Because many ISPs filter out route announcements with small prefixes, this will generally require a large "ISP-sized" IP allocation, such as a /32, to ensure global reachability. Using such large prefixes is an inefficient use of IPv6's address space; there are only about 4 billion /32 prefixes. However, from a pragmatic perspective, allocating a /32 is equivalent in global address space cost to allocating a single IPv4 address, and this may be acceptable if, as seems to be likely for the foreseeable future, the number of multihomed sites can be numbered only in the millions, as opposed to the many billions of non-multihomed endpoints which are anticipated to comprise the vast majority of IPv6 endpoints.["citation needed] Some "regional Internet registrys (RIR) such as RIPE have started to allocate /48 from a specific prefix for this purpose. RIPE allocates IPv6 provider-independent address spaces /48 or shorter from 2001:0678::/29.

Multihoming with multiple addresses[edit]

Multihoming with multiple addresses has been implemented for IPv6.[6][10] For outgoing traffic, this requires support on the host, either protocol agnostic ("Multipath TCP, "SCTP, etc.) or specific to IPv6 (e.g. "SHIM6).

Other solutions[edit]

See also[edit]

References[edit]

  1. ^ Iljitsch van Beijnum, A look at multihoming and BGP 
  2. ^ Sample Configuration for BGP with Two Different Service Providers (Multihoming) 
  3. ^ http://bgp.potaroo.net/
  4. ^ https://tools.ietf.org/html/rfc2260
  5. ^ https://tools.ietf.org/html/rfc5220
  6. ^ a b Matthieu Boutier; Juliusz Chroboczek (2015), "Source-specific routing", Proc. IFIP Networking 2015, "arXiv:1403.0445Freely accessible 
  7. ^ https://tools.ietf.org/html/draft-wr-mptcp-single-homed-07
  8. ^ Vector Routing (PDF) 
  9. ^ https://www.ripe.net/participate/policies/proposals/2006-01
  10. ^ https://tools.ietf.org/html/draft-ietf-rtgwg-dst-src-routing-02

Further reading[edit]

) )