Project

General

Profile

Projet agregation » History » Version 15

« Previous - Version 15/225 (diff) - Next » - Current version
Jocelyn Dealande, 11/02/2011 07:02 PM


Projet agregation

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

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.

Pourquoi iperf ne fonctionne pas bien (plein de pertes) en TCP avec une mauvaise MTU ?
Les faits, lorsque la MTU de l'interface de tunnel est à 0 :

  • iperf -c 10.0.0.1 ne fonctionne pas bien, à se demander si la fragmentation IP fonctionne (ne se termine jamais, on ne voit pas de paquets revenir vers le client)
  • un wget se foire comme iperf
  • ping -s 1500 10.0.0.1 fonctionne au poil)

Journal (à partir du 28 oct)

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

28 oct.

  • Initiation python (découverte pour Yanick ET Jocelyn)
  • 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