Projet

Général

Profil

Projet agregation » Historique » Version 57

Jocelyn Dealande, 08/08/2012 03:02

1 1 Laurent GUERBY
h1. Projet agregation
2 1 Laurent GUERBY
3 18 Yanick Delarbre
* [[L'installation de gitolite]]
4 3 Yanick Delarbre
* http://pad.rhizome-fai.net/U7HSgxYvDM | Le code du tunnel tun réalisé avec python
5 17 Yanick Delarbre
* 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 ?)
6 1 Laurent GUERBY
7 1 Laurent GUERBY
* http://lists.tetaneutral.net/listinfo/projet-agregation
8 1 Laurent GUERBY
* http://chiliproject.tetaneutral.net/issues/16
9 4 Jocelyn Dealande
10 50 Laurent GUERBY
* MLVPN de ed https://github.com/zehome/MLVPN
11 50 Laurent GUERBY
12 1 Laurent GUERBY
* discussion sur le sujet http://www.spinics.net/lists/lartc/msg21455.html
13 55 Jocelyn Dealande
14 55 Jocelyn Dealande
h2. Projet universitaire UTC (Compiègne) Yanick & Jocelyn (Automne 2011)
15 55 Jocelyn Dealande
16 56 Jocelyn Dealande
* code (python): git clone git://rhizome-fai.tetaneutral.net/agregation.git
17 55 Jocelyn Dealande
* Rapport attachment:Rapport_2.pdf
18 55 Jocelyn Dealande
* Présentation attachment:Agrégation_de_liens_xDSL_sur_un_réseau_radio.pdf 
19 57 Jocelyn Dealande
* vidéo de la soutenance : http://rhizome-fai.net/media/videos/soutenance_tx_agregation_UTC_TTNN_jdelalande_ydelarbre.webm
20 55 Jocelyn Dealande
* [[Bibliographie du projet]] (pas à jour, cf rapport pour une version à jour)
21 31 Laurent GUERBY
22 22 Laurent GUERBY
h2. Prototype v1
23 22 Laurent GUERBY
24 22 Laurent GUERBY
http://lists.tetaneutral.net/pipermail/projet-agregation/2011-November/000023.html
25 4 Jocelyn Dealande
26 4 Jocelyn Dealande
h2. Test de tunproxy.py
27 4 Jocelyn Dealande
28 4 Jocelyn Dealande
On utilise "tunproxy.py":http://www.secdev.org/projects/tuntap_udp/files/tunproxy.py. Entre 2 machines
29 4 Jocelyn Dealande
* client-adsl (une machine chez nous)
30 4 Jocelyn Dealande
* gateway (la VM)
31 4 Jocelyn Dealande
32 4 Jocelyn Dealande
h3. Sur la gateway (= VM ttn)
33 4 Jocelyn Dealande
34 4 Jocelyn Dealande
Démarrer le tunnel, il crée lui-même une interface _toto0_ (détruite à la sortie).
35 4 Jocelyn Dealande
36 4 Jocelyn Dealande
<pre>
37 4 Jocelyn Dealande
 ./tunproxy.py -s 6000
38 11 Jocelyn Dealande
 ifconfig toto0 10.0.0.1/24 mtu 1468
39 4 Jocelyn Dealande
</pre>
40 1 Laurent GUERBY
41 15 Jocelyn Dealande
La MTU est calculée comme suit : 
42 1 Laurent GUERBY
43 11 Jocelyn Dealande
  MTU de l'iface virtuelle  = MTU  de l'iface physique - taille_max(header IP) - taille(header UDP)
44 15 Jocelyn Dealande
  MTU de l'iface virtuelle = 1500 - 24 - 8
45 11 Jocelyn Dealande
46 17 Yanick Delarbre
http://www.commentcamarche.net/faq/7185-introduction-au-mtu
47 11 Jocelyn Dealande
48 4 Jocelyn Dealande
h3. Sur le client
49 4 Jocelyn Dealande
50 4 Jocelyn Dealande
51 4 Jocelyn Dealande
<pre>
52 4 Jocelyn Dealande
 ./tunproxy.py -c rhizome-fai.tetaneutral.net:6000
53 12 Yanick Delarbre
 ifconfig toto0 10.0.0.2/24 mtu 1468
54 4 Jocelyn Dealande
</pre>
55 4 Jocelyn Dealande
56 4 Jocelyn Dealande
Tout le trafic vers les adresses en 10.0.0.x passera par le tunnel.
57 4 Jocelyn Dealande
58 4 Jocelyn Dealande
* http://lists.tetaneutral.net/listinfo/projet-agregation
59 1 Laurent GUERBY
* http://chiliproject.tetaneutral.net/issues/16
60 1 Laurent GUERBY
61 15 Jocelyn Dealande
Un test de perf sur un téléchargement d'un fichier de 40Mio donne :
62 15 Jocelyn Dealande
63 15 Jocelyn Dealande
* avec tunnel : 909kb/s
64 15 Jocelyn Dealande
* sans tunnel : 942kb/s
65 15 Jocelyn Dealande
66 29 Jocelyn Dealande
h1. Détection de la saturation d'un lien / bufferbloat
67 30 Jocelyn Dealande
68 29 Jocelyn Dealande
Un des points sur lesquels nous nous penchons est la détection de la capacité d'un lien et de son évolution, ceci 1) pour utiliser au mieux des liens de capacité différente et éventuellement changeante.
69 29 Jocelyn Dealande
70 29 Jocelyn Dealande
Tout le challenge est de détecter (passivement) plutôt que de mesurer (activement) la capacité du lien, sans induire de trafic supplémentaire.
71 29 Jocelyn Dealande
72 29 Jocelyn Dealande
Nous avons fait des mesures sur deux liens :
73 29 Jocelyn Dealande
74 29 Jocelyn Dealande
h2. Mesure ADSL Free (Freebox)
75 29 Jocelyn Dealande
76 29 Jocelyn Dealande
Il semble que de la QoS soit appliquée… l'effet de bufferbloat n'est pas vraiment visible : on passe d'un ping de 40 à 70/80ms… (TODO: prendre le temps de collecter des résultats des deux côtés du tunnel un peu plus sérieusement que juste l'impression donnée ceci-dit). Tous les paquets de ping arrivent, même lorsque le lien est saturé.
77 29 Jocelyn Dealande
78 29 Jocelyn Dealande
h2. Lien ADSL (OVH)
79 29 Jocelyn Dealande
80 29 Jocelyn Dealande
L'effet de la saturation se fait clairement ressentir sur le ping : on passe de 70 à plus de 300ms de ping lorsque le lien est saturé.
81 1 Laurent GUERBY
82 30 Jocelyn Dealande
Données du test et graphiques : attachment:saturation_et_ping___uplink_seulement__udp_sctp.ods 
83 30 Jocelyn Dealande
84 1 Laurent GUERBY
h3. Conditions du test :
85 30 Jocelyn Dealande
86 1 Laurent GUERBY
* Tunnel tap basé sur tunproxy.py (cf dépôt git), qui est le seul à utiliser la connexion
87 1 Laurent GUERBY
* Données collectées toutes les secondes, chaque peer enregistre : 
88 30 Jocelyn Dealande
** timestamp
89 30 Jocelyn Dealande
** stats des paquets entrants
90 30 Jocelyn Dealande
** ping
91 29 Jocelyn Dealande
* On teste la connection au repos en la saturant par moments avec iperf
92 30 Jocelyn Dealande
** en UDP : en metant l'option -b à une valeur supérieure à la capacité d'uplink 
93 30 Jocelyn Dealande
** en TCP
94 1 Laurent GUERBY
* Les données des 2 peers sont fusionnées à posteriori (script merge_tunproxy_csv.py) en fonction des timestamp.
95 30 Jocelyn Dealande
* Les données sont graphées sur un tableur (ouais je sais, beurk ;-) ).
96 29 Jocelyn Dealande
97 29 Jocelyn Dealande
Le comptage du volume sortant n'est pas pertinent puisque la moitié des paquets peuvent-être dropés en route…
98 29 Jocelyn Dealande
99 29 Jocelyn Dealande
100 29 Jocelyn Dealande
h3. Analyse des résultats
101 30 Jocelyn Dealande
102 29 Jocelyn Dealande
(voir document joint)
103 29 Jocelyn Dealande
* On note systématiquement une corrélation forte entre lien saturé et augmentation du ping. Que le lien soit saturé en UDP ou TCP.
104 29 Jocelyn Dealande
* En UDP, on peut saturer le lien complètement. Il en résulte qu'une part des pings se perd -> Prendre non seulement en compte le RTT mais également le taux de pings perdus.
105 29 Jocelyn Dealande
* En TCP, on observe aussi une montée du ping significative, mais jamais de pings perdus. On constate d'ailleurs que TCP se rend compte qu'il sature le lien et divise sa fenêtre (trou dans le graphe).
106 29 Jocelyn Dealande
* -> Quid de la réalité de la saturation d'un lien par rapport à ces deux exemples simples ?
107 11 Jocelyn Dealande
108 11 Jocelyn Dealande
109 32 Jocelyn Dealande
h2. Demi-délai
110 32 Jocelyn Dealande
111 32 Jocelyn Dealande
Nous pouvons donc corréler une saturation du lien (qu'elle soit effectuée par un protocole qui gère la congestion ou non) avec une augmentation du ping. Reste un autre problème, nous voulons détecter dans quel sens a lieu la saturation. Or un ping nous donne le temps d'aller retour (RTT, Round-Trip-time). Il n'est en outre pas possible de mesure la durée absolue d'une trame entre deux sites, les horloges n'étant pas synchronisées. Deux approches sont envisagées
112 32 Jocelyn Dealande
113 32 Jocelyn Dealande
114 32 Jocelyn Dealande
h3. Synchronisation par NTP
115 32 Jocelyn Dealande
116 32 Jocelyn Dealande
NTP est un protocole permetant de synchroniser via le réseau les horloges de machines distantes. Si NTP fournit une précision suffisante, il serait intéressant pour pouvoir effectuer des demi-ping : 
117 32 Jocelyn Dealande
118 32 Jocelyn Dealande
*  On maintient les horloges synchronisées grace à NTP entre machine 1 et machine 2
119 32 Jocelyn Dealande
*  Machine1 envoie un paquet à machine2 contenant un timestamp
120 32 Jocelyn Dealande
*  Machine 2 peut connaître le temps de trajet machine1->machine2 en comparant ce timestamp avec sa propre horloge.
121 32 Jocelyn Dealande
122 32 Jocelyn Dealande
On mesure des ping entre 20 et 100ms en général, soit des demi-ping entre 10 et 50ms. Or, les études sur NTP (ex: http://www.eecis.udel.edu/~mills/database/brief/perf/perf.pdf) montrent qu'à travers un réseau WAN (ex: l'ADSL que nous utilisons), l'erreur de NTP est autour de *10ms*. Soit une erreur relative entre 10% et 50%, ce qui n'est pas acceptable. La seule solution viable, selon l'étude mentionnée, pour synchroniser réellement des équipements serait d'avoir une source GPS qui permet d'avoir une erreur en-dessous de la milliseconde. Cela nécessite de l'équipement supplémentaire et n'est souhaitable.
123 32 Jocelyn Dealande
124 32 Jocelyn Dealande
Voir aussi http://www.frameip.com/ntp/
125 32 Jocelyn Dealande
126 32 Jocelyn Dealande
h3. Par évolution du délai relatif
127 32 Jocelyn Dealande
128 32 Jocelyn Dealande
Une autre approche discutée est de mesurer non pas le délai absolu mais la variation de celui-ci.
129 32 Jocelyn Dealande
On mesure timestamp_envoi_site1 - timestamp_reception_site2 pour chaque paquet, la valeur absolue n'a aucun sens (on utilise deux horloges différentes).
130 32 Jocelyn Dealande
131 32 Jocelyn Dealande
Un autre problème est alors la dérive relative des horloges des deux machines qu'il ne faut pas négliger (exemple donné dans l'article sur UTP de 17ms de dérive en 10 minutes)
132 32 Jocelyn Dealande
133 32 Jocelyn Dealande
Cette idée est d'ailleurs reprise dans le protocole UTP de bittorrent : http://www.rasterbar.com/products/libtorrent/utp.html
134 32 Jocelyn Dealande
135 33 Jocelyn Dealande
Un outil faisant ce type de mesure a été implémenté dans le dépôt : _delta_half_trip_time.py_ 
136 33 Jocelyn Dealande
137 33 Jocelyn Dealande
Côté serveur :
138 33 Jocelyn Dealande
139 33 Jocelyn Dealande
    ./delta_half_trip_time.py -s 2244
140 33 Jocelyn Dealande
141 33 Jocelyn Dealande
Côté client:
142 33 Jocelyn Dealande
143 33 Jocelyn Dealande
    ./delta_half_trip_time.py -s <ip_serv>:2244
144 33 Jocelyn Dealande
145 33 Jocelyn Dealande
Le script mesure en permanence les délais toutes les secondes. Il ne prend pas en compte la dérive d'horloge pour l'heure. La sortie est du CSV contenant les délais dans les deux sens (de chaque côté). Le format est :
146 33 Jocelyn Dealande
147 34 Jocelyn Dealande
    pkt_type,sequence number,delay
148 33 Jocelyn Dealande
149 33 Jocelyn Dealande
_pkt_type_ vaut *'t'* (comme _timer_) pour les mesures entrantes (download) et *'d'* (comme _delay_) pour les réponses aux paquets sortants (upload).
150 33 Jocelyn Dealande
151 33 Jocelyn Dealande
h4. mesures
152 33 Jocelyn Dealande
153 44 Jocelyn Dealande
Résultats : attachment:one-way_delay.ods
154 1 Laurent GUERBY
155 44 Jocelyn Dealande
h5. Saturation TCP (iperf) dans un sens puis dans l'autre
156 1 Laurent GUERBY
Note sur ces mesures (iperf TCP) : correspond peut-être au cas le plus difficile à détecter (une unique connection TCP qui sature le lien) étant donné que le backoff de TCP va essayer d'éviter de saturer le lien en permanence.
157 44 Jocelyn Dealande
158 44 Jocelyn Dealande
h5. Saturation UDP progressive
159 44 Jocelyn Dealande
160 44 Jocelyn Dealande
Ces mesures sont effectuées à l'aide de load_uplink.py (dans le git)
161 44 Jocelyn Dealande
162 44 Jocelyn Dealande
Pour charger l'upload d'une connecxion qui monte en pratique à ~109kB/s (résultat iperf TCP).
163 44 Jocelyn Dealande
On passe par paliers de 10kB/s de 0 à 120kB/s (5s par palier) :
164 44 Jocelyn Dealande
165 44 Jocelyn Dealande
    python load_uplink.py 91.224.149.199 10 5 120
166 44 Jocelyn Dealande
167 44 Jocelyn Dealande
Par ailleurs, on observe à l'aide de delta_half_trip_time.py l'évolution du ping (cf document de résultats).
168 44 Jocelyn Dealande
169 44 Jocelyn Dealande
On observe qu'il n'y a pas de saturation progressive. Ou le lien est saturé et en quelques secondes, le delay s'envole, ou il ne l'est pas et le ping reste stable.
170 44 Jocelyn Dealande
171 44 Jocelyn Dealande
172 44 Jocelyn Dealande
Plusieurs tests ont été réalisés, l'idée étant de trouver la formule qui à partir des n derniers delays et du delai minimum est capable de dire si oui ou non on a saturation.
173 44 Jocelyn Dealande
174 44 Jocelyn Dealande
175 44 Jocelyn Dealande
On arrive à une première solution, elle ne fait pas de faux positifs mais peine à détecter les saturations < 10 secondes.
176 44 Jocelyn Dealande
177 44 Jocelyn Dealande
   Soit "l_derniers" les 6 derniers échantillons de délai
178 44 Jocelyn Dealande
   Si max(l_derniers) > TRIGGER et 4 échantillons de l_derniers au moins sont supérieurs à 1/3*max(l_derniers), alors SATURATION
179 44 Jocelyn Dealande
180 45 Jocelyn Dealande
h5. Mesure d'un scénario d'usage
181 33 Jocelyn Dealande
182 45 Jocelyn Dealande
Le but est ici de mesurer un scénario d'usage « classique » de la connexion, en upload et download pour voir si une formule nous permet de détecter les pics.
183 45 Jocelyn Dealande
(cf sat. usage normaux dans le document attaché).
184 45 Jocelyn Dealande
185 45 Jocelyn Dealande
Le scénario est le suivant : 
186 45 Jocelyn Dealande
187 45 Jocelyn Dealande
* vidéo en 1080p sur youtube (téléchargement par sacade « à la youtube »)
188 45 Jocelyn Dealande
* scp d'un fichier vers un serveur (3MiO)
189 45 Jocelyn Dealande
* scp d'un fichier depuis un serveur (3MiO)
190 45 Jocelyn Dealande
191 45 Jocelyn Dealande
h6. Observations
192 45 Jocelyn Dealande
On observe que, particulièrement en download, il n'est pas possible de détecter les saturations courtes. Ne saturant pas les buffers du modem-routeur, elles ne font pas grimper le délai. (cf SCP en up). On doit ceci-dit être proche de la limite avec notre transfert de 3Mio car sur les deux essais, il y a une fois ou on a une réponse en augmentation de délai et une fois sans.
193 45 Jocelyn Dealande
194 45 Jocelyn Dealande
Il est curieux de noter que les saturation en download entrainent également une augmentation du délai en upload. Nous n'avons jamais observé ça jusqu'alors… Je n'en comprend pas le sens -> à éclaircir/reproduire.
195 45 Jocelyn Dealande
196 36 Jocelyn Dealande
h4. dérive
197 36 Jocelyn Dealande
198 36 Jocelyn Dealande
Le fichier attachment:one-way_delay.ods présente également une mesure de la dérive sur 40 minutes entre 2 machines. L'enjeu est de savoir si il est nécessaire de mettre en place un mécanisme pour détecter et prendre en compte la dérive des horloges qui rendraient la comparaison de deux délais relatifs peu pertinents si elle était trop importante.
199 36 Jocelyn Dealande
200 36 Jocelyn Dealande
Bien que l'expérience ne porte que sur un cas et ne fasse pas loi, elle nous expose une dérive de 0.5ms sur 40 minutes d'observation (dérive relative de ~1.4%). Ne souhaitant garder pour nos mesures de capacité de lien qu'une fenêtre glissante que de quelques minutes ou dizaines de minutes tout au plus, il n'apparaît pas nécessaire de prendre en compte cette dérive.
201 33 Jocelyn Dealande
202 33 Jocelyn Dealande
203 52 Jocelyn Dealande
h2. Influence du réseau radio
204 52 Jocelyn Dealande
205 52 Jocelyn Dealande
On considère que le réseau radio entre les différents points de raccordement à internet n'est pas un goulot d'étranglement.
206 52 Jocelyn Dealande
En revanche, il faut prendre garde à la qualité du lien, qui peut fausser les mesures Le transmit CCQ (paquets valides/paquets transmis) est un bon indicateur de la qualité du lien. Un lien de mauvaise qualité impliquera que certains pings soient plus longs (retransmissions). cf document ping_et_bande_passante.ods
207 52 Jocelyn Dealande
208 11 Jocelyn Dealande
h1. Petits points techniques…
209 11 Jocelyn Dealande
210 20 Jocelyn Dealande
h2. Que mesure iperf et comment (en UDP) ?
211 1 Laurent GUERBY
212 16 Jocelyn Dealande
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.*
213 17 Yanick Delarbre
214 17 Yanick Delarbre
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.
215 17 Yanick Delarbre
216 17 Yanick Delarbre
h2. Quelques outils réseaux bien pratique
217 17 Yanick Delarbre
218 17 Yanick Delarbre
* tcpdump | http://openmaniak.com/fr/tcpdump.php
219 17 Yanick Delarbre
<pre bash>
220 17 Yanick Delarbre
tcpdump -D #Interfaces réseaux disponibles pour la capture
221 17 Yanick Delarbre
tcpdump port 80 -i eth0 -w capture.log #Enregistre le trafic Web vers le fichier capture.log pouvant être ouvert avec Wireshark
222 17 Yanick Delarbre
tcpdump icmp #Affiche tout le trafic associé au protocole icmp
223 17 Yanick Delarbre
</pre>
224 17 Yanick Delarbre
* ping | http://www.bortzmeyer.org/ping-taille-compte.html
225 17 Yanick Delarbre
** Permet de tester un problème de MTU grâce à l'option -s de ping permettant de fixer une taille de paquet
226 17 Yanick Delarbre
* hping3
227 17 Yanick Delarbre
<pre bash>
228 5 Jocelyn Dealande
hping --syn -p 80 --data 1200 10.0.0.1 #Envoie de paquet tcp syn sur le port 80 de taille 1200
229 15 Jocelyn Dealande
</pre>
230 21 Jocelyn Dealande
231 21 Jocelyn Dealande
232 23 Jocelyn Dealande
*tracepath* pour découvrir le PMTU
233 23 Jocelyn Dealande
234 42 Yanick Delarbre
h1. multi.py
235 40 Yanick Delarbre
236 40 Yanick Delarbre
peer_: Liste des sockets du clients basés sur ses interfaces physiques
237 40 Yanick Delarbre
peer_d: sous forme de dictionnaire
238 40 Yanick Delarbre
peer_l: sous forme de liste
239 40 Yanick Delarbre
240 40 Yanick Delarbre
La structure:
241 40 Yanick Delarbre
Liste < . . . > Dictionnaire
242 40 Yanick Delarbre
0->A  < . . . > <A,None>
243 40 Yanick Delarbre
1->B  < . . . > <B,None>
244 40 Yanick Delarbre
2->C  < . . . > <C,None>
245 40 Yanick Delarbre
246 41 Yanick Delarbre
!http://chiliproject.tetaneutral.net/attachments/23/schema_multy.png!
247 40 Yanick Delarbre
248 48 Jocelyn Dealande
249 48 Jocelyn Dealande
h2. Routage
250 48 Jocelyn Dealande
251 48 Jocelyn Dealande
Pour qu'un script comme multi.py fonctionne, il faut faire du routage selon la source.
252 48 Jocelyn Dealande
253 49 Jocelyn Dealande
* http://www.inetdoc.net/guides/lartc/lartc.iproute2.html
254 49 Jocelyn Dealande
* http://www.rjsystems.nl/en/2100-adv-routing.php
255 49 Jocelyn Dealande
* man ip
256 49 Jocelyn Dealande
257 48 Jocelyn Dealande
En effet, il n'y a qu'une IP de serveur, mais N IPs de client. Or, les décisions de routage d'une table gérée avec la commande route sont de la forme suivante (simplifié):
258 48 Jocelyn Dealande
259 48 Jocelyn Dealande
    <Destination> <passerelle> <interface>
260 48 Jocelyn Dealande
261 48 Jocelyn Dealande
Le routage est fait seulement en fonction de la destination.
262 48 Jocelyn Dealande
263 48 Jocelyn Dealande
On utilise donc l'outil _ip route_. Quelques exemples.
264 48 Jocelyn Dealande
Montrer la table de routage:
265 48 Jocelyn Dealande
    
266 48 Jocelyn Dealande
    ip route show
267 48 Jocelyn Dealande
268 48 Jocelyn Dealande
Montrer la route pour une IP source et dest données :
269 48 Jocelyn Dealande
270 48 Jocelyn Dealande
    ip route get 0.0.0.0 from 192.168.1.71
271 48 Jocelyn Dealande
272 48 Jocelyn Dealande
273 48 Jocelyn Dealande
274 48 Jocelyn Dealande
Initialement, on a deux interfaces (eth0 et wlan0) avec une passerelle vers internet sur chaque (2 lignes ADSL), on est NATé sur les deux. Mais une seule est déclarée comme route par défaut.
275 48 Jocelyn Dealande
276 48 Jocelyn Dealande
<pre>
277 48 Jocelyn Dealande
jocelyn@sensitive:~$ ip route get 8.8.8.8 from 192.168.2.33
278 48 Jocelyn Dealande
8.8.8.8 from 192.168.2.33 via 192.168.1.254 dev wlan0 
279 48 Jocelyn Dealande
    cache 
280 48 Jocelyn Dealande
jocelyn@sensitive:~$ ip route get 8.8.8.8 from 192.168.1.71
281 48 Jocelyn Dealande
8.8.8.8 from 192.168.1.71 via 192.168.1.254 dev wlan0 
282 48 Jocelyn Dealande
    cache 
283 48 Jocelyn Dealande
284 48 Jocelyn Dealande
</pre>
285 48 Jocelyn Dealande
286 48 Jocelyn Dealande
Par défaut, on n'a que la table « main » et « default ».  (on peut voir les tables avec _ip rule_).
287 48 Jocelyn Dealande
Nos deux ip locales sont 192.168.1.71 (wlan0) et 192.168.2.33 (eth0)
288 48 Jocelyn Dealande
On y ajoute notre table : fdn_rhizome avec nos règles :
289 48 Jocelyn Dealande
290 48 Jocelyn Dealande
    # Ajout d'une nouvelle table
291 48 Jocelyn Dealande
    echo "1000 rhizome_fdn" >> /etc/iproute2/rt_tables
292 48 Jocelyn Dealande
    # et sa route par défaut
293 48 Jocelyn Dealande
    ip route add default via 192.168.2.1 dev eth0 table rhizome_fdn
294 48 Jocelyn Dealande
    # On dit au système de ne regarder notre table que pour les requêtes venant de 192.168.2.33
295 48 Jocelyn Dealande
    ip rule add from 192.168.2.33 lookup rhizome_fdn prio 1000
296 48 Jocelyn Dealande
297 48 Jocelyn Dealande
On vérifie qu'on passe par une interface différente en fonction de l'IP source : 
298 48 Jocelyn Dealande
299 48 Jocelyn Dealande
    jocelyn@sensitive:~$ ip route get 8.8.8.8 from 192.168.2.33
300 48 Jocelyn Dealande
    8.8.8.8 from 192.168.2.33 via 192.168.2.1 dev eth0
301 48 Jocelyn Dealande
    8.8.8.8 from 192.168.1.71 via 192.168.1.254 dev wlan0
302 51 Jocelyn Dealande
303 51 Jocelyn Dealande
Pour un test pratique, on peut utiliser ping avec l'option -I pour spécifier l'interface de sortie, puis vérifier dans wireshark que les trames sortent bien par une interface différente (header MAC, il suffit de regarder l'addr. MAC source).
304 51 Jocelyn Dealande
305 51 Jocelyn Dealande
Script pour permettre de sortir sur deux interfaces WAN différentes, dans le git : _dual-wan-routing.sh_
306 51 Jocelyn Dealande
Le script met en place les règles de routage pour les deux interfaces puis les test.
307 51 Jocelyn Dealande
308 51 Jocelyn Dealande
309 48 Jocelyn Dealande
 
310 48 Jocelyn Dealande
311 48 Jocelyn Dealande
312 1 Laurent GUERBY
h1. Journal (à partir du 28 oct)
313 1 Laurent GUERBY
314 1 Laurent GUERBY
Activités du projet de Yanick & Jocelyn (TX) 
315 53 Jocelyn Dealande
*
316 53 Jocelyn Dealande
317 53 Jocelyn Dealande
h2. du 23 au 30 Janvier
318 53 Jocelyn Dealande
319 53 Jocelyn Dealande
* Implémentation de l'agrégation avec ajustement dynamique des pondérations
320 53 Jocelyn Dealande
* Mesures sur une vraies agrégation de deux liens (latence, download, upload…)
321 53 Jocelyn Dealande
* Analyse des résultats
322 53 Jocelyn Dealande
* Mesures de l'influence du réseau radio
323 53 Jocelyn Dealande
* création d'un script basique d'initialisation
324 53 Jocelyn Dealande
* Rapport
325 49 Jocelyn Dealande
326 49 Jocelyn Dealande
h2. 22 Janvier
327 49 Jocelyn Dealande
328 49 Jocelyn Dealande
* Configuration du routage avec IProute2
329 51 Jocelyn Dealande
** Script dual-wan.sh de configuration du routage (attention, flush les tables de routage…)
330 49 Jocelyn Dealande
331 45 Jocelyn Dealande
332 45 Jocelyn Dealande
h2. 16 Janvier
333 45 Jocelyn Dealande
334 45 Jocelyn Dealande
* Détection de saturation
335 45 Jocelyn Dealande
** Le tableur détecte à la fois les saturations en upload et download
336 45 Jocelyn Dealande
** Le tableur prend maintenant des paramètres au lieu de valeurs en dur pour ajuster la formule…
337 45 Jocelyn Dealande
** Bugfixé le script qui nettoie les CSV.
338 45 Jocelyn Dealande
TODO: reproduire et vérifier l'histoire de délais dans les 2 sens, appliquer le tableau paramétré détectant l'UP et down aux mesures précédentes
339 1 Laurent GUERBY
340 1 Laurent GUERBY
h2. 8 janvier.
341 1 Laurent GUERBY
342 43 Jocelyn Dealande
* Détection de saturation:
343 43 Jocelyn Dealande
** Évolution de delta_half_trip_time.py pour enregistrer un historique des délais (dans les 2 sens)
344 43 Jocelyn Dealande
** Ajout d'une détection de saturation (… Mais à améliorer, trop de faux positifs)
345 43 Jocelyn Dealande
** Création de l'outil de test load_uplink.py pour charger progressivement un lien jusqu'à la saturation et pouvoir ainsi observer le comportement du ping.
346 37 Yanick Delarbre
* Compréhension du script multy.py de Laurent Guerby
347 43 Jocelyn Dealande
** Commentaire du script multy.py
348 37 Yanick Delarbre
** Schéma graphique du fonctionnement de multy.py
349 43 Jocelyn Dealande
350 37 Yanick Delarbre
351 38 Yanick Delarbre
h2. 28/29 déc.
352 33 Jocelyn Dealande
353 33 Jocelyn Dealande
* Détection de saturation : nouvel outil pour mesurer les délais dans un sens
354 33 Jocelyn Dealande
** Création de l'outil, qui fonctionne de manière bidirectionelle et rapporte les informations aux deux pairs
355 33 Jocelyn Dealande
** Première mesure rapide sur un iperf en TCP, dans un sens puis dans l'autre, simplement pour valider la détection.
356 29 Jocelyn Dealande
357 29 Jocelyn Dealande
h2. 5 déc.
358 30 Jocelyn Dealande
359 29 Jocelyn Dealande
* Détection de saturation :
360 29 Jocelyn Dealande
* Output CSV en direct vers le fichier plutôt que statiquement au bout de 3 minutes…
361 29 Jocelyn Dealande
* Écriture d'un outil de script de logs CSV
362 1 Laurent GUERBY
* Collecte de mesures sur l'effet sur le ping de la saturation d'un lien en UDP et TCP
363 24 Yanick Delarbre
* Analyse basique des résultats
364 25 Yanick Delarbre
365 24 Yanick Delarbre
h2. 27 nov.
366 24 Yanick Delarbre
367 24 Yanick Delarbre
* Lecture et utilisation de linkagreg (outil d'agrégation de Fernando)
368 24 Yanick Delarbre
* Faire fonctionner linkagreg sur une architecture 64bits
369 27 Yanick Delarbre
* Faire fonctionner linkagreg avec une connection sur le client //Fonctionnel
370 27 Yanick Delarbre
* Faire fonctionner linkagre avec n connection sur le client //Non fonctionnel
371 27 Yanick Delarbre
** Test avec une connection filaire et WiFi //Non fonctionnel car perte (important) de paquet sur le lien WiFi
372 23 Jocelyn Dealande
** Test avec des connections virtuelles //Non fonctionnel car QoS inapplicable sur des interfaces virtuelles
373 28 Jocelyn Dealande
** Test avec deux interfaces physiques //Non fonctionnel car QoS déficiente
374 28 Jocelyn Dealande
375 28 Jocelyn Dealande
* Ajout de la collecte de données sur les temps de réponse (ping) périodiquement.
376 28 Jocelyn Dealande
* Export des données en CSV (pour exploitation/graphe… etc.)
377 28 Jocelyn Dealande
* Premier jeu de mesure (mauvais) sur une ligne adsl.
378 19 Jocelyn Dealande
* 
379 19 Jocelyn Dealande
380 19 Jocelyn Dealande
h2. 11 nov.
381 19 Jocelyn Dealande
382 19 Jocelyn Dealande
* 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).
383 19 Jocelyn Dealande
* Configuration auto des adresses IP de chaque côté du tunnel (plus besoin d'ifconfig à la main)
384 19 Jocelyn Dealande
* Ajout sur tunproxy.py de compteurs de débit 
385 19 Jocelyn Dealande
  * mémorise le traffic sur les x dernières tranches de n secondes (défaut 10 tranches de 1 seconde)
386 19 Jocelyn Dealande
  * Affiche les moyennes et les max.
387 19 Jocelyn Dealande
* 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!)
388 19 Jocelyn Dealande
* 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 :
389 19 Jocelyn Dealande
  * évite de gérer les soucis spécifiques du niveau IP
390 1 Laurent GUERBY
  * TUN ne supporte pas IPV6 par exemple …
391 23 Jocelyn Dealande
392 23 Jocelyn Dealande
393 23 Jocelyn Dealande
h2. 5 nov.
394 35 Jocelyn Dealande
395 23 Jocelyn Dealande
* Mise en place d'un dépôt git (gitolite) pour partager du code avec Fernando Alves de Sames Wireless : 
396 23 Jocelyn Dealande
397 23 Jocelyn Dealande
    # Dépot public  : (lecture-seule)
398 1 Laurent GUERBY
    git clone git://rhizome-fai.tetaneutral.net/agregation.git
399 6 Jocelyn Dealande
400 54 Yanick Delarbre
h2. 2 nov
401 54 Yanick Delarbre
402 54 Yanick Delarbre
* Modification de la MTU pour éviter la fragmentation de paquet
403 54 Yanick Delarbre
404 23 Jocelyn Dealande
h2.  28 oct. 
405 5 Jocelyn Dealande
406 8 Jocelyn Dealande
* Initiation python (découverte pour Yanick) 
407 15 Jocelyn Dealande
* Commentaire intégral du tunproxy.py et premiers tests de ce dernier
408 5 Jocelyn Dealande
** ping ok (+1ms)
409 5 Jocelyn Dealande
** iperf à travers le tunnel : BP ~= celle de l'uplink ADSL. Le dernier datagrame ne reçoit pas d'ACK
410 5 Jocelyn Dealande
411 5 Jocelyn Dealande
<pre>
412 5 Jocelyn Dealande
[  3] local 10.0.0.2 port 50191 connected with 10.0.0.1 port 5001                        
413 5 Jocelyn Dealande
[ ID] Interval       Transfer     Bandwidth                                              
414 13 Yanick Delarbre
[  3]  0.0-10.0 sec  1.25 MBytes  1.05 Mbits/sec                                         
415 13 Yanick Delarbre
[  3] Sent 893 datagrams                                                                 
416 13 Yanick Delarbre
[  3] WARNING: did not receive ack of last datagram after 10 tries.
417 13 Yanick Delarbre
</pre>
418 13 Yanick Delarbre
419 13 Yanick Delarbre
h1. Fonctionnalité
420 1 Laurent GUERBY
421 1 Laurent GUERBY
* Ajouter plusieurs sockets sur le tunnel pour éviter le traffic shaping de la part d'un opérateur
422 46 Yanick Delarbre
423 46 Yanick Delarbre
h1. Annexes
424 46 Yanick Delarbre
425 46 Yanick Delarbre
h2. Rappel de base de python
426 47 Yanick Delarbre
427 46 Yanick Delarbre
<pre>
428 46 Yanick Delarbre
@classmethod: Decorater python: la méthode s'applique à la définition de la classe. Il s'agit d'une méthode statique.
429 46 Yanick Delarbre
#cls: La classe Python et non l'objet instancié: tous les objets instanciés sont modifiés, il s'agit d'un attribut statique.
430 46 Yanick Delarbre
#self: L'objet instancié, équivalent du this.
431 46 Yanick Delarbre
</pre>