Projet agregation » Historique » Version 49
Jocelyn Dealande, 22/01/2012 21:11
1 | 1 | Laurent GUERBY | h1. Projet agregation |
---|---|---|---|
2 | 1 | Laurent GUERBY | |
3 | 2 | Yanick Delarbre | * [[Bibliographie du projet]] |
4 | 18 | Yanick Delarbre | * [[L'installation de gitolite]] |
5 | 3 | Yanick Delarbre | * http://pad.rhizome-fai.net/U7HSgxYvDM | Le code du tunnel tun réalisé avec python |
6 | 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 ?) |
7 | 1 | Laurent GUERBY | |
8 | 1 | Laurent GUERBY | * http://lists.tetaneutral.net/listinfo/projet-agregation |
9 | 1 | Laurent GUERBY | * http://chiliproject.tetaneutral.net/issues/16 |
10 | 4 | Jocelyn Dealande | |
11 | 31 | Laurent GUERBY | * discussion sur le sujet http://www.spinics.net/lists/lartc/msg21455.html |
12 | 31 | Laurent GUERBY | |
13 | 22 | Laurent GUERBY | h2. Prototype v1 |
14 | 22 | Laurent GUERBY | |
15 | 22 | Laurent GUERBY | http://lists.tetaneutral.net/pipermail/projet-agregation/2011-November/000023.html |
16 | 4 | Jocelyn Dealande | |
17 | 4 | Jocelyn Dealande | h2. Test de tunproxy.py |
18 | 4 | Jocelyn Dealande | |
19 | 4 | Jocelyn Dealande | On utilise "tunproxy.py":http://www.secdev.org/projects/tuntap_udp/files/tunproxy.py. Entre 2 machines |
20 | 4 | Jocelyn Dealande | * client-adsl (une machine chez nous) |
21 | 4 | Jocelyn Dealande | * gateway (la VM) |
22 | 4 | Jocelyn Dealande | |
23 | 4 | Jocelyn Dealande | h3. Sur la gateway (= VM ttn) |
24 | 4 | Jocelyn Dealande | |
25 | 4 | Jocelyn Dealande | Démarrer le tunnel, il crée lui-même une interface _toto0_ (détruite à la sortie). |
26 | 4 | Jocelyn Dealande | |
27 | 4 | Jocelyn Dealande | <pre> |
28 | 4 | Jocelyn Dealande | ./tunproxy.py -s 6000 |
29 | 11 | Jocelyn Dealande | ifconfig toto0 10.0.0.1/24 mtu 1468 |
30 | 4 | Jocelyn Dealande | </pre> |
31 | 1 | Laurent GUERBY | |
32 | 15 | Jocelyn Dealande | La MTU est calculée comme suit : |
33 | 1 | Laurent GUERBY | |
34 | 11 | Jocelyn Dealande | MTU de l'iface virtuelle = MTU de l'iface physique - taille_max(header IP) - taille(header UDP) |
35 | 15 | Jocelyn Dealande | MTU de l'iface virtuelle = 1500 - 24 - 8 |
36 | 11 | Jocelyn Dealande | |
37 | 17 | Yanick Delarbre | http://www.commentcamarche.net/faq/7185-introduction-au-mtu |
38 | 11 | Jocelyn Dealande | |
39 | 4 | Jocelyn Dealande | h3. Sur le client |
40 | 4 | Jocelyn Dealande | |
41 | 4 | Jocelyn Dealande | |
42 | 4 | Jocelyn Dealande | <pre> |
43 | 4 | Jocelyn Dealande | ./tunproxy.py -c rhizome-fai.tetaneutral.net:6000 |
44 | 12 | Yanick Delarbre | ifconfig toto0 10.0.0.2/24 mtu 1468 |
45 | 4 | Jocelyn Dealande | </pre> |
46 | 4 | Jocelyn Dealande | |
47 | 4 | Jocelyn Dealande | Tout le trafic vers les adresses en 10.0.0.x passera par le tunnel. |
48 | 4 | Jocelyn Dealande | |
49 | 4 | Jocelyn Dealande | * http://lists.tetaneutral.net/listinfo/projet-agregation |
50 | 1 | Laurent GUERBY | * http://chiliproject.tetaneutral.net/issues/16 |
51 | 1 | Laurent GUERBY | |
52 | 15 | Jocelyn Dealande | Un test de perf sur un téléchargement d'un fichier de 40Mio donne : |
53 | 15 | Jocelyn Dealande | |
54 | 15 | Jocelyn Dealande | * avec tunnel : 909kb/s |
55 | 15 | Jocelyn Dealande | * sans tunnel : 942kb/s |
56 | 15 | Jocelyn Dealande | |
57 | 29 | Jocelyn Dealande | h1. Détection de la saturation d'un lien / bufferbloat |
58 | 30 | Jocelyn Dealande | |
59 | 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. |
60 | 29 | Jocelyn Dealande | |
61 | 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. |
62 | 29 | Jocelyn Dealande | |
63 | 29 | Jocelyn Dealande | Nous avons fait des mesures sur deux liens : |
64 | 29 | Jocelyn Dealande | |
65 | 29 | Jocelyn Dealande | h2. Mesure ADSL Free (Freebox) |
66 | 29 | Jocelyn Dealande | |
67 | 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é. |
68 | 29 | Jocelyn Dealande | |
69 | 29 | Jocelyn Dealande | h2. Lien ADSL (OVH) |
70 | 29 | Jocelyn Dealande | |
71 | 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é. |
72 | 1 | Laurent GUERBY | |
73 | 30 | Jocelyn Dealande | Données du test et graphiques : attachment:saturation_et_ping___uplink_seulement__udp_sctp.ods |
74 | 30 | Jocelyn Dealande | |
75 | 1 | Laurent GUERBY | h3. Conditions du test : |
76 | 30 | Jocelyn Dealande | |
77 | 1 | Laurent GUERBY | * Tunnel tap basé sur tunproxy.py (cf dépôt git), qui est le seul à utiliser la connexion |
78 | 1 | Laurent GUERBY | * Données collectées toutes les secondes, chaque peer enregistre : |
79 | 30 | Jocelyn Dealande | ** timestamp |
80 | 30 | Jocelyn Dealande | ** stats des paquets entrants |
81 | 30 | Jocelyn Dealande | ** ping |
82 | 29 | Jocelyn Dealande | * On teste la connection au repos en la saturant par moments avec iperf |
83 | 30 | Jocelyn Dealande | ** en UDP : en metant l'option -b à une valeur supérieure à la capacité d'uplink |
84 | 30 | Jocelyn Dealande | ** en TCP |
85 | 1 | Laurent GUERBY | * Les données des 2 peers sont fusionnées à posteriori (script merge_tunproxy_csv.py) en fonction des timestamp. |
86 | 30 | Jocelyn Dealande | * Les données sont graphées sur un tableur (ouais je sais, beurk ;-) ). |
87 | 29 | Jocelyn Dealande | |
88 | 29 | Jocelyn Dealande | Le comptage du volume sortant n'est pas pertinent puisque la moitié des paquets peuvent-être dropés en route⦠|
89 | 29 | Jocelyn Dealande | |
90 | 29 | Jocelyn Dealande | |
91 | 29 | Jocelyn Dealande | h3. Analyse des résultats |
92 | 30 | Jocelyn Dealande | |
93 | 29 | Jocelyn Dealande | (voir document joint) |
94 | 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. |
95 | 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. |
96 | 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). |
97 | 29 | Jocelyn Dealande | * -> Quid de la réalité de la saturation d'un lien par rapport à ces deux exemples simples ? |
98 | 11 | Jocelyn Dealande | |
99 | 11 | Jocelyn Dealande | |
100 | 32 | Jocelyn Dealande | h2. Demi-délai |
101 | 32 | Jocelyn Dealande | |
102 | 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 |
103 | 32 | Jocelyn Dealande | |
104 | 32 | Jocelyn Dealande | |
105 | 32 | Jocelyn Dealande | h3. Synchronisation par NTP |
106 | 32 | Jocelyn Dealande | |
107 | 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 : |
108 | 32 | Jocelyn Dealande | |
109 | 32 | Jocelyn Dealande | * On maintient les horloges synchronisées grace à NTP entre machine 1 et machine 2 |
110 | 32 | Jocelyn Dealande | * Machine1 envoie un paquet à machine2 contenant un timestamp |
111 | 32 | Jocelyn Dealande | * Machine 2 peut connaître le temps de trajet machine1->machine2 en comparant ce timestamp avec sa propre horloge. |
112 | 32 | Jocelyn Dealande | |
113 | 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. |
114 | 32 | Jocelyn Dealande | |
115 | 32 | Jocelyn Dealande | Voir aussi http://www.frameip.com/ntp/ |
116 | 32 | Jocelyn Dealande | |
117 | 32 | Jocelyn Dealande | h3. Par évolution du délai relatif |
118 | 32 | Jocelyn Dealande | |
119 | 32 | Jocelyn Dealande | Une autre approche discutée est de mesurer non pas le délai absolu mais la variation de celui-ci. |
120 | 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). |
121 | 32 | Jocelyn Dealande | |
122 | 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) |
123 | 32 | Jocelyn Dealande | |
124 | 32 | Jocelyn Dealande | Cette idée est d'ailleurs reprise dans le protocole UTP de bittorrent : http://www.rasterbar.com/products/libtorrent/utp.html |
125 | 32 | Jocelyn Dealande | |
126 | 33 | Jocelyn Dealande | Un outil faisant ce type de mesure a été implémenté dans le dépôt : _delta_half_trip_time.py_ |
127 | 33 | Jocelyn Dealande | |
128 | 33 | Jocelyn Dealande | Côté serveur : |
129 | 33 | Jocelyn Dealande | |
130 | 33 | Jocelyn Dealande | ./delta_half_trip_time.py -s 2244 |
131 | 33 | Jocelyn Dealande | |
132 | 33 | Jocelyn Dealande | Côté client: |
133 | 33 | Jocelyn Dealande | |
134 | 33 | Jocelyn Dealande | ./delta_half_trip_time.py -s <ip_serv>:2244 |
135 | 33 | Jocelyn Dealande | |
136 | 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 : |
137 | 33 | Jocelyn Dealande | |
138 | 34 | Jocelyn Dealande | pkt_type,sequence number,delay |
139 | 33 | Jocelyn Dealande | |
140 | 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). |
141 | 33 | Jocelyn Dealande | |
142 | 33 | Jocelyn Dealande | h4. mesures |
143 | 33 | Jocelyn Dealande | |
144 | 44 | Jocelyn Dealande | Résultats : attachment:one-way_delay.ods |
145 | 1 | Laurent GUERBY | |
146 | 44 | Jocelyn Dealande | h5. Saturation TCP (iperf) dans un sens puis dans l'autre |
147 | 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. |
148 | 44 | Jocelyn Dealande | |
149 | 44 | Jocelyn Dealande | h5. Saturation UDP progressive |
150 | 44 | Jocelyn Dealande | |
151 | 44 | Jocelyn Dealande | Ces mesures sont effectuées à l'aide de load_uplink.py (dans le git) |
152 | 44 | Jocelyn Dealande | |
153 | 44 | Jocelyn Dealande | Pour charger l'upload d'une connecxion qui monte en pratique à ~109kB/s (résultat iperf TCP). |
154 | 44 | Jocelyn Dealande | On passe par paliers de 10kB/s de 0 Ã 120kB/s (5s par palier) : |
155 | 44 | Jocelyn Dealande | |
156 | 44 | Jocelyn Dealande | python load_uplink.py 91.224.149.199 10 5 120 |
157 | 44 | Jocelyn Dealande | |
158 | 44 | Jocelyn Dealande | Par ailleurs, on observe à l'aide de delta_half_trip_time.py l'évolution du ping (cf document de résultats). |
159 | 44 | Jocelyn Dealande | |
160 | 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. |
161 | 44 | Jocelyn Dealande | |
162 | 44 | Jocelyn Dealande | |
163 | 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. |
164 | 44 | Jocelyn Dealande | |
165 | 44 | Jocelyn Dealande | |
166 | 44 | Jocelyn Dealande | On arrive à une première solution, elle ne fait pas de faux positifs mais peine à détecter les saturations < 10 secondes. |
167 | 44 | Jocelyn Dealande | |
168 | 44 | Jocelyn Dealande | Soit "l_derniers" les 6 derniers échantillons de délai |
169 | 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 |
170 | 44 | Jocelyn Dealande | |
171 | 45 | Jocelyn Dealande | h5. Mesure d'un scénario d'usage |
172 | 33 | Jocelyn Dealande | |
173 | 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. |
174 | 45 | Jocelyn Dealande | (cf sat. usage normaux dans le document attaché). |
175 | 45 | Jocelyn Dealande | |
176 | 45 | Jocelyn Dealande | Le scénario est le suivant : |
177 | 45 | Jocelyn Dealande | |
178 | 45 | Jocelyn Dealande | * vidéo en 1080p sur youtube (téléchargement par sacade « à la youtube ») |
179 | 45 | Jocelyn Dealande | * scp d'un fichier vers un serveur (3MiO) |
180 | 45 | Jocelyn Dealande | * scp d'un fichier depuis un serveur (3MiO) |
181 | 45 | Jocelyn Dealande | |
182 | 45 | Jocelyn Dealande | h6. Observations |
183 | 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. |
184 | 45 | Jocelyn Dealande | |
185 | 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. |
186 | 45 | Jocelyn Dealande | |
187 | 36 | Jocelyn Dealande | h4. dérive |
188 | 36 | Jocelyn Dealande | |
189 | 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. |
190 | 36 | Jocelyn Dealande | |
191 | 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. |
192 | 33 | Jocelyn Dealande | |
193 | 33 | Jocelyn Dealande | |
194 | 11 | Jocelyn Dealande | h1. Petits points techniques⦠|
195 | 11 | Jocelyn Dealande | |
196 | 20 | Jocelyn Dealande | h2. Que mesure iperf et comment (en UDP) ? |
197 | 1 | Laurent GUERBY | |
198 | 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.* |
199 | 17 | Yanick Delarbre | |
200 | 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. |
201 | 17 | Yanick Delarbre | |
202 | 17 | Yanick Delarbre | h2. Quelques outils réseaux bien pratique |
203 | 17 | Yanick Delarbre | |
204 | 17 | Yanick Delarbre | * tcpdump | http://openmaniak.com/fr/tcpdump.php |
205 | 17 | Yanick Delarbre | <pre bash> |
206 | 17 | Yanick Delarbre | tcpdump -D #Interfaces réseaux disponibles pour la capture |
207 | 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 |
208 | 17 | Yanick Delarbre | tcpdump icmp #Affiche tout le trafic associé au protocole icmp |
209 | 17 | Yanick Delarbre | </pre> |
210 | 17 | Yanick Delarbre | * ping | http://www.bortzmeyer.org/ping-taille-compte.html |
211 | 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 |
212 | 17 | Yanick Delarbre | * hping3 |
213 | 17 | Yanick Delarbre | <pre bash> |
214 | 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 |
215 | 15 | Jocelyn Dealande | </pre> |
216 | 21 | Jocelyn Dealande | |
217 | 21 | Jocelyn Dealande | |
218 | 23 | Jocelyn Dealande | *tracepath* pour découvrir le PMTU |
219 | 23 | Jocelyn Dealande | |
220 | 42 | Yanick Delarbre | h1. multi.py |
221 | 40 | Yanick Delarbre | |
222 | 40 | Yanick Delarbre | peer_: Liste des sockets du clients basés sur ses interfaces physiques |
223 | 40 | Yanick Delarbre | peer_d: sous forme de dictionnaire |
224 | 40 | Yanick Delarbre | peer_l: sous forme de liste |
225 | 40 | Yanick Delarbre | |
226 | 40 | Yanick Delarbre | La structure: |
227 | 40 | Yanick Delarbre | Liste < . . . > Dictionnaire |
228 | 40 | Yanick Delarbre | 0->A < . . . > <A,None> |
229 | 40 | Yanick Delarbre | 1->B < . . . > <B,None> |
230 | 40 | Yanick Delarbre | 2->C < . . . > <C,None> |
231 | 40 | Yanick Delarbre | |
232 | 41 | Yanick Delarbre | !http://chiliproject.tetaneutral.net/attachments/23/schema_multy.png! |
233 | 40 | Yanick Delarbre | |
234 | 48 | Jocelyn Dealande | |
235 | 48 | Jocelyn Dealande | h2. Routage |
236 | 48 | Jocelyn Dealande | |
237 | 48 | Jocelyn Dealande | Pour qu'un script comme multi.py fonctionne, il faut faire du routage selon la source. |
238 | 48 | Jocelyn Dealande | |
239 | 49 | Jocelyn Dealande | * http://www.inetdoc.net/guides/lartc/lartc.iproute2.html |
240 | 49 | Jocelyn Dealande | * http://www.rjsystems.nl/en/2100-adv-routing.php |
241 | 49 | Jocelyn Dealande | * man ip |
242 | 49 | Jocelyn Dealande | |
243 | 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é): |
244 | 48 | Jocelyn Dealande | |
245 | 48 | Jocelyn Dealande | <Destination> <passerelle> <interface> |
246 | 48 | Jocelyn Dealande | |
247 | 48 | Jocelyn Dealande | Le routage est fait seulement en fonction de la destination. |
248 | 48 | Jocelyn Dealande | |
249 | 48 | Jocelyn Dealande | On utilise donc l'outil _ip route_. Quelques exemples. |
250 | 48 | Jocelyn Dealande | Montrer la table de routage: |
251 | 48 | Jocelyn Dealande | |
252 | 48 | Jocelyn Dealande | ip route show |
253 | 48 | Jocelyn Dealande | |
254 | 48 | Jocelyn Dealande | Montrer la route pour une IP source et dest données : |
255 | 48 | Jocelyn Dealande | |
256 | 48 | Jocelyn Dealande | ip route get 0.0.0.0 from 192.168.1.71 |
257 | 48 | Jocelyn Dealande | |
258 | 48 | Jocelyn Dealande | |
259 | 48 | Jocelyn Dealande | |
260 | 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. |
261 | 48 | Jocelyn Dealande | |
262 | 48 | Jocelyn Dealande | <pre> |
263 | 48 | Jocelyn Dealande | jocelyn@sensitive:~$ ip route get 8.8.8.8 from 192.168.2.33 |
264 | 48 | Jocelyn Dealande | 8.8.8.8 from 192.168.2.33 via 192.168.1.254 dev wlan0 |
265 | 48 | Jocelyn Dealande | cache |
266 | 48 | Jocelyn Dealande | jocelyn@sensitive:~$ ip route get 8.8.8.8 from 192.168.1.71 |
267 | 48 | Jocelyn Dealande | 8.8.8.8 from 192.168.1.71 via 192.168.1.254 dev wlan0 |
268 | 48 | Jocelyn Dealande | cache |
269 | 48 | Jocelyn Dealande | |
270 | 48 | Jocelyn Dealande | </pre> |
271 | 48 | Jocelyn Dealande | |
272 | 48 | Jocelyn Dealande | Par défaut, on n'a que la table « main » et « default ». (on peut voir les tables avec _ip rule_). |
273 | 48 | Jocelyn Dealande | Nos deux ip locales sont 192.168.1.71 (wlan0) et 192.168.2.33 (eth0) |
274 | 48 | Jocelyn Dealande | On y ajoute notre table : fdn_rhizome avec nos règles : |
275 | 48 | Jocelyn Dealande | |
276 | 48 | Jocelyn Dealande | # Ajout d'une nouvelle table |
277 | 48 | Jocelyn Dealande | echo "1000 rhizome_fdn" >> /etc/iproute2/rt_tables |
278 | 48 | Jocelyn Dealande | # et sa route par défaut |
279 | 48 | Jocelyn Dealande | ip route add default via 192.168.2.1 dev eth0 table rhizome_fdn |
280 | 48 | Jocelyn Dealande | # On dit au système de ne regarder notre table que pour les requêtes venant de 192.168.2.33 |
281 | 48 | Jocelyn Dealande | ip rule add from 192.168.2.33 lookup rhizome_fdn prio 1000 |
282 | 48 | Jocelyn Dealande | |
283 | 48 | Jocelyn Dealande | On vérifie qu'on passe par une interface différente en fonction de l'IP source : |
284 | 48 | Jocelyn Dealande | |
285 | 48 | Jocelyn Dealande | jocelyn@sensitive:~$ ip route get 8.8.8.8 from 192.168.2.33 |
286 | 48 | Jocelyn Dealande | 8.8.8.8 from 192.168.2.33 via 192.168.2.1 dev eth0 |
287 | 48 | Jocelyn Dealande | 8.8.8.8 from 192.168.1.71 via 192.168.1.254 dev wlan0 |
288 | 48 | Jocelyn Dealande | |
289 | 48 | Jocelyn Dealande | |
290 | 48 | Jocelyn Dealande | |
291 | 1 | Laurent GUERBY | h1. Journal (Ã partir du 28 oct) |
292 | 1 | Laurent GUERBY | |
293 | 1 | Laurent GUERBY | Activités du projet de Yanick & Jocelyn (TX) |
294 | 49 | Jocelyn Dealande | |
295 | 49 | Jocelyn Dealande | h2. 22 Janvier |
296 | 49 | Jocelyn Dealande | |
297 | 49 | Jocelyn Dealande | * Configuration du routage avec IProute2 |
298 | 49 | Jocelyn Dealande | |
299 | 45 | Jocelyn Dealande | |
300 | 45 | Jocelyn Dealande | h2. 16 Janvier |
301 | 45 | Jocelyn Dealande | |
302 | 45 | Jocelyn Dealande | * Détection de saturation |
303 | 45 | Jocelyn Dealande | ** Le tableur détecte à la fois les saturations en upload et download |
304 | 45 | Jocelyn Dealande | ** Le tableur prend maintenant des paramètres au lieu de valeurs en dur pour ajuster la formule⦠|
305 | 45 | Jocelyn Dealande | ** Bugfixé le script qui nettoie les CSV. |
306 | 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 |
307 | 1 | Laurent GUERBY | |
308 | 1 | Laurent GUERBY | h2. 8 janvier. |
309 | 1 | Laurent GUERBY | |
310 | 43 | Jocelyn Dealande | * Détection de saturation: |
311 | 43 | Jocelyn Dealande | ** Ãvolution de delta_half_trip_time.py pour enregistrer un historique des délais (dans les 2 sens) |
312 | 43 | Jocelyn Dealande | ** Ajout d'une détection de saturation (⦠Mais à améliorer, trop de faux positifs) |
313 | 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. |
314 | 37 | Yanick Delarbre | * Compréhension du script multy.py de Laurent Guerby |
315 | 43 | Jocelyn Dealande | ** Commentaire du script multy.py |
316 | 37 | Yanick Delarbre | ** Schéma graphique du fonctionnement de multy.py |
317 | 43 | Jocelyn Dealande | |
318 | 37 | Yanick Delarbre | |
319 | 38 | Yanick Delarbre | h2. 28/29 déc. |
320 | 33 | Jocelyn Dealande | |
321 | 33 | Jocelyn Dealande | * Détection de saturation : nouvel outil pour mesurer les délais dans un sens |
322 | 33 | Jocelyn Dealande | ** Création de l'outil, qui fonctionne de manière bidirectionelle et rapporte les informations aux deux pairs |
323 | 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. |
324 | 29 | Jocelyn Dealande | |
325 | 29 | Jocelyn Dealande | h2. 5 déc. |
326 | 30 | Jocelyn Dealande | |
327 | 29 | Jocelyn Dealande | * Détection de saturation : |
328 | 29 | Jocelyn Dealande | * Output CSV en direct vers le fichier plutôt que statiquement au bout de 3 minutes⦠|
329 | 29 | Jocelyn Dealande | * Ãcriture d'un outil de script de logs CSV |
330 | 1 | Laurent GUERBY | * Collecte de mesures sur l'effet sur le ping de la saturation d'un lien en UDP et TCP |
331 | 24 | Yanick Delarbre | * Analyse basique des résultats |
332 | 25 | Yanick Delarbre | |
333 | 24 | Yanick Delarbre | h2. 27 nov. |
334 | 24 | Yanick Delarbre | |
335 | 24 | Yanick Delarbre | * Lecture et utilisation de linkagreg (outil d'agrégation de Fernando) |
336 | 24 | Yanick Delarbre | * Faire fonctionner linkagreg sur une architecture 64bits |
337 | 27 | Yanick Delarbre | * Faire fonctionner linkagreg avec une connection sur le client //Fonctionnel |
338 | 27 | Yanick Delarbre | * Faire fonctionner linkagre avec n connection sur le client //Non fonctionnel |
339 | 27 | Yanick Delarbre | ** Test avec une connection filaire et WiFi //Non fonctionnel car perte (important) de paquet sur le lien WiFi |
340 | 23 | Jocelyn Dealande | ** Test avec des connections virtuelles //Non fonctionnel car QoS inapplicable sur des interfaces virtuelles |
341 | 28 | Jocelyn Dealande | ** Test avec deux interfaces physiques //Non fonctionnel car QoS déficiente |
342 | 28 | Jocelyn Dealande | |
343 | 28 | Jocelyn Dealande | * Ajout de la collecte de données sur les temps de réponse (ping) périodiquement. |
344 | 28 | Jocelyn Dealande | * Export des données en CSV (pour exploitation/graphe⦠etc.) |
345 | 28 | Jocelyn Dealande | * Premier jeu de mesure (mauvais) sur une ligne adsl. |
346 | 19 | Jocelyn Dealande | * |
347 | 19 | Jocelyn Dealande | |
348 | 19 | Jocelyn Dealande | h2. 11 nov. |
349 | 19 | Jocelyn Dealande | |
350 | 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). |
351 | 19 | Jocelyn Dealande | * Configuration auto des adresses IP de chaque côté du tunnel (plus besoin d'ifconfig à la main) |
352 | 19 | Jocelyn Dealande | * Ajout sur tunproxy.py de compteurs de débit |
353 | 19 | Jocelyn Dealande | * mémorise le traffic sur les x dernières tranches de n secondes (défaut 10 tranches de 1 seconde) |
354 | 19 | Jocelyn Dealande | * Affiche les moyennes et les max. |
355 | 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!) |
356 | 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 : |
357 | 19 | Jocelyn Dealande | * évite de gérer les soucis spécifiques du niveau IP |
358 | 1 | Laurent GUERBY | * TUN ne supporte pas IPV6 par exemple ⦠|
359 | 23 | Jocelyn Dealande | |
360 | 23 | Jocelyn Dealande | |
361 | 23 | Jocelyn Dealande | h2. 5 nov. |
362 | 35 | Jocelyn Dealande | |
363 | 23 | Jocelyn Dealande | * Mise en place d'un dépôt git (gitolite) pour partager du code avec Fernando Alves de Sames Wireless : |
364 | 23 | Jocelyn Dealande | |
365 | 23 | Jocelyn Dealande | # Dépot public : (lecture-seule) |
366 | 1 | Laurent GUERBY | git clone git://rhizome-fai.tetaneutral.net/agregation.git |
367 | 6 | Jocelyn Dealande | |
368 | 23 | Jocelyn Dealande | h2. 28 oct. |
369 | 5 | Jocelyn Dealande | |
370 | 8 | Jocelyn Dealande | * Initiation python (découverte pour Yanick) |
371 | 15 | Jocelyn Dealande | * Commentaire intégral du tunproxy.py et premiers tests de ce dernier |
372 | 5 | Jocelyn Dealande | ** ping ok (+1ms) |
373 | 5 | Jocelyn Dealande | ** iperf à travers le tunnel : BP ~= celle de l'uplink ADSL. Le dernier datagrame ne reçoit pas d'ACK |
374 | 5 | Jocelyn Dealande | |
375 | 5 | Jocelyn Dealande | <pre> |
376 | 5 | Jocelyn Dealande | [ 3] local 10.0.0.2 port 50191 connected with 10.0.0.1 port 5001 |
377 | 5 | Jocelyn Dealande | [ ID] Interval Transfer Bandwidth |
378 | 5 | Jocelyn Dealande | [ 3] 0.0-10.0 sec 1.25 MBytes 1.05 Mbits/sec |
379 | 5 | Jocelyn Dealande | [ 3] Sent 893 datagrams |
380 | 13 | Yanick Delarbre | [ 3] WARNING: did not receive ack of last datagram after 10 tries. |
381 | 13 | Yanick Delarbre | </pre> |
382 | 13 | Yanick Delarbre | |
383 | 13 | Yanick Delarbre | h2. 2 novembre |
384 | 13 | Yanick Delarbre | |
385 | 13 | Yanick Delarbre | * Modification de la MTU pour éviter la fragmentation de paquet |
386 | 13 | Yanick Delarbre | |
387 | 13 | Yanick Delarbre | h1. Fonctionnalité |
388 | 1 | Laurent GUERBY | |
389 | 1 | Laurent GUERBY | * Ajouter plusieurs sockets sur le tunnel pour éviter le traffic shaping de la part d'un opérateur |
390 | 46 | Yanick Delarbre | |
391 | 46 | Yanick Delarbre | h1. Annexes |
392 | 46 | Yanick Delarbre | |
393 | 46 | Yanick Delarbre | h2. Rappel de base de python |
394 | 47 | Yanick Delarbre | |
395 | 46 | Yanick Delarbre | <pre> |
396 | 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. |
397 | 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. |
398 | 46 | Yanick Delarbre | #self: L'objet instancié, équivalent du this. |
399 | 46 | Yanick Delarbre | </pre> |