OVH announced today its
OverTheBox project, which is
basically a link-aggregation solution for Internet access links.
Analysis of the technology
Foreword on link aggregation
First of all, aggregating Internet access links has nothing to do with
classical
link aggregation (also
called bonding or trunking). This is a much harder problem, because the
access links typically have very diverse characteristics, in terms of
latency, capacity, and packet loss.
Think of aggregating a DSL line, a FTTH line and a satellite connection.
If you simply send packets in a round-robin fashion, you will basically
get the worst out of each link: packets will be heavily reordered, causing
TCP to fall apart. The latency of a flow will basically be the latency of
the worst link. Additionally, packet loss on any of the links will
heavily impact the whole flow.
Technology used in OverTheBox
For OverTheBox, the main technology used by OVH is
Multipath TCP, often abbreviated as MPTCP.
Multipath TCP basically allows to split a TCP flow across multiple paths,
providing redundancy and increased throughput. It does so in a clever
way: each subflow runs TCP independently, providing congestion control and
packet loss recovery independently for each path. A scheduler decides on
which path to send data, based first on the RTT of each path (lower RTT is
preferred) and moving to the next path when the congestion window is
filled.
While Multipath TCP was not initially designed for link aggregation, it
implements all necessary ingredients to do this efficiently. However, it
only works for TCP traffic, and requires that both ends of a TCP
connection know how to speak Multipath TCP. This is actually by design:
end hosts are in the best position to discover paths and their associated
characteristics (the typical use-case being a
smartphone with both 4G and Wi-Fi).
OVH used the Linux implementation of Multipath TCP, and
based its distribution on OpenWRT,
using an existing patch.
Since Multipath TCP is not yet widely deployed in end-hosts, a
link-aggregation solution based on Multipath TCP must be transparent for
the devices behind the aggregation point. To do this, OVH used a
classical solution based on a VPN. The idea is to run a VPN protocol able
to tunnel data over TCP, such as OpenVPN. This way, provided both the VPN
client and servers and MPTCP-compatible, the VPN will automatically use
all available paths, with associated load-balancing and failover benefits.
OVH
apparently decided
to use vtun, which I had never heard of
before. That being said, there are also
references to OpenVPN
in the code, so I am not sure which one they use.
In addition to that, OVH seems to use a transparent SOCKS proxy,
shadowsocks. The goal is to avoid
TCP over TCP encapsulation, which is
notoriously a bad idea.
Thanks to the SOCKS proxy, TCP connections from local clients are
terminated locally, and new TCP connections are established from the other
end of the tunnel towards the destination. This way, any packet loss on
the path towards the destination does not trigger retransmissions inside
the VPN.
For UDP traffic, I am not sure whether it also goes through the SOCKS
proxy (this is possible with SOCKS5, but would be somewhat useless in this
case) or travels directly on the VPN.
Finally, as a last note, OVH decided to shoot IPv6 in the head by
completely ignoring AAAA DNS requests
in their local DNS resolver. This is a ugly hack, and sounds like a quick
and dirty fix for an issue discovered just before the initial release. My
guess is that either shadowsocks does not support IPv6, or the IPv6
connectivity provided by some of the access links interferes with the
operation of the OverTheBox box. I do hope that this is a temporary fix,
because crippling IPv6 like this will certainly not help its deployment.
By the way, Multipath TCP of course fully supports IPv6.
By the way, this analysis is based on a rather quick look at the source
code, and my own experience. If you think I made a mistake, feel free to
send me an email (contact at the domain name of this blog).
Impact of OverThebox
As such, this project from OVH merely assembles existing components. It
introduces nothing new, except maybe a nice web interface (which is
actually non-negligible in terms of user impact).
And indeed, technically speaking, people have already been doing the exact
same thing for a while: Multipath TCP for link aggregation, a VPN such as
OpenVPN for encapsulation, and a transparent SOCKS proxy to terminate
client TCP connections before entering the tunnel. See for instance
this mail on the mptcp-dev mailing list.
But this is, to my knowledge, the first open off-the-shelf solution
providing an easy-to-use interface. What's more, OVH
released the code, and the solution should work
just fine with your own VPN server: it does not force you to use OVH
services, which is extremely nice.
This is in huge contrast with existing proprietary solutions for the same
problem, such as the products sold by
Peplink. Their
business model is to sell you the hardware and the service, with
associated licensing fees. Since the protocol is proprietary, you are
forced to use the Peplink VPN servers (even though they seem to offer to
deploy VPN servers in the cloud, that you can manage through their
provided interface). OverTheBox is likely to have an effect on this kind
of proprietary businesses. On the other hand, providers like Peplink can
(and probably should) make a difference by providing custom support for
companies, something that OVH probably won't do.
Finally, let us note that there are other solutions to the original
problem, such as MLVPN (which is not
based on Multipath TCP). But OVH clearly has enough weight to make a huge
impact with its nice, integrated solution.
Cet article est en français, puisqu'il est susceptible d'intéresser
principalement des lecteurs français.
En France, SFR fournit de l'IPv6 sur ses accès ADSL et fibre : c'est très
bien ! En revanche, il ne s'agit pas d'une connectivité IPv6 native
(probablement parce que le réseau d'accès ne fonctionne qu'en IPv4 pour le
moment). La connectivité IPv6 est fournie par un tunnel monté au-dessus
d'IPv4. Lorsqu'on utilise la box de SFR, c'est transparent : la box monte
le tunnel elle-même, et on ne voit rien (à part une MTU un peu faible).
En revanche, si on remplace la box par un routeur à soi (par exemple, sous
OpenWRT), il faut monter le tunnel soi-même si on
veut profiter de l'IPv6. Ce n'est pas si évident à mettre en place
(techniquement, c'est de l'IPv6 sur L2TP sur UDP sur IPv4, avec du PPP et
du DHCPv6 pour faire bonne mesure). Le but de cet article est de
détailler la mise en place du tunnel IPv6 sous OpenWRT, sachant que la
configuration est adaptable pour d'autre systèmes GNU/Linux ou BSD.
Configuration IPv4
Obtenir une adresse IPv4 avec un routeur branché sur l'ONT SFR a déjà été
beaucoup
documenté :
il suffit de faire du DHCP avec un vendor-id spécifique. Sous OpenWRT, ça
se traduit par :
# /etc/config/network
config interface 'wan'
option ifname 'eth0' # à adapter
option proto 'dhcp'
option vendorid "neufbox-BypassedNeufBox-DirectConnectionToFTTH-toto@nowhere.xxx"
Le vendorid doit en fait simplement commencer par "neufbox", mais indiquer
que ce n'est pas une Neufbox semble recommandé, des fois que le support
technique passe par là (même si en pratique, le support de SFR est plutôt
du genre « C'est bizarre, votre connexion Internet n'a pas l'air de
fonctionner. » « Si si, je vous assure, ça marche très bien. » « Ah
bon. »).
Analyse du tunnel
La première étape est de déterminer l'adresse du LNS (L2TP Network
Server), qui est le routeur avec lequel le tunnel L2TP est monté. Pour
monter le tunnel, il y a ensuite deux niveaux d'authentification :
- une authentification pour monter le tunnel L2TP lui-même. C'est
simplement un mot de passe codé en dur, le même pour toutes les
Neufbox : 6pe
- une authentification PPP, dont le couple login/mot de passe est
spécifique à chaque client SFR.
Il faut donc connaître le login et le mot de passe PPP. Fort
heureusement, la Neufbox envoie ceux-ci en clair lorsqu'elle établit le
tunnel.
Pour récupérer toutes ces informations, il suffit donc d'écouter le trafic
de la Neufbox juste après son démarrage.
Écouter le trafic de la Neufbox
Pour une connexion fibre, c'est très simple, il suffit de se mettre entre
la Neufbox et l'ONT. Voir
cet article
pour plus de détails.
Le plus simple est probablement d'utiliser une machine sous Linux avec
deux interfaces réseau (par exemple, un laptop avec une carte Ethernet en
USB). Une interface est branchée sur le port WAN de la Neufbox, l'autre
est branchée sur l'ONT. Ensuite, on bridge les deux interfaces :
# brctl addbr br0
# brctl addif br0 eth0
# brctl addif br0 eth1
# ip link set eth0 up
# ip link set eth1 up
# ip link set br0 up
# sysctl -w net.ipv4.ip_forward=1
Il faut aussi s'assurer que le firewall autorise le forwarding de paquet.
En cas de doute :
# iptables -P FORWARD ACCEPT
# iptables -F FORWARD
Il ne reste plus qu'à regarder le trafic qui passe :
Adresse du LNS
Sur ma connexion fibre, l'adresse du LNS avec lequel la Neufbox établit le
tunnel est 109.6.3.95. Il se peut que le serveur soit différent selon
la région, ou d'autres critères. Par exemple, dans la
capture faite par Marin,
le LNS est 109.6.1.72. Un autre utilisateur
indique
que chez lui, le LNS est 109.6.4.36.
Le plus simple est donc d'écouter le trafic et d'utiliser le même LNS que
votre Neufbox.
Login et mot de passe PPP
Le login PPP est manifestement de la forme
dhcp/XX.XX.XX.XX@YYYYYYYYYYYY, où XX.XX.XX.XX est l'IPv4 publique de
l'accès Internet, et YYYYYYYYYYYY est l'adresse MAC du port WAN de la
Neufbox, sans les :.
Pour le mot de passe PPP, il ne semble pas y avoir de logique
particulière. Il s'agit visiblement d'une chaîne de 16 caractères dans
l'alphabet [A-Z0-9] (alphanumérique avec uniquement des lettres en
majuscule).
Configuration sous OpenWRT Barrier Breaker
Tout est dans la documentation d'OpenWRT. En adaptant pour SFR, ça donne donc :
# /etc/config/network
config interface 6pe
option proto l2tp
option server '109.6.3.95' # à adapter
option username 'dhcp/XX.XX.XX.XX@YYYYYYYYYYYY'
option password 'ZZZZZZZZZZZZZZZZ'
option keepalive '6'
option ipv6 '1'
config interface 'wan6'
option ifname '@6pe'
option proto 'dhcpv6'
Ainsi que :
# /etc/xl2tpd/xl2tp-secrets
* * 6pe
Et hop, ça juste marche (autoconfiguration sur le LAN, règles de firewall,
etc). Magique, OpenWRT, non ? :)
Configuration pour d'autres OS (GNU/Linux, BSD)
La méthode pédestre, en configurant xl2tpd puis pppd, est également
documentée sur le wiki OpenWRT.
Quelqu'un a également
essayé avec un EdgeRouter Lite,
et a fini par
obtenir une config
pas super propre, mais qui marche.
Notons que le firmware des Neufbox est disponible :
http://neufbox.alwaysdata.net/.
Notamment, il est possible de récupérer la configuration de xl2tpd et
pppd pour être sûr d'avoir la même.
Performance
Le tunnel est monté sur un routeur
Netgear WNDR3800,
sous OpenWRT Barrier Breaker rc3. La connexion est une fibre SFR 1G/200M.
Les tests sont fait depuis un laptop branché en filaire, vers
ipv6.intuxication.testdebit.info, qui est à environ 10 ms, avec les
commandes suivantes :
# Download
wget -O /dev/null http://ipv6.intuxication.testdebit.info/fichiers/1000Mo.dat
# Upload
curl -o /dev/null -F 'filecontent=@1000Mo.dat' http://ipv6.intuxication.testdebit.info
Chaque commande est lancé plusieurs fois en parallèle si nécessaire (pour
remplir le tuyau), et le débit instantané est relevé sur le routeur.
J'obtiens les débits IP maximaux suivants :
- 80 Mbits en upload
- 105 Mbits en download
En upload, un top sur le routeur montre que le CPU passe 100% du temps à
traiter des interruptions logicielles (sirq). En download, l'utilisation
CPU est plutôt de l'ordre de 90%.
Pour comparer, en IPv4 dans les mêmes conditions, j'obtiens 180 Mbps avec
85% d'utilisation CPU sur le routeur, le résultat étant identique en
upload et en download. Visiblement, encapsuler des paquets L2TP est donc
plus coûteux que de les décapsuler.
Conclusion
Cet article décrit comment utiliser la connectivité IPv6 fournie par SFR
lorsqu'on remplace la Neufbox par un routeur à soi. On peut avoir envie
d'utiliser d'autres services (téléphone, télévision, etc), mais plein de
gens ont documenté comment faire : voir les liens ci-dessous.
Liens