Does there exist a way to split TCP/IP traffic across three routes and have the first packets to reach the destination be used?

I'm imagining something like multi-homing but with the requirement that traffic is sent on all three links each time.

We have three routes (over different physical interfaces to different ISPs) to an IP address and want to achieve the minimum latency at all times with redundancy/failover. We'd like the application layer to see a single IP address but have the traffic make best use of the three connections.

The latency/availability can change on all three connections so I was wondering about the possibility of sending packets down all routes and having the winning packet be the one that was used.

  • 1
    So you want to send the same identical data 3 times, and use which arrives first? What is the problem you are having that this solves? – DanBig Apr 8 '13 at 15:43
  • What are you actually trying to achieve? It sounds like you have 3 Internet connections and want all outbound connections to go out on all three then somehow have the connection complete on whichever was fastest to that destination at that time. – USD Matt Apr 8 '13 at 15:51
  • updated the q a little in response to your comments – chillitom Apr 8 '13 at 16:33
  • I believe your question has been answered on unix.SE (for Linux, at least). By the TCP protocol definition, received dulicate packets should be dropped automatically when discovered (when sequence numbers equal, not sure this is the case for the referred solution). – Lukas Apr 8 '13 at 17:26
  • 2
    You should talk directly to someone with expertise in wide area networking. You will need several back and forth rounds of the expert asking questions and you giving answers to focus in on the right solution. To start, figure out what your requirements are and forget any notions you might have about how you think you will meet them. Details will matter. Is this bulk data? Lots of tiny bits. The occasional tiny bit? Is it requested by the client or unsolicited? Can you run your own "shim" on both ends? Is the same data going to all clients? And so on. – David Schwartz Apr 8 '13 at 19:36

The approach you are suggesting is completely wrong in my opinion.


Its a waste of resources, it's like "security through obscurity" patching over a problem rather than fixing it directly, and it's going create complexity that can be avoided through a better designed solution (trouble shoot network issue over three links at once, I don't fancy that!)

So What Then?

As you said yourself, the latency of each link will be fluctuating. I see a few of approaches here, either way, the solution needs to be one that was designed for such a scenario (tackling latency and RTT issues). Look at solutions for this, your actual problem, not the meta problem of "how to use all three links at once?".

Solution One

First, if you have three links, ditch 1 or 2 of them, and re-invest the money on something with a guaranteed latency. ISPs sell point-to-point links (so get one to your destination) with an SLA on delay, and your on for a winner right there. You can keep the third link as a backup if you like.

Solution Two

The second option to use something like Cisco's OER (optimal edge routing). Other vendors have similar technologies, or if you have a *nix firewall/router/gateway for example, you could also script or code a similar solution for yourself. Using Cisco OER as an example, it allows you to set up tests (i.e. ping's) to a destination, it measures the quality of the test, if it degrades to a certain point, traffic is rerouted another way. So you can set up tests for latency and always use the lowest latency route.

Solution Three

MPLS TE - Multi Protocol Label Switching - Traffic Engineering. I know it's a bit of a mouthful, but MPLS-TE allows you to set up tunnels between two end points, and again, route traffic down the lowest latency path. This is a bit more specialised though; you either need a good ISP that can do this for you, or you need to invest in some half decent routers and set it up for your self. You can run MPLS over GRE between to remote routes and set this up.

Solution Four

One possible idea is that you can use multiple VPNs or tunnels between the two ends of your network and introduce per-packet load balancing (round robbin'ing) across all three links. You can do this with Cisco and Juniper routers for example, or again, if you use Linux, you can use a package like teql, or buy a hardware device like a FireBrick. If all the links have similar latencies (so you aren't mixing ADSL, 3G and fibre) this would work. It generally isn't advised as out of order packets can cause problems in applications, so no mixing of latency style links as I just mentioned. But, I do have it enabled across a couple of links now, and did at my last place, and they are problem free. I'm sure a packet may arrive out of order every now and again, but it must be very rarely, as I don't ever notice any problems.

Solution Five

You mentioned the latency being related to your application. Since I don't know what your application is or how it works, there may always be the outside chance that there is some sanity in me recommending you do something about this at the application layer. I mean, re-code the application to handle higher latency links. Shit happens, even if you implement a magical low latency network solution, shit happens, latency will rise, plan for the worse, code it into your application to handle such undesirable scenarios should the worst happen (faulty planning and all, FMEA etc).


This really is probably a really bad method for doing this seeing as you will just saturate the links with traffic. If I am correctly understanding this then VPN/tunnel software isn't really what you want either as that is more of a method for securing traffic coming in to your internal network or remote access.

It sounds to me like you need to purchase a hardware device that allows for link aggregation and it will smartly decide which port your outbound traffic would need to route. Many current firewalls can do this or you can probably use a Cisco device and use BGP.

  • 'link aggregation' sounds like a promising google term, thanks. – chillitom Apr 8 '13 at 19:29

There isn't any way to "multicast" unicast packets the way you suggest. Here are some alternatives:

Try running a recent build of OLSRD, such as the OpenWRT OLSRd builds on each WAN interface and the Debian or Ubuntu OLSRd on the interfaces of the multi-homed host. OLSRD configured with LinkQualityLevel set to 2 should result in use of the lowest latency ISP link, although not the lowest latency to any particular Internet destination other than the next hop to the ISP.

If the destinations are known ahead of time or you have a good set of representative destinations, you could write a daemon in Python or Perl that periodically tests the ping times to each destination. You would run the daemon on each WAN interface (probably meaning each router facing an ISP) and query the ping data from the multi-homed host using a client program that changes the default route on the multi-homed host according to the best ping time. This will probably take you fifty to a hundred hours of programming to write and debug.

If you use BGP then you will need to register an ASN and ask your ISP's to configure their routers to speak BGP with your. This is probably not feasible for you unless you register a large block of IP addresses.

The type of routing you are trying to do is gnerally called Optimized Link State Routing.

  • Thanks - sounds rather involved and perhaps a little beyond my ability though I'll read up on OLSR. – chillitom Apr 8 '13 at 19:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.