Interface redundancy on the host with TCP Multipath

TCP and UDP protocols are used exchange data between hosts. They have been used for a decade or longer and are very well documented how they work.

Everyone knows the problem that when you lost your active link on the server all your TCP sessions are going to die as well. Let's say your server has 2 active interfaces. There is no way to move/migrate a TCP session to use another active interface (by default). The other link can't be used automatically as a fail back mechanism.

There are couple of reasons behind why it isn't to works, the simplest one is that the new link used a different IP address. Even if the Linux kernel would start using the new interface and start sending IP/TCP packets sourced with the new IP address these packets wouldn't be recognized on the remote site. The remote site expect tcp segments from one and only one IP source.

Problem

How to provide a link level redundancy on the server to keep a TCP session alive even if one interface experience an error.

Analysis and solution Demonstration

The problem could be see as a more generic issue: how to implement multihoming or link redundancy. There are couple of working solution out there. The simplest example:

• Link bonding(link aggregation) on the server; requires support and proper configuration on the switch and the server

We will look at another one: TCP Multipath. What is cool about this is that it is transparent to your application. It visualizes a session and provide a single TCP session to the application that can benefit from built-in multipath redundancy on the kernel level.

References

http://multipath-tcp.org/
Decoupled from IP, TCP is at last able to support multihomed hosts
https://devcentral.f5.com/articles/multipath-tcp-mptcp
https://devcentral.f5.com/articles/the-evolution-of-tcp