Project

General

Profile

Projet agregation » History » Version 13

Version 12 (Yanick Delarbre, 11/02/2011 05:57 PM) → Version 13/225 (Yanick Delarbre, 11/02/2011 05:59 PM)

h1. Projet agregation

* [[Bibliographie du projet]]
* http://pad.rhizome-fai.net/U7HSgxYvDM | Le code du tunnel tun réalisé avec python

* http://lists.tetaneutral.net/listinfo/projet-agregation
* http://chiliproject.tetaneutral.net/issues/16

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

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

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.

h1. Journal (à partir du 28 oct)

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

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

<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