Multihomed IP hosts

A few weeks ago, a member of the NANOG mailing list asked an interesting question: is it OK for a host to have two physical interfaces in the same IP subnet (obviously with two different IP addresses)?

The follow-up discussion uncovered an interesting fact: although such a configuration is quite unusual in the modern IP world, it’s explicitly permitted by RFC 1122. The discussion also exposed numerous problems you might experience when trying to deploy this design on a Linux host as well as some misconceptions about the source IP addresses in TCP and UDP packets.

I’ve summarized the topologies defined in RFC 1122, IP addressing rules pertinent to TCP/UDP clients and servers as well as problems you might experience in the Multihomed IP hosts article in the CT3 wiki.

This article is part of You've asked for it series.

5 comments:

  1. I followed the conversation on NANOG with much pleasure, from both the pro- and the con-side of the argument, regardless of RFC-'legality'.

    If I recall correctly the argument started because of loadbalancing/high availability issues.

    It gets even more interesting if you allow the host to bridge between these interfaces and an HA virtual interface, although I think that bundeling (bonding) of the interfaces the 'cleanest' solution is. Ofcourse there are some problems if your aggeregate is spanned over multiple switches because of HA demands, which often forces the use of active/passive constructions.

    Luckily switch-cluster technology (SMLT, VSS etc.) is becoming available on enterprise-grade hardware, which overcomes these problems.

    Question regarding the future, will there be host-implementations of L2MP? Oppertunity or headache?

    ReplyDelete
  2. Several of our clients "acomplished" to implement multihomed servers generating a kind of "assymetric routing" which generated "exessive unicast-flooding". In one case (paired with huge filetransfers) this resulted in periodical "brownouts" of there core. This "phenomenon" could/should be added to the issues section.

    ReplyDelete
  3. @Michael: Gladly. Could you send me more information? You can use the form accessible through the "Contact" link on the top of the page if we haven't communicated before.

    ReplyDelete
  4. There were several comments in the NANOG thread suggesting that exit interface and source IP address are necessarily correlated.

    This just isn't true.

    For connectionless protocols, and for the first (SYN) packet in a TCP session, the correlation *might* be there, but even that can be changed.

    Consider the "source-interface" set of IOS commands, which force the first packet in a session to ignore the exit interface.

    For a mid-session example, consider this: I can ssh into the external interface of my linksys router from inside my home network.

    The exit interface of the response packet is the internal one, but the source address is the external one.

    I'm suprised how many people got this wrong.

    ReplyDelete
  5. @Anonymous: the misconceptions in the NANOG thread prompted me to write the Wiki article.

    If you go through the TCP/UDP portion of it, you'll see the exact correlation between the outgoing interface and source IP address (when and where it does exist).

    ReplyDelete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.