Projet agregation » Historique » Version 18
« Précédent -
Version 18/225
(diff) -
Suivant » -
Version actuelle
Yanick Delarbre, 09/11/2011 12:24
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
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.
- 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
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 1400 10.0.0.1 fonctionne au poil)
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
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