Multihoming

Multihoming refers to a computer or device connected to more than one computer network. It can be used, for example, to increase the reliability of an Internet Protocol network, such as a user served by more than one Internet service provider.

Variants

In the IP context, there are several ways to multihome, separate from the actual protocols used to do so, amongst which the most important are:

Single Link, Multiple IP address (spaces)

The host has multiple IP addresses (e.g. 2001:db8::1 and 2001:db8::2 in IPv6), but only one physical upstream link. When the single link fails, connectivity is down for all addresses.

Multiple Interfaces, Single IP address per interface

The host has multiple network interface controllers (NIC) and each interface has one, or more, IP addresses. If one of the links fails, then its IP address becomes unreachable, but the other IP addresses may still work. Hosts that have multiple IPv6 or IPv4 records enabled can then still be reachable at the penalty of having the client program time out and retry on the broken address. Existing connections can't be taken over by the other interface, as TCP does not support this. To remedy this, one could use Stream Control Transmission Protocol (SCTP) which does allow this situation. However SCTP is not used very much in practice. A new protocol based on TCP, Multipath TCP, taking form as a TCP extension, is also being actively worked on at the IETF as of March 2012. It would also remedy this issue, as well as providing better performance by making use of every available network interface.

Multiple Links, Single IP address (space)

This is what is generally meant by multihoming. With the use of a routing protocol, in most cases Border Gateway Protocol (BGP), the end-site announces this address space to its upstream links. When one of the links fail, the protocol notices this on both sides and traffic is not sent over the failing link any more. This method is usually employed to multihome a site and not for single hosts.

Risks generated by multiple connections to one ISP:

Multiple Links, Multiple IP address (spaces)

This approach uses a specialized Link Load Balancer (or WAN Load Balancer) appliance between the firewall and the link routers. No special configuration is required in the ISP’s routers. It allows use of all links at the same time to increase the total available bandwidth and detects link saturation and failures in real time to redirect traffic. Algorithms allow traffic management. Incoming balancing is usually performed with a real time DNS resolution.

Another common use of this variant is to control routing between the separate address spaces used by each interface. This is often used for PC server based firewalls.

Caveats

While multihoming is generally used to eliminate network connectivity as a potential single point of failure (SPOF), certain implementation caveats apply which can affect the success of such a strategy.

In particular, to eliminate the network single point of failure:

The elimination of a single point of failure is achieved only when each component that could potentially fail is duplicated.

Multihoming can complicate interface administration. One technology that helps is the Consistent Network Device Naming convention of Linux.[2][3]

IPv4 multihoming

To be multihomed to the Internet using BGP, a network must have its own public IP address range and a public Autonomous System (AS) number. Then connections to two (or more) separate ISPs are established. The routing over these connections is normally controlled by a BGP enabled router.

In the case where one outgoing link from the multihomed network fails, outgoing traffic will automatically be routed via one of the remaining links. More importantly, other networks will be notified, through BGP updates of the multihomed network routes, of the need to route incoming traffic via another ISP and link.

A key pitfall in multihoming is that two apparently independent links, from completely different ISPs may actually share a common transmission line and/or edge router. This will form a single point of failure and considerably reduce the reliability benefits from multihoming.

Another problem to look out for is that multihoming too small a network may not be effective since route filtering is very common among BGP users and larger prefixes (smaller networks) may be filtered out.

IPv6 multihoming

As of 6 February 2010, multihoming in the next-generation Internet Protocol (IPv6) was not yet standardized.

Current solutions

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. 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.

Other possibilities

Mono-homing applies if users are affiliating with a single platform. From consumers’ perspective, using a single platform requires lower cost and effort – once an upfront and once an ongoing cost – compared to multiple platforms because using additional platforms lead to further expenses like additional adoption, training or even the opportunity cost of time. Hence, platform operators need to understand the needs of their users in order to position and price their products accordingly.

Potential solutions

See also

References

  1. ↑ "Multihoming - a complete step-by-step guide". 30 October 2015. Retrieved 12 February 2016.
  2. ↑ Matt Domsch (October 9, 2009). "Network Device Naming mechanism and policy". LWN. Eklektix, Inc. Retrieved May 27, 2013.
  3. ↑ Narendra K (July 2012). "Consistent Network Device Naming in Linux" (PDF). Dell Linux Engineering division. Retrieved May 27, 2013.

External links

IPv4 multihoming

IPv6 multihoming

Further reading

This article is issued from Wikipedia - version of the Friday, February 12, 2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.