Projet agregation » Historique » Version 27
Version 26 (Yanick Delarbre, 27/11/2011 19:20) → Version 27/225 (Yanick Delarbre, 27/11/2011 19:21)
h1. Projet agregation
* [[Bibliographie du projet]]
* [[L'installation de gitolite]]
* http://pad.rhizome-fai.net/U7HSgxYvDM | Le code du tunnel tun réalisé avec python
* http://pad.rhizome-fai.net/TS2HBLkTnN | Spécification de l'iperf (de quel manière on détecte la capacité d'un lien de manière opportuniste ? Monitoring ?)
* http://lists.tetaneutral.net/listinfo/projet-agregation
* http://chiliproject.tetaneutral.net/issues/16
h2. Prototype v1
http://lists.tetaneutral.net/pipermail/projet-agregation/2011-November/000023.html
h2. Test de tunproxy.py
On utilise "tunproxy.py":http://www.secdev.org/projects/tuntap_udp/files/tunproxy.py. Entre 2 machines
* client-adsl (une machine chez nous)
* gateway (la VM)
h3. Sur la gateway (= VM ttn)
Démarrer le tunnel, il crée lui-même une interface _toto0_ (détruite à la sortie).
<pre>
./tunproxy.py -s 6000
ifconfig toto0 10.0.0.1/24 mtu 1468
</pre>
La MTU est calculée comme suit :
MTU de l'iface virtuelle = MTU de l'iface physique - taille_max(header IP) - taille(header UDP)
MTU de l'iface virtuelle = 1500 - 24 - 8
http://www.commentcamarche.net/faq/7185-introduction-au-mtu
h3. Sur le client
<pre>
./tunproxy.py -c rhizome-fai.tetaneutral.net:6000
ifconfig toto0 10.0.0.2/24 mtu 1468
</pre>
Tout le trafic vers les adresses en 10.0.0.x passera par le tunnel.
* http://lists.tetaneutral.net/listinfo/projet-agregation
* http://chiliproject.tetaneutral.net/issues/16
Un test de perf sur un téléchargement d'un fichier de 40Mio donne :
* avec tunnel : 909kb/s
* sans tunnel : 942kb/s
h1. Petits points techniquesâ¦
h2. Que mesure iperf et comment (en UDP) ?
Iperf mesure le débit du client vers le serveur (dans un seul sens). En UDP, il envoie à une vitesse nominale (par défait 1M). Le résultat donné par le client n'est pas une mesure mais correspond à cette vitesse nominale. *Seul le _server repport_ correspond à la "vraie" mesure.*
La saturation d'un lien générant des pertes, pour mesurer les pertes liées à la qualité du lien (et non à sa capacité), il faut demander au client d'émettre un peu en-dessous de la vitesse à laquelle peut recevoir le serveur.
h2. Quelques outils réseaux bien pratique
* tcpdump | http://openmaniak.com/fr/tcpdump.php
<pre bash>
tcpdump -D #Interfaces réseaux disponibles pour la capture
tcpdump port 80 -i eth0 -w capture.log #Enregistre le trafic Web vers le fichier capture.log pouvant être ouvert avec Wireshark
tcpdump icmp #Affiche tout le trafic associé au protocole icmp
</pre>
* ping | http://www.bortzmeyer.org/ping-taille-compte.html
** Permet de tester un problème de MTU grâce à l'option -s de ping permettant de fixer une taille de paquet
* hping3
<pre bash>
hping --syn -p 80 --data 1200 10.0.0.1 #Envoie de paquet tcp syn sur le port 80 de taille 1200
</pre>
*tracepath* pour découvrir le PMTU
h1. TODO étapes suivantes
* Chercher relation entre variations de latence et saturation de lien. Concrètement, être capable de détecter *l'évènement "mon lien est saturé"* et de mémoriser la capacité max. du lien
* Finir de lire/comprendre le code de Fernando (linkagreg)
* Lire/comprendre le bout de script python de Laurent (multi-UDP pour contourner les QoS)
h1. Journal (Ã partir du 28 oct)
Activités du projet de Yanick & Jocelyn (TX)
h2. 27 nov.
* Lecture et utilisation de linkagreg (outil d'agrégation de Fernando)
* Faire fonctionner linkagreg sur une architecture 64bits
* Faire fonctionner linkagreg avec une connection sur le client //Fonctionnel
* Faire fonctionner linkagre avec n connection sur le client //Non fonctionnel
** * * Test avec une connection filaire et WiFi //Non fonctionnel car perte (important) de paquet sur le lien WiFi
** * * Test avec des connections virtuelles //Non fonctionnel car QoS inapplicable sur des interfaces virtuelles
** * * Test avec deux interfaces physiques //Non fonctionnel car QoS déficiente
h2. 11 nov.
* Debuggage du problème de MTU (c'est honteux mais c'est bêtement la taille des buffers qui n'était pas assez grande dans le programme. Notamment dû aux pseudo en-têtes, cf plus bas).
* Configuration auto des adresses IP de chaque côté du tunnel (plus besoin d'ifconfig à la main)
* Ajout sur tunproxy.py de compteurs de débit
* mémorise le traffic sur les x dernières tranches de n secondes (défaut 10 tranches de 1 seconde)
* Affiche les moyennes et les max.
* Compréhension de ce qui passe dans TUN : bien qu'étant un tunnel de niveau 3, il y a une pseudo-en-tête de L2, cf "doc officielle":http://www.mjmwired.net/kernel/Documentation/networking/tuntap.txt#102 (merci Laurent!)
* discussion avec Laurent sur les intérêts de faire un tunnel L2 (qui rajoute pourtant l'overhead de l'en-tête L2), en bref :
* évite de gérer les soucis spécifiques du niveau IP
* TUN ne supporte pas IPV6 par exemple â¦
h2. 5 nov.
* Mise en place d'un dépôt git (gitolite) pour partager du code avec Fernando Alves de Sames Wireless :
# Dépot public : (lecture-seule)
git clone git://rhizome-fai.tetaneutral.net/agregation.git
h2. 28 oct.
* Initiation python (découverte pour Yanick)
* Commentaire intégral du tunproxy.py et premiers tests de ce dernier
** ping ok (+1ms)
** iperf à travers le tunnel : BP ~= celle de l'uplink ADSL. Le dernier datagrame ne reçoit pas d'ACK
<pre>
[ 3] local 10.0.0.2 port 50191 connected with 10.0.0.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 1.25 MBytes 1.05 Mbits/sec
[ 3] Sent 893 datagrams
[ 3] WARNING: did not receive ack of last datagram after 10 tries.
</pre>
h2. 2 novembre
* Modification de la MTU pour éviter la fragmentation de paquet
h1. Fonctionnalité
* Ajouter plusieurs sockets sur le tunnel pour éviter le traffic shaping de la part d'un opérateur
* [[Bibliographie du projet]]
* [[L'installation de gitolite]]
* http://pad.rhizome-fai.net/U7HSgxYvDM | Le code du tunnel tun réalisé avec python
* http://pad.rhizome-fai.net/TS2HBLkTnN | Spécification de l'iperf (de quel manière on détecte la capacité d'un lien de manière opportuniste ? Monitoring ?)
* http://lists.tetaneutral.net/listinfo/projet-agregation
* http://chiliproject.tetaneutral.net/issues/16
h2. Prototype v1
http://lists.tetaneutral.net/pipermail/projet-agregation/2011-November/000023.html
h2. Test de tunproxy.py
On utilise "tunproxy.py":http://www.secdev.org/projects/tuntap_udp/files/tunproxy.py. Entre 2 machines
* client-adsl (une machine chez nous)
* gateway (la VM)
h3. Sur la gateway (= VM ttn)
Démarrer le tunnel, il crée lui-même une interface _toto0_ (détruite à la sortie).
<pre>
./tunproxy.py -s 6000
ifconfig toto0 10.0.0.1/24 mtu 1468
</pre>
La MTU est calculée comme suit :
MTU de l'iface virtuelle = MTU de l'iface physique - taille_max(header IP) - taille(header UDP)
MTU de l'iface virtuelle = 1500 - 24 - 8
http://www.commentcamarche.net/faq/7185-introduction-au-mtu
h3. Sur le client
<pre>
./tunproxy.py -c rhizome-fai.tetaneutral.net:6000
ifconfig toto0 10.0.0.2/24 mtu 1468
</pre>
Tout le trafic vers les adresses en 10.0.0.x passera par le tunnel.
* http://lists.tetaneutral.net/listinfo/projet-agregation
* http://chiliproject.tetaneutral.net/issues/16
Un test de perf sur un téléchargement d'un fichier de 40Mio donne :
* avec tunnel : 909kb/s
* sans tunnel : 942kb/s
h1. Petits points techniquesâ¦
h2. Que mesure iperf et comment (en UDP) ?
Iperf mesure le débit du client vers le serveur (dans un seul sens). En UDP, il envoie à une vitesse nominale (par défait 1M). Le résultat donné par le client n'est pas une mesure mais correspond à cette vitesse nominale. *Seul le _server repport_ correspond à la "vraie" mesure.*
La saturation d'un lien générant des pertes, pour mesurer les pertes liées à la qualité du lien (et non à sa capacité), il faut demander au client d'émettre un peu en-dessous de la vitesse à laquelle peut recevoir le serveur.
h2. Quelques outils réseaux bien pratique
* tcpdump | http://openmaniak.com/fr/tcpdump.php
<pre bash>
tcpdump -D #Interfaces réseaux disponibles pour la capture
tcpdump port 80 -i eth0 -w capture.log #Enregistre le trafic Web vers le fichier capture.log pouvant être ouvert avec Wireshark
tcpdump icmp #Affiche tout le trafic associé au protocole icmp
</pre>
* ping | http://www.bortzmeyer.org/ping-taille-compte.html
** Permet de tester un problème de MTU grâce à l'option -s de ping permettant de fixer une taille de paquet
* hping3
<pre bash>
hping --syn -p 80 --data 1200 10.0.0.1 #Envoie de paquet tcp syn sur le port 80 de taille 1200
</pre>
*tracepath* pour découvrir le PMTU
h1. TODO étapes suivantes
* Chercher relation entre variations de latence et saturation de lien. Concrètement, être capable de détecter *l'évènement "mon lien est saturé"* et de mémoriser la capacité max. du lien
* Finir de lire/comprendre le code de Fernando (linkagreg)
* Lire/comprendre le bout de script python de Laurent (multi-UDP pour contourner les QoS)
h1. Journal (Ã partir du 28 oct)
Activités du projet de Yanick & Jocelyn (TX)
h2. 27 nov.
* Lecture et utilisation de linkagreg (outil d'agrégation de Fernando)
* Faire fonctionner linkagreg sur une architecture 64bits
* Faire fonctionner linkagreg avec une connection sur le client //Fonctionnel
* Faire fonctionner linkagre avec n connection sur le client //Non fonctionnel
** * * Test avec une connection filaire et WiFi //Non fonctionnel car perte (important) de paquet sur le lien WiFi
** * * Test avec des connections virtuelles //Non fonctionnel car QoS inapplicable sur des interfaces virtuelles
** * * Test avec deux interfaces physiques //Non fonctionnel car QoS déficiente
h2. 11 nov.
* Debuggage du problème de MTU (c'est honteux mais c'est bêtement la taille des buffers qui n'était pas assez grande dans le programme. Notamment dû aux pseudo en-têtes, cf plus bas).
* Configuration auto des adresses IP de chaque côté du tunnel (plus besoin d'ifconfig à la main)
* Ajout sur tunproxy.py de compteurs de débit
* mémorise le traffic sur les x dernières tranches de n secondes (défaut 10 tranches de 1 seconde)
* Affiche les moyennes et les max.
* Compréhension de ce qui passe dans TUN : bien qu'étant un tunnel de niveau 3, il y a une pseudo-en-tête de L2, cf "doc officielle":http://www.mjmwired.net/kernel/Documentation/networking/tuntap.txt#102 (merci Laurent!)
* discussion avec Laurent sur les intérêts de faire un tunnel L2 (qui rajoute pourtant l'overhead de l'en-tête L2), en bref :
* évite de gérer les soucis spécifiques du niveau IP
* TUN ne supporte pas IPV6 par exemple â¦
h2. 5 nov.
* Mise en place d'un dépôt git (gitolite) pour partager du code avec Fernando Alves de Sames Wireless :
# Dépot public : (lecture-seule)
git clone git://rhizome-fai.tetaneutral.net/agregation.git
h2. 28 oct.
* Initiation python (découverte pour Yanick)
* Commentaire intégral du tunproxy.py et premiers tests de ce dernier
** ping ok (+1ms)
** iperf à travers le tunnel : BP ~= celle de l'uplink ADSL. Le dernier datagrame ne reçoit pas d'ACK
<pre>
[ 3] local 10.0.0.2 port 50191 connected with 10.0.0.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 1.25 MBytes 1.05 Mbits/sec
[ 3] Sent 893 datagrams
[ 3] WARNING: did not receive ack of last datagram after 10 tries.
</pre>
h2. 2 novembre
* Modification de la MTU pour éviter la fragmentation de paquet
h1. Fonctionnalité
* Ajouter plusieurs sockets sur le tunnel pour éviter le traffic shaping de la part d'un opérateur