Projet

Général

Profil

Projet agregation » Historique » Version 28

« Précédent - Version 28/225 (diff) - Suivant » - Version actuelle
Jocelyn Dealande, 05/12/2011 20:56


Projet agregation

Prototype v1

http://lists.tetaneutral.net/pipermail/projet-agregation/2011-November/000023.html

Test de tunproxy.py

On utilise tunproxy.py. Entre 2 machines
  • client-adsl (une machine chez nous)
  • gateway (la VM)

Sur la gateway (= VM ttn)

Démarrer le tunnel, il crée lui-même une interface toto0 (détruite à la sortie).

 ./tunproxy.py -s 6000
 ifconfig toto0 10.0.0.1/24 mtu 1468

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

Sur le client

 ./tunproxy.py -c rhizome-fai.tetaneutral.net:6000
 ifconfig toto0 10.0.0.2/24 mtu 1468

Tout le trafic vers les adresses en 10.0.0.x passera par le tunnel.

Un test de perf sur un téléchargement d'un fichier de 40Mio donne :

  • avec tunnel : 909kb/s
  • sans tunnel : 942kb/s

Petits points techniques…

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.

Quelques outils réseaux bien pratique

  • tcpdump | http://openmaniak.com/fr/tcpdump.php
    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
    
  • 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
    hping --syn -p 80 --data 1200 10.0.0.1 #Envoie de paquet tcp syn sur le port 80 de taille 1200
    

tracepath pour découvrir le PMTU

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)

Journal (à partir du 28 oct)

Activités du projet de Yanick & Jocelyn (TX)

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
  • Ajout de la collecte de données sur les temps de réponse (ping) périodiquement.
  • Export des données en CSV (pour exploitation/graphe… etc.)
  • Premier jeu de mesure (mauvais) sur une ligne adsl. *

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 (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 …

5 nov.
  • Mise en place d'un dépôt git (gitolite) pour partager du code avec Fernando Alves de Sames Wireless :

  1. Dépot public : (lecture-seule)
    git clone git://rhizome-fai.tetaneutral.net/agregation.git

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
[  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.

2 novembre

  • Modification de la MTU pour éviter la fragmentation de paquet

Fonctionnalité

  • Ajouter plusieurs sockets sur le tunnel pour éviter le traffic shaping de la part d'un opérateur