Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Bonding OpenVpn

22 réponses
Avatar
Essomba
Bonjour à tous,

je reviens vers vous concernant le bonding dont on avait parlé dans un
autre message ( Re: Aggrégation débit - IP fallback du 19/12/2011 à 21h41 ).

Ce bonding est maintenant en exploitation avec les paramètres suivants :
- liens openvpn tap,
- bonding mode=0, monitoring par ARP ;
- bonding de chaque côté du VPN ;
- liens 1 et 2 : 512 kb/s ;
- lien 3 : 1 M/s.

J'aurais deux questions :
1. le mode 0 est du round robing, mais du vrai. Les débits sont quasi
les mêmes sur chaque liens alors que un lien pourrait permettre d'aller
deux fois plus vite. Pensez vous que je puisse passer en mode 802.3ad
sachant que chaque côté est une machine linux avec le driver bonding ?
Sinon comment pourrais-je exploiter complètement le lien le plus rapide ?
2. il y a des cycles dans le débit : ça accélère puis ralenti puis
accélère puis ralenti, ... alors que si on prends les connexions
individuellement, le débit est relativement stable. Une idée ?

Merci,

Laurent


--
Remplacez yahou par yahoo et com par fr pour me répondre en direct

Laurent

10 réponses

1 2 3
Avatar
Pascal Hambourg
Salut,

Essomba a écrit :
Bonjour à tous,

je reviens vers vous concernant le bonding dont on avait parlé dans un
autre message ( Re: Aggrégation débit - IP fallback du 19/12/2011 à 21h41 ).

Ce bonding est maintenant en exploitation avec les paramètres suivants :
- liens openvpn tap,
- bonding mode=0, monitoring par ARP ;
- bonding de chaque côté du VPN ;
- liens 1 et 2 : 512 kb/s ;
- lien 3 : 1 M/s.

J'aurais deux questions :
1. le mode 0 est du round robing, mais du vrai. Les débits sont quasi
les mêmes sur chaque liens alors que un lien pourrait permettre d'aller
deux fois plus vite. Pensez vous que je puisse passer en mode 802.3ad
sachant que chaque côté est une machine linux avec le driver bonding ?



Dans Documentation/bonding.txt on peut lire qu'un des prérequis est la
prise en charge d'ethtool par le pilote des interfaces pour récupérer la
vitesse et le duplex. Je doute que ce soit possible dans ton cas, le
débit étant fixés par les liens xDSL.

Sinon comment pourrais-je exploiter complètement le lien le plus rapide ?



J'avais suggéré d'agréger les deux liens à 512 Mbit/s, puis d'agréger le
bonding résultant avec le lien à 1 Mbit/s dans un second bonding.

2. il y a des cycles dans le débit : ça accélère puis ralenti puis
accélère puis ralenti, ... alors que si on prends les connexions
individuellement, le débit est relativement stable. Une idée ?



Pas vraiment, mais ça pourrait être un effet de la différence de
capacité des liens.
Avatar
essomba84
On 24/02/2012 20:41, Pascal Hambourg wrote:


J'avais suggéré d'agréger les deux liens à 512 Mbit/s, puis d'agréger le
bonding résultant avec le lien à 1 Mbit/s dans un second bonding.




ben oui, c'est une bonne idée sauf que ifenslave refuse une interface
slave de type bond... Ou alors je m'y prends mal...
Avatar
Pascal Hambourg
essomba84 a écrit :
On 24/02/2012 20:41, Pascal Hambourg wrote:

J'avais suggéré d'agréger les deux liens à 512 Mbit/s, puis d'agréger le
bonding résultant avec le lien à 1 Mbit/s dans un second bonding.




ben oui, c'est une bonne idée sauf que ifenslave refuse une interface
slave de type bond... Ou alors je m'y prends mal...



Que se passe-t-il ?
Je viens de tester sur une Debian Squeeze avec trois interfaces dummy,
ça a l'air de marcher.

# cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.5.0 (November 4, 2008)

Bonding Mode: load balancing (round-robin)
MII Status: up
MII Polling Interval (ms): 0
Up Delay (ms): 0
Down Delay (ms): 0

Slave Interface: dummy0
MII Status: up
Link Failure Count: 0
Permanent HW addr: 5a:77:95:4e:8f:61

Slave Interface: dummy1
MII Status: up
Link Failure Count: 0
Permanent HW addr: 86:cd:b0:7a:9f:85

# cat /proc/net/bonding/bond1
Ethernet Channel Bonding Driver: v3.5.0 (November 4, 2008)

Bonding Mode: load balancing (round-robin)
MII Status: up
MII Polling Interval (ms): 0
Up Delay (ms): 0
Down Delay (ms): 0

Slave Interface: bond0
MII Status: up
Link Failure Count: 0
Permanent HW addr: 5a:77:95:4e:8f:61

Slave Interface: dummy2
MII Status: up
Link Failure Count: 0
Permanent HW addr: 02:70:8f:42:49:ef

Après une salve de ping -f sur l'adresse IP broadcast de bond1 :

# ifconfig
bond0 Link encap:Ethernet HWaddr 5a:77:95:4e:8f:61
UP BROADCAST RUNNING SLAVE MASTER MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:411 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:0 (0.0 B) TX bytes:39870 (38.9 KiB)

bond1 Link encap:Ethernet HWaddr 5a:77:95:4e:8f:61
inet adr:172.16.0.1 Bcast:172.16.255.255 Masque:255.255.0.0
adr inet6: fe80::70:8fff:fe42:49ef/64 Scope:Lien
UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:814 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:0 (0.0 B) TX bytes:79160 (77.3 KiB)

dummy0 Link encap:Ethernet HWaddr 5a:77:95:4e:8f:61
UP BROADCAST RUNNING NOARP SLAVE MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:206 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:0 (0.0 B) TX bytes:19996 (19.5 KiB)

dummy1 Link encap:Ethernet HWaddr 5a:77:95:4e:8f:61
UP BROADCAST RUNNING NOARP SLAVE MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:205 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:0 (0.0 B) TX bytes:19874 (19.4 KiB)

dummy2 Link encap:Ethernet HWaddr 5a:77:95:4e:8f:61
UP BROADCAST RUNNING NOARP SLAVE MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:403 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:0 (0.0 B) TX bytes:39290 (38.3 KiB)
Avatar
essomba84
On 24/02/2012 22:37, Pascal Hambourg wrote:
essomba84 a écrit :
On 24/02/2012 20:41, Pascal Hambourg wrote:

J'avais suggéré d'agréger les deux liens à 512 Mbit/s, puis d'agréger le
bonding résultant avec le lien à 1 Mbit/s dans un second bonding.




ben oui, c'est une bonne idée sauf que ifenslave refuse une interface
slave de type bond... Ou alors je m'y prends mal...



Que se passe-t-il ?
Je viens de tester sur une Debian Squeeze avec trois interfaces dummy,
ça a l'air de marcher.




(snip)

Bah moi ça me dit :

endpoint:/tmp# ifenslave bond1 bond0 tap3
Master 'bond1', Slave 'bond0': Error: Enslave failed

Sinon j'ai eu une autre idée : je crée 2 VPN sur l'interface deux fois
plus rapide et j'agrège 4 liens. J'arrive donc à avoir un débit qui est
la somme des 3 débits de FAI mais malhreusement ça reste très très
instable... Une idée de pourquoi ?

Merci,

Laurent
Avatar
Pascal Hambourg
essomba84 a écrit :
On 24/02/2012 22:37, Pascal Hambourg wrote:
essomba84 a écrit :



ben oui, c'est une bonne idée sauf que ifenslave refuse une interface
slave de type bond... Ou alors je m'y prends mal...


Que se passe-t-il ?
Je viens de tester sur une Debian Squeeze avec trois interfaces dummy,
ça a l'air de marcher.



Bah moi ça me dit :

endpoint:/tmp# ifenslave bond1 bond0 tap3
Master 'bond1', Slave 'bond0': Error: Enslave failed



Quelle distribution/version/noyau ?

Sinon j'ai eu une autre idée : je crée 2 VPN sur l'interface deux fois
plus rapide et j'agrège 4 liens.



Bien vu.

J'arrive donc à avoir un débit qui est
la somme des 3 débits de FAI mais malhreusement ça reste très très
instable... Une idée de pourquoi ?



Non, à part que ça doit être lié au comportement de TCP. Quelle est la
forme, la périodicité et l'amplitude de la variation de débit ?
Y a-t-il une grosse différence de latence entre les liaisons Wimax et
ADSL ? Dans ce cas, il y a peut-être un effet lié à la réception dans le
désordre, et augmenter la valeur de tcp_reordering pourrait aider.
Avatar
essomba84
On 25/02/2012 01:29, Pascal Hambourg wrote:


Quelle distribution/version/noyau ?



debian sid, noyau 3.2.0-1-amd64


Sinon j'ai eu une autre idée : je crée 2 VPN sur l'interface deux fois
plus rapide et j'agrège 4 liens.



Bien vu.

J'arrive donc à avoir un débit qui est
la somme des 3 débits de FAI mais malhreusement ça reste très très
instable... Une idée de pourquoi ?



Non, à part que ça doit être lié au comportement de TCP. Quelle est la
forme, la périodicité et l'amplitude de la variation de débit ?



je n'ai pas de graphique. Mais les variations vont de 170ko/s à 35 en
l'espace de 3s puis ça met une dizaine de seconde à remonter vers 170.
Et en permanence sur un fichier de 5Mo.


Y a-t-il une grosse différence de latence entre les liaisons Wimax et
ADSL ? Dans ce cas, il y a peut-être un effet lié à la réception dans le
désordre, et augmenter la valeur de tcp_reordering pourrait aider.



en gros sur la ligne adsl je ping ma passerelle en 200ms et en wimax en
260ms. Il est clair que le problème viens de l'agrégation avec la ligne
ADSL. En fait j'ai 109ko/s stable en agrégeant les deux wimax. Dès que
je mets la ligne ADSL, ça commence à faire n'importe quoi alors que
seule, elle est à 119ko/s stable...

Je dois changer la valeur de tcp_reordering à quel niveau ? la machine
locale ou la machine distante ? les deux ? sur quelle interface ? celles
des VPN ? celles de sorties ? celle du bond ?

Merci,

Laurent
Avatar
Pascal Hambourg
essomba84 a écrit :
On 25/02/2012 01:29, Pascal Hambourg wrote:

Quelle distribution/version/noyau ?



debian sid, noyau 3.2.0-1-amd64



J'ai pas sous la main, mais j'essaierai de regarder si un changement
peut expliquer ça.

>> J'arrive donc à avoir un débit qui est
>> la somme des 3 débits de FAI mais malhreusement ça reste très très
>> instable... Une idée de pourquoi ?
>
> Non, à part que ça doit être lié au comportement de TCP. Quelle est la
> forme, la périodicité et l'amplitude de la variation de débit ?

je n'ai pas de graphique. Mais les variations vont de 170ko/s à 35 en
l'espace de 3s puis ça met une dizaine de seconde à remonter vers 170.
Et en permanence sur un fichier de 5Mo.



En dents de scie, donc. Comme lors d'une perte de paquets importante,
TCP réduit brusquement le débit puis augmente progressivement.

en gros sur la ligne adsl je ping ma passerelle en 200ms et en wimax en
260ms. Il est clair que le problème viens de l'agrégation avec la ligne
ADSL. En fait j'ai 109ko/s stable en agrégeant les deux wimax. Dès que
je mets la ligne ADSL, ça commence à faire n'importe quoi alors que
seule, elle est à 119ko/s stable...

Je dois changer la valeur de tcp_reordering à quel niveau ? la machine
locale ou la machine distante ? les deux ? sur quelle interface ? celles
des VPN ? celles de sorties ? celle du bond ?



Sur la machine finale qui reçoit le fichier puisque c'est elle qui fait
la remise dans l'ordre des segments TCP. Ce paramètre n'est pas lié à
une interface particulière (sysctl net.ipv4.tcp_reordering).
Avatar
Tonton Th
On 02/24/2012 08:41 PM, Pascal Hambourg wrote:

- liens 1 et 2 : 512 kb/s ;
- lien 3 : 1 M/s.

Sinon comment pourrais-je exploiter complètement le lien le plus rapide ?



J'avais suggéré d'agréger les deux liens à 512 Mbit/s, puis d'agréger le
bonding résultant avec le lien à 1 Mbit/s dans un second bonding.



Question idiote : en mettant deux tunnels dans le lien rapide,
ça ne pourrait pas assurer aussi le bon remplissage, puisque
les quatres seraient identiques ?

--

Nous vivons dans un monde étrange/
http://foo.bar.quux.over-blog.com/
Avatar
essomba84
On 25/02/2012 12:36, Tonton Th wrote:
On 02/24/2012 08:41 PM, Pascal Hambourg wrote:

- liens 1 et 2 : 512 kb/s ;
- lien 3 : 1 M/s.





Sinon comment pourrais-je exploiter complètement le lien le plus
rapide ?



J'avais suggéré d'agréger les deux liens à 512 Mbit/s, puis d'agréger le
bonding résultant avec le lien à 1 Mbit/s dans un second bonding.



Question idiote : en mettant deux tunnels dans le lien rapide,
ça ne pourrait pas assurer aussi le bon remplissage, puisque
les quatres seraient identiques ?




bonjour,

je l'ai déjà fait (voire message ci-dessus). Le problème que je remarque
est que lorsqu'on agrège deux liens de qualité différentes (ici avec des
temps d'accès différents), le bonding ne fonctionne pas bien...

L
Avatar
essomba84
On 25/02/2012 11:04, Pascal Hambourg wrote:
essomba84 a écrit :
On 25/02/2012 01:29, Pascal Hambourg wrote:

Quelle distribution/version/noyau ?



debian sid, noyau 3.2.0-1-amd64



J'ai pas sous la main, mais j'essaierai de regarder si un changement
peut expliquer ça.

>> J'arrive donc à avoir un débit qui est
>> la somme des 3 débits de FAI mais malhreusement ça reste très très
>> instable... Une idée de pourquoi ?
>
> Non, à part que ça doit être lié au comportement de TCP. Quelle est la
> forme, la périodicité et l'amplitude de la variation de débit ?

je n'ai pas de graphique. Mais les variations vont de 170ko/s à 35 en
l'espace de 3s puis ça met une dizaine de seconde à remonter vers 170.
Et en permanence sur un fichier de 5Mo.



En dents de scie, donc. Comme lors d'une perte de paquets importante,
TCP réduit brusquement le débit puis augmente progressivement.



y a des moyens de voir ce qui se passe ? ou les paquets se perdent ?
pourquoi ? combien ?

Merci,

L
1 2 3