Le 27/03/2015 16:35, BERTRAND Joël a écrit :
Samuel a écrit :Il faudrait aussi que tu analyses le trafic sortant (sont-ce des ACK UDP pour le VPN ?). En virant le bond, qu'est-ce que cela donne ? Parce que j'ai un peu de mal à voir comment on fait du bonding en niveau 3 (ce qu'imposent les freeboxes qui ont chacune une adresse IP publique différente). Cela met peut-être un certain bazar dans les ACK d'openvpn.Le 27/03/2015 14:40, BERTRAND Joël a écrit :Samuel a écrit :Sur une VM Wheezy à la maison, j'ai monté 2 tunnels (2 lignes adsl) versun serveur OVHIls sont montés de manière classique et à priori optimisé : connexion en UDP et pas de chiffrement (cypher none) et en interface tap (car bondingdessus)Quand je fais un gros téléchargement (disons une video youtube) par leslignes adsl, je download à 13Mbit avec un upload (d'après zabbix) très léger : peut-être 200 à 500 kbQuand je route les IP google (208.xxxx , 173.xxxx etc ...) au travers dubonding des tap, je constate une baisse à moins de 10Mbit sur chaqueligne ...; et je constate que mon upload et complètement saturé (1 Mbit)sur chaque ligne au travers des tunnels vpn. [...]
Je n'ai pas trouvé beaucoup de doc, ni de solution, mais cela a l'air lié au problème de packet reordering du mode balance-rr du bonding. Avec un seul tunnel, ou même en changeant pour l'option balance-xor le problème disparait. (upload divisé par 2) Le problème avec balance-xor c'est que c'est plus lié à une connexion, ce qui fait qu'on ne bénéficie du bonding que sur plusieurs téléchargements. Je vais chercher pour comprendre si le problème du packet reordering est plus lié à la latence adsl ou comme tu le soulignais un problème de ack ( ce qui semblait être le cas au vu des captures tcpdump) vis à vis du routage (mais là je crois que ça va dépasser mes compétences).
J'ai joué avec les options no-replay et replay-window d'openvpn qui ont supprimé certains logs d'erreur liés à l'ordre des paquets, mais ça ne corrige pas l'overhead.
Merci encore. Je ferai un retour si je trouve. Samuel.