Feb 13, 2019

Teaching routing and network security — Daily log

Today I have been mostly teaching or preparing upcoming courses. I also had a nice lunch discussion with colleagues on DNS and the role of transaction IDs, but that story will have to wait until tomorrow!

Teaching routing

I gave another networking course for first year's students today. This was the first practical session where they actually had to plug some cables around: you can imagine the excitement but also the mess! To make things even easier, the course was in a new networking lab I had never been before, so I had to improvise with the hardware lying around.

The students learnt how to configure network interfaces (ifconfig, route & netstat on FreeBSD), and they had to use their prior knowledge of packet capture and ping to troubleshoot when things didn't work as expected. They had to form a simple "chain" topology (shown below) with two subnets, and the computer in the middle needed to be configured as a router. They needed to figure out that static routes were required on both edge computers, so that they knew how to reach the remote subnet through the router. Finally, they looked in details at the behaviour of ARP and the scope of MAC addresses.


Network security course

I then prepared an upcoming practical session on network security with a colleague working for Quarkslab. I already have a good part of the course ready from last year on firewalling and advanced uses of iptables (including compiling custom BPF programs!). My colleague wants to add a part where students will practice ARP spoofing, so we looked at how to integrate that with the existing content.

Interestingly, he showed me how to automate virtual machine generation using Packer. This should be really helpful for future teachers in this course: they will be able to easily customize and rebuild the virtual machine images used by the students! Last year, I installed and configured the virtual machine manually, which makes it hard to update it or apply the same modifications to a new VM image.

Feb 12, 2019

Multipath scheduling simulation — Daily log

Multipath scheduling

Today I mostly worked on my current research project, a simulator of multipath multistream scheduling algorithms.

Multipath scheduling is needed when you want to transmit data over several concurrent paths: which piece of data should be sent on which path? This problem has been made visible by Multipath TCP, since the Linux implementation includes several schedulers that can be changed at runtime. Several new schedulers for MPTCP are being proposed in the academic literature every year: the original LowRTT and its evaluation, Delay-Aware Packet Scheduling, BLocking ESTimation, Earliest Completion First, and many others.

All these algorithms mostly differ in the objective function they try to optimize or in assumptions that can be made for specific data flows (e.g. video streaming traffic). However, they all adopt the semantic of TCP, which transports a single flow of data. I am interested in extending the problem for several streams (have you heard of QUIC?) that need to be scheduled on multiple paths. Instead of a single optimisation problem, you now end up with several concurrent streams, where each stream wants to complete as soon as possible!

Writing a simulator

The goal of my simulator is to quickly obtain an intuition on the behaviour of scheduling algorithms: it provides a graphical and animated visualisation of what's going on over time. The simulator also allows for more in-depth exploration, for instance comparing the completion times of streams for different scheduling algorithms.

Below is a screenshot of the current simulator: it is not very pretty because that's not its goal! The streams are represented by vertical bars whose size equals the amount of data remaining to be transmitted, and the darker parts represent in-flight data. Below are two paths, each modelled as a packet queue with a constant-rate service (link capacity) and a fixed propagation time.

Screenshot of the current simulator

I am writing this simulator in Python thanks to salabim: this is a really well designed, easy-to-use and well-documented simulation framework. I had an initial simulation prototype working in less than one day, and it took only an additional day to add graphical visualisation. One of the reasons it's so easy to use is thanks to Python: I didn't want to spend days implementing complex algorithms in NS-3, even though it would be much more realistic. At the same time, salabim is reasonably fast once you disable logging and visualisation.

After working with salabim some more, I did find some limitations: the programming style around salabim is fine for small simulations, but quickly becomes a mess for larger projects. All examples use lots of global variables, which encourages you to write all your code in one file (after all, this is how salabim itself is developed with its 15k lines in a single file...)

Feb 12, 2019

Introducing daily logs

As you may have seen, I am not very good at writing regular articles here! I often get ideas for an article; sometimes I am motivated enough to actually start writing it; but then, most of the time, I never finish the article.

With my third and (hopefully) last year of PhD going full steam, and still lots of involvement in community networks, I decided to change my writing approach and start publishing a daily log of what I do.

What should you expect?

Content-wise, I will mostly talk about networking, of course!

More precisely, I will cover the following activities:

  • my research activities: what I'm currently working on, interesting discussions with colleagues, conferences I attend, etc;
  • my teaching activities, also mostly related to networking;
  • my non-profit activities in Grenode, Rézine, Fédération FDN and other organisations related to community networks.

I may also cover other activities that are not directly related to networking, for instance Openstreetmap, the GCC compile farm, contribution to various free software, and so on.


Since this is a new exercise for me, I welcome all kind of feedback! You can reach me on Mastodon or by email (root at <this blog's domain name>).

Feb 11, 2018

Etat des points d'échange Internet en France

Qu'est-ce qu'un point d'échange Internet ?

Un point d'échange Internet, ou IXP (Internet eXchange Point), c'est un endroit où plusieurs opérateurs réseau s'interconnectent pour échanger du trafic.

De façon simplifiée, il faut voir ça comme un gros switch Ethernet sur lequel chaque opérateur réseau va se brancher, à l'aide d'un câble RJ45 ou une fibre optique. Oui oui, on parle bien du même genre de switch Ethernet que vous avez sûrement chez vous pour brancher vos ordinateurs, juste un peu plus rapide et fiable (et donc plus cher).

Dans la réalité, la plupart des IXP ont une architecture plus complexe, avec plusieurs switches dans différentes baies d'un datacenter, et des points de présence ("PoP" pour "Point of Presence") dans plusieurs datacenters, reliés entre eux avec des fibres optiques. Mais le principe reste le même.

Analyse des points d'échange Internet

Récemment, le centre de recherche CAIDA a publié un jeu de données sur les IXP. Du coup je me suis dit que j'allais regarder ce qu'il y a dedans !

C'est intéressant d'avoir une vision globale du paysage des IXPs, parce qu'ils dessinent une grande partie de l'architecture physique d'Internet (qui est, je le rappelle, justement une interconnexion de réseaux).

Regardons d'abord quelles informations sont disponibles :

$ tail -n +2 ixs_201712.jsonl | jq 'select(.name == "France-IX")'

ce qui donne :

  "name": "France-IX",
  "city": "Paris",
  "country": "FR",
  "sources": [
  "alternatenames": [
    "Mix Internet Exchange and Transit",
    "France Internet Exchange "
  "geo_id": 2988507,
  "region": "Paris",
  "pch_id": 74,
  "url": [
  "pdb_id": 68,
  "pdb_org_id": 147,
  "alternativenames": [
    "French National Internet Exchange IPv6"
  "ix_id": 377,
  "org_id": 23

On peut déjà remarquer plusieurs choses :

  1. les données viennent de différentes sources, comme indiqué ici : PeeringDB, la page Wikipédia sur les points d'échanges, PCH, et bgplookingglass.com.

  2. c'est un peu le bazar... En recoupant les différentes sources, CAIDA a associé des points d'échange qui n'ont rien à voir les uns avec les autres (FranceIX, MIXT, FNIX6) ! Là encore, la méthode utilisée est décrite sur la page du jeu de données.

Ensuite, on voit qu'on peut facilement filtrer par pays :

$ tail -n +2 ixs_201712.jsonl | jq 'select(.country == "FR") | .name' | wc -l

Il semble donc y avoir 42 IXPs en France (modulo les doublons et erreurs), ça ne s'invente pas :)

Les points d'échange en France

Après nettoyage manuel des doublons et des vieux IXPs qui ont disparus, il reste environ 21 points d'échange en France, ce qui reste un nombre conséquent !

Contrairement à ce qu'on pourrait penser, il n'y a que 4 points d'échanges actifs à Paris : FranceIX, FR-IX, Equinix et SFINX (ainsi que Hopus, qui n'est pas vraiment un IXP). Tous les autres (environ 13 actifs) sont donc soit en région, soit en outre-mer.

C'est étonnant quand on sait que l'Internet français est ultra-centralisé sur Paris (heureusement, ça s'améliore depuis quelques années, grâce notamment à Rézopole). D'ailleurs, il y a historiquement eu beaucoup de points d'échange à Paris, mais la plupart sont morts ou ont été absorbés.

On peut analyser cette rareté relative des points d'échanges à Paris, ainsi que leur prolifération en région et en outre-mer, de plusieurs manières :

Les IXP permettent de développer le territoire local

Les points d'échange sont importants pour développer le réseau sur le territoire local, puisqu'ils permettent aux opérateurs locaux de s'échanger du trafic directement, sans passer par les gros noeuds d'interconnexion comme Paris, Londres ou Amsterdam. Ça permet de réduire la latence et le coût, et de moins dépendre d'infrastructures qui deviennent critiques de par leur concentration (par exemple TH2 à Paris concentre une grosse partie des interconnexions de l'Internet français...). En somme, décentraliser et relocaliser le réseau, ce qui a des vertus non seulement techniques et économiques, mais également humaines : cela permet aussi de relocaliser les compétences techniques.

C'est d'autant plus important en outre-mer ! Imaginons un abonné à La Réunion qui veut accéder à un serveur hébergé également à La Réunion. Sans point d'échange local, sa requête passera par une fibre sous-marine, parcourera probablement quelques centaines ou milliers de kilomètres, et reviendra par le même chemin...

Du coup, il paraît logique que de plus en plus de régions développent des points d'échanges Internet en local. Par exemple, Rézopole est financé en partie par la Région Rhône-Alpes pour s'occuper de LyonIX et GrenoblIX.

Deux IXP sur un même territoire se font concurrence

Une autre explication, c'est qu'il y a peu de place pour plusieurs points d'échanges sur un même territoire. En effet :

1) pour un opérateur, se connecter à un point d'échange représente un coût majoritairement fixe, qui ne dépend que très peu de la quantité de trafic échangée (contrairement à du transit).

Il faut payer le cablage dans le datacenter, puis le port sur le switch du point d'échange : ce dernier coût est souvent lié à la capacité du port (1 Gbit/s, 10 Gbit/s, etc) et non à son utilisation réelle.

Du coup, si un opérateur a le choix entre 5 petits points d'échanges qui permettront au total d'échanger 400 Mbit/s, et un seul point d'échange plus gros sur lequel il pourra écouler ses 400 Mbit/s, il aura tendance à privilégier le plus gros.

Bien sûr, il y a d'autres critères de choix (redondance, présence dans plusieurs datacenters, tarifs, qualité du service) qui font que quelques points d'échange peuvent cohabiter sur le même territoire, mais ça limite quand même fortement le potentiel d'avoir des dizaines d'IXP au même endroit.

2) l'effet de réseau joue : comme pour beaucoup de systèmes en réseau, plus un point d'échange possède de membres, plus il devient intéressant de s'y connecter. En effet, plus de membres présents signifie d'avantage de trafic échangé potentiel, pour le même coût fixe.

Cet effet a naturellement tendance à faire grossir les gros IXP et à faire disparaître les petits, et finit généralement par converger vers un unique IXP sur un territoire donné (sauf à Paris, où la demande est suffisamment forte et les datacenters suffisamment nombreux pour permettre à quelques IXP de co-exister ; on peut également voir des IXP avec des politiques très différentes co-exister, par exemple un IXP académique et un IXP commercial)

Notons qu'il est quand même possible d'aller à contre-courant de cet effet de réseau. Par exemple, le point d'échange SIX à Seattle a un modèle financier particulier : les opérateurs payent uniquement des frais d'accès au service, et ensuite ils peuvent échanger du trafic sur le point d'échange sans frais récurrents ! Le MINAP à Milan a un modèle similaire, à une plus petite échelle, où même les frais d'accès sont offerts (mais pas les frais de raccordement).

Plus généralement, pas mal de points d'échange (notamment les petits) sont sponsorisés par des acteurs du marché télécom local, qui se rendent bien compte des intérêts techniques et politiques de l'interconnexion locale : faible latence, contrôle de l'infrastructure, indépendance. En outre, les membres du point d'échange représentent des clients potentiels, à qui les sponsors du point d'échange pourront ensuite vendre de l'hébergement ou du transit !

La qualité de service d'un IXP doit être irréprochable

Lorsqu'un point d'échange commence à grossir, il se pose forcément la question de la qualité du service.

Tant que le point d'échange connecte le FAI associatif de la ville d'à côté et les 2 petites boîtes du coin, les coupures n'ont pas un impact énorme. Mais lorsque des centaines de membres sont connectés, certains de grosse taille, la moindre panne peut impacter des millions d'utilisateurs finals.

Par ailleurs, pour les opérateurs, cela représente du travail de maintenance et de suivi, qui peut s'avérer plus lourd et coûteux que le bénéfice d'être connecté au point d'échange.

Les opérateurs ont donc naturellement tendance à privilégier les points d'échange bien gérés et fiables. En réponse, les points d'échanges qui veulent subsister et grossir se donnent les moyens d'assurer un service fiable : astreinte 24/24, architecture technique redondée, matériel de pointe, etc.

Soyons clair : gérer un point d'échange de taille raisonnable n'est pas facile, puisque cela demande à la fois une forte expertise technique (matériel spécialisé, architecture distribuée sur plusieurs sites) mais il y a aussi une forte composante relationnelle : la structure opérant le point d'échange doit interagir avec des centaines de structures hétérogènes, qui souhaitent toutes avoir un service fonctionnel sans que ça ne leur demande trop de temps de gestion et d'entretien.

On assiste donc à la fois à un regroupement des compétences, via des structures comme Rézopole pour éviter de tout réinventer de zéro à chaque IXP, mais aussi à un fort partage de connaissance et d'expérience à plus large échelle, avec le RIPE et EuroIX.


L'ecosystème des points d'échange n'est pas un sujet nouveau, mais il reste fascinant parce qu'il entrelace des problématiques techniques et des relations entre structures parfois très différentes. Il illustre bien le modèle distribué et pair-à-pair qui a fait d'Internet un succès. On peut par ailleurs constater que certains points d'échange sont gérés comme un bien commun !

Si le sujet vous intéresse, le RIPE NCC maintient un blog collaboratif très actif sur des sujets liés à Internet en Europe, notamment les IXP et le peering. Toujours sur RIPE labs, Uta Meier-Hahn écrit régulièrement des articles passionnants sur les enjeux des interconnexions entre opérateurs.

Sep 24, 2015

OVH's OverTheBox: Internet access link aggregation using Multipath TCP

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.

Aug 22, 2014

Utiliser IPv6 chez SFR, sans la Neufbox

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 :

# tcpdump -n -v -i eth0

Adresse du LNS

Sur ma connexion fibre, l'adresse du LNS avec lequel la Neufbox établit le tunnel est 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 Un autre utilisateur indique que chez lui, le LNS est

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 '' # à 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.


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.


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.


Jul 23, 2014

Back to business

So, writing a blog again. I had one, years ago. Hosted at home, like this one (though it was behind DSL at the time, FTTH wasn't as widespread as it is now). It was about free software, programming languages (especially functional), and maybe already some bits of networks. I remember writing a long post after discovering network neutrality for the first time, thanks to a talk by La Quadrature du Net.

This new blog will be mostly about networks, and how you can use them for fun and for saving the world (yes, this is overly ambitious). Overlay networks, wireless mesh networks, routing protocols, free software, free hardware, Do-It-Yourself ISPs, community-owned networks... And probably other stuff I forgot.

As a general rule, ideas and principles behind networks will be discussed, and not only "how to do this particular thing with that particular software". I strongly believe that networking is not hard, provided you understand what you are doing, which is often the most difficult part. Once you know what you are doing, it is relatively easy to use the available networking tools, or to create new ones. That being said, I will definitely provide configuration examples when they are non-obvious and/or use some obscure functionalities.

By the way, this blog will not show photos of big Cisco routers, or explain how to do X with insert your favourite prioprietary router OS here.

Hopefully, this blog will stay up longer than the previous one. Enjoy reading, and happy hacking!