Multipath routing on a Raspberry Pi 2(whizzy.org)
whizzy.org
Multipath routing on a Raspberry Pi 2
http://www.whizzy.org/2015/05/multipathrouting-rasppi2/
4 comments
Very cool project. One downside to this approach is that each tcp connection cannot use more than one link's bandwidth. I've been meaning to try this with a multipath VPN to work around that issue but haven't had the time yet.
I tried this[0] and successfully round-robin packets in a single stream. Problem was that the two links had different latencies and Linux has no tolerance for out of order packets. Instead, it would cause a huge number of retransmissions.
[0] https://github.com/erjiang/tuntuntun
[0] https://github.com/erjiang/tuntuntun
Interesting, even so was it a net win?
It looks like tuntuntun is pretty basic, my thought was OpenVPN with null encryption over MPTCP. But the combination would obviously have a lot more overhead than that.
It looks like tuntuntun is pretty basic, my thought was OpenVPN with null encryption over MPTCP. But the combination would obviously have a lot more overhead than that.
I think it would have been nice to have bit more discussion on the results, both on performance and fault-tolerance points of view. Getting 10MB/s on 2x70Mbps lines sounds like the RPi is bottlenecking quite heavily.
I haven't added any fault tolerance. Should be fairly easy to detect if a route is unavailable and re-write the routing table. And yes, I expect the Pi is still a bottleneck.
Is there any embedded hardware that can handle 140Mbps line speed without being maxed out?
Something like the Cubox-i/Hummingboard should do the trick. It has a beefier CPU and a gigabit ethernet interface that isn't attached via USB like the one on the Pi/Pi2.
[deleted]
> I don’t really get how, in the case of an HTTP conversation (or flow) which is connectionless, all the packets in the conversation get marked the same.
What do you mean? HTTP is stateless, not connection-less. This is probably related to:
> Although HTTP is a connectionless protocol this change of IP address did seem to freak some services out.
Maybe what you saw is a single request being split into multiple packets taking different routes then different source address from what you said. I have no idea how such setup could work in practice.