1

Imagine I have a computer with two slow cheap internet connections from ISP A and B. I also have a VPS in a datacenter with very high infinite bandwidth.

I can make two VPN's. One from A to VPS and one from B to VPS. I can aggregate the two "virtual" tun interfaces, install a DHCP on my VPS and have a bandwidth that is the sum of the one possible with A or B alone.

By monitoring the bandwidth and adapt the load (for instance with ifenslave mode 5 or 6), everything could be balanced in a well better way that it would be possible with simple RR load balancing. 

                 +- TUN: A ---- VPN ------+
                 |                        |
 Host - aggTun --|                        +-- VPS - DHCP--- WWW
                 |                        |
                 +- TUN: B ---- VPN ------+

However, this seems too good to be true and I strongly believe that this could have a bad impact on TCP connections (especially if the delays with A and B are differents). Do someone know what problems could arise and how could I solve them with a Linux environment?

Thank you very much and have a nice week

Improve this question
1
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can provide and accept your own answer.
    – Ron Maupin ♦
    Feb 19, 2018 at 4:36

1 Answer 1

Reset to default
3

The basic problem with this, and every other aggregation scenario, is how you will accomplish the load sharing. By that I mean, how will the host determine which link to use to forward the packet out of? There are essentially two choices:

  1. Per-packet load sharing. The host/router will send packets alternating between the two links. As you mention, this can cause serious impacts on throughput if packets arrive out of order due to unequal delays.
  2. Per-flow balancing. The host/router will send all packets for a particular flow down one path. The host/router uses a hashing algorithm to determine which path to take. Usually the algorithm uses some combination of layer 2, 3, and 4 information to pick which path to use. The problem here is that depending on the environment, the flows can be very unbalanced. For example, if you use IP information, and you talk to one particular host (your VPS endpoint, for example), you will use only one link. You will have to choose your algorithm carefully, depending on your particular usage.

Also, don't forget that you have to do this on both ends of the link. It's not much benefit if your outgoing traffic is shared across multiple links but the inbound traffic uses only one.

Improve this answer
4
  • Thank you very much for your clear answer. I was more interested to the per-packet approach. Do you know if there are conditions where this should work pretty well? (Is two internet connections with delay 10+-5ms and 20+-10ms also problematic). Do you know if there are algorithmic solutions to this problem (like switching to per-flow when delay is very different between links)? Have a nice day
    – Alexis Clarembeau
    Jun 12, 2017 at 12:50
  • Per-packet is almost never used because of the variable delays -- which you have no control over.
    – Ron Trunk
    Jun 12, 2017 at 12:57
  • Ok so I don't understand how this feature works? zeroshell.org/load-balancing-failover/#vpn-bonding It seems to do layer 2 round robin. Is this a bad design or is there something I didn't catch up? Thank you
    – Alexis Clarembeau
    Jun 12, 2017 at 14:40
  • I have no experience with it, but the issues I described still apply. Also, remember that a flow will use only one link. So the maximum throughput for any one flow will not exceed the single link bandwidth.
    – Ron Trunk
    Jun 12, 2017 at 14:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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