voici rapidement mon problème. Je possède 3 passerelle internet, une à
2Mbit/s les deux autres à 1M chacune.
Je voudrais:
- aggréger les débit des 2 à 1M pour faire 2M,
- me servir de cet aggrégat dans le cas où la première connexion tombe.
Comment feriez-vous ? J'ai regardé du côté du
"bonding"(http://www.linuxfoundation.org/collaborate/workgroups/networking/bonding)
mais apparemment ça s'applique à des liens ethernet et pas des liens IP.
je me réponds à moi même. Donc hier, j'ai monté mes 3 liens VPN en mode bridged (interfaces TAP). Je les ai ensuite aggrégés grâce au module bonding, en mode 0 (round robing). J'ai testé et, apparemment, les liens sont aggrégés car j'ai la somme des débits sur un même téléchargement, à priori, mono-thread (wget).
Est-ce normal ?
Pour ma part oui, tu as agrégé 3 liens ethernet ce qui donne le résultat attendu.
Tu dois juste ne pas avoir la somme exacte des debits disponibles du fait des encapsulations empilées.
La bonne surprise est que je ne m'attendais pas à le bonding puisse utiliser des interfaces tap.
-- JFM> Au royaume des aveugles le borgne est roi
Au royaume des aveugles les borgnes sont mal vus.
-+- TP in Guide du Neuneu Usenet : Tu t'es vu quand tu fufes -+-
Essomba <essomba421@yahou.com.invalid> writes:
'Lut,
je me réponds à moi même. Donc hier, j'ai monté mes 3 liens VPN en mode
bridged (interfaces TAP). Je les ai ensuite aggrégés grâce au module
bonding, en mode 0 (round robing). J'ai testé et, apparemment, les liens
sont aggrégés car j'ai la somme des débits sur un même téléchargement, à
priori, mono-thread (wget).
Est-ce normal ?
Pour ma part oui, tu as agrégé 3 liens ethernet ce qui donne le résultat
attendu.
Tu dois juste ne pas avoir la somme exacte des debits disponibles du
fait des encapsulations empilées.
La bonne surprise est que je ne m'attendais pas à le bonding puisse
utiliser des interfaces tap.
--
JFM> Au royaume des aveugles le borgne est roi
Au royaume des aveugles les borgnes sont mal vus.
-+- TP in Guide du Neuneu Usenet : Tu t'es vu quand tu fufes -+-
je me réponds à moi même. Donc hier, j'ai monté mes 3 liens VPN en mode bridged (interfaces TAP). Je les ai ensuite aggrégés grâce au module bonding, en mode 0 (round robing). J'ai testé et, apparemment, les liens sont aggrégés car j'ai la somme des débits sur un même téléchargement, à priori, mono-thread (wget).
Est-ce normal ?
Pour ma part oui, tu as agrégé 3 liens ethernet ce qui donne le résultat attendu.
Tu dois juste ne pas avoir la somme exacte des debits disponibles du fait des encapsulations empilées.
La bonne surprise est que je ne m'attendais pas à le bonding puisse utiliser des interfaces tap.
-- JFM> Au royaume des aveugles le borgne est roi
Au royaume des aveugles les borgnes sont mal vus.
-+- TP in Guide du Neuneu Usenet : Tu t'es vu quand tu fufes -+-
Pascal Hambourg
Eric Masson a écrit :
Pascal Hambourg writes:
Tu as une route multipath avec plusieurs liens IP, et tu envoies une part du trafic IP sur chaque lien en proportion de sa capacité.
Donc, si on se place dans un contexte linux, via quelque chose de ce type (extrait LARTC) : ip route add default scope global nexthop via $P1 dev $IF1 weight 1 nexthop via $P2 dev $IF2 weight 1
En jouant sur les paramètres weight pour la répartition, je suppose ?
Presque, car le cache de routage s'en mêle et la répartition se fait par "flux" (couple source-destination) et non par paquet individuel. Pour que la répartition se fasse paquet par paquet il y a l'option "equalize", mais il semble que le patch nécessaire n'ait jamais été inclus dans le noyau officiel.
Cela fonctionne certainement, mais c'est du load balancing, pas de l'agrégation au niveau lien, non ?
Je ne vois pas la différence. Le but de l'agrégation est bien d'apporter l'équilibrage de charge (et/ou la redondance), non ?
Tu as une route multipath avec plusieurs liens IP, et tu envoies une
part du trafic IP sur chaque lien en proportion de sa capacité.
Donc, si on se place dans un contexte linux, via quelque chose de ce
type (extrait LARTC) :
ip route add default scope global nexthop via $P1 dev $IF1 weight 1
nexthop via $P2 dev $IF2 weight 1
En jouant sur les paramètres weight pour la répartition, je suppose ?
Presque, car le cache de routage s'en mêle et la répartition se fait par
"flux" (couple source-destination) et non par paquet individuel. Pour
que la répartition se fasse paquet par paquet il y a l'option
"equalize", mais il semble que le patch nécessaire n'ait jamais été
inclus dans le noyau officiel.
Cela fonctionne certainement, mais c'est du load balancing, pas de
l'agrégation au niveau lien, non ?
Je ne vois pas la différence. Le but de l'agrégation est bien d'apporter
l'équilibrage de charge (et/ou la redondance), non ?
Tu as une route multipath avec plusieurs liens IP, et tu envoies une part du trafic IP sur chaque lien en proportion de sa capacité.
Donc, si on se place dans un contexte linux, via quelque chose de ce type (extrait LARTC) : ip route add default scope global nexthop via $P1 dev $IF1 weight 1 nexthop via $P2 dev $IF2 weight 1
En jouant sur les paramètres weight pour la répartition, je suppose ?
Presque, car le cache de routage s'en mêle et la répartition se fait par "flux" (couple source-destination) et non par paquet individuel. Pour que la répartition se fasse paquet par paquet il y a l'option "equalize", mais il semble que le patch nécessaire n'ait jamais été inclus dans le noyau officiel.
Cela fonctionne certainement, mais c'est du load balancing, pas de l'agrégation au niveau lien, non ?
Je ne vois pas la différence. Le but de l'agrégation est bien d'apporter l'équilibrage de charge (et/ou la redondance), non ?
Pascal Hambourg
Eric Masson a écrit :
Essomba writes:
je me réponds à moi même. Donc hier, j'ai monté mes 3 liens VPN en mode bridged (interfaces TAP). Je les ai ensuite aggrégés grâce au module bonding, en mode 0 (round robing). J'ai testé et, apparemment, les liens sont aggrégés car j'ai la somme des débits sur un même téléchargement, à priori, mono-thread (wget).
Est-ce normal ?
Pour ma part oui, tu as agrégé 3 liens ethernet ce qui donne le résultat attendu.
Tu dois juste ne pas avoir la somme exacte des debits disponibles du fait des encapsulations empilées.
Sauf erreur, avec du round-robin non pondéré le lien à 2 Mbit/s devrait être sous-utilisé à 1 Mbit/s. En toute rigueur il faudrait créer une première agrégation avec les deux 1 Mbit et l'agréger avec la 2 Mbit/s.
La bonne surprise est que je ne m'attendais pas à le bonding puisse utiliser des interfaces tap.
Il n'y a pas de raison puisque ces interfaces sont vues comme des interfaces ethernet.
Eric Masson a écrit :
Essomba <essomba421@yahou.com.invalid> writes:
je me réponds à moi même. Donc hier, j'ai monté mes 3 liens VPN en mode
bridged (interfaces TAP). Je les ai ensuite aggrégés grâce au module
bonding, en mode 0 (round robing). J'ai testé et, apparemment, les liens
sont aggrégés car j'ai la somme des débits sur un même téléchargement, à
priori, mono-thread (wget).
Est-ce normal ?
Pour ma part oui, tu as agrégé 3 liens ethernet ce qui donne le résultat
attendu.
Tu dois juste ne pas avoir la somme exacte des debits disponibles du
fait des encapsulations empilées.
Sauf erreur, avec du round-robin non pondéré le lien à 2 Mbit/s devrait
être sous-utilisé à 1 Mbit/s. En toute rigueur il faudrait créer une
première agrégation avec les deux 1 Mbit et l'agréger avec la 2 Mbit/s.
La bonne surprise est que je ne m'attendais pas à le bonding puisse
utiliser des interfaces tap.
Il n'y a pas de raison puisque ces interfaces sont vues comme des
interfaces ethernet.
je me réponds à moi même. Donc hier, j'ai monté mes 3 liens VPN en mode bridged (interfaces TAP). Je les ai ensuite aggrégés grâce au module bonding, en mode 0 (round robing). J'ai testé et, apparemment, les liens sont aggrégés car j'ai la somme des débits sur un même téléchargement, à priori, mono-thread (wget).
Est-ce normal ?
Pour ma part oui, tu as agrégé 3 liens ethernet ce qui donne le résultat attendu.
Tu dois juste ne pas avoir la somme exacte des debits disponibles du fait des encapsulations empilées.
Sauf erreur, avec du round-robin non pondéré le lien à 2 Mbit/s devrait être sous-utilisé à 1 Mbit/s. En toute rigueur il faudrait créer une première agrégation avec les deux 1 Mbit et l'agréger avec la 2 Mbit/s.
La bonne surprise est que je ne m'attendais pas à le bonding puisse utiliser des interfaces tap.
Il n'y a pas de raison puisque ces interfaces sont vues comme des interfaces ethernet.
Damien Wyart
* Pascal Hambourg in fr.comp.reseaux.ip:
Presque, car le cache de routage s'en mêle et la répartition se fait par "flux" (couple source-destination) et non par paquet individuel. Pour que la répartition se fasse paquet par paquet il y a l'option "equalize", mais il semble que le patch nécessaire n'ait jamais été inclus dans le noyau officiel.
En effet. Il y a quelques détails ici : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug9897
-- DW
* Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> in fr.comp.reseaux.ip:
Presque, car le cache de routage s'en mêle et la répartition se fait
par "flux" (couple source-destination) et non par paquet individuel.
Pour que la répartition se fasse paquet par paquet il y a l'option
"equalize", mais il semble que le patch nécessaire n'ait jamais été
inclus dans le noyau officiel.
En effet. Il y a quelques détails ici :
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug9897
Presque, car le cache de routage s'en mêle et la répartition se fait par "flux" (couple source-destination) et non par paquet individuel. Pour que la répartition se fasse paquet par paquet il y a l'option "equalize", mais il semble que le patch nécessaire n'ait jamais été inclus dans le noyau officiel.
En effet. Il y a quelques détails ici : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug9897
-- DW
essomba84
On 20/12/2011 11:08, Essomba wrote:
On 19/12/2011 22:32, essomba84 wrote:
Bonjour,
je suis le PO sur fcolc.
Mon problème était le suivant : j'ai une ligne à 2Mbits en ADSL et 2 lignes en wimax à 1M chacune.
Je *voudrais* le schéma suivant :
client 1 LAN --+ +--eth1--WMAX--+ | | | client 2 LAN --+-switch--debian(OVPN)+--eth0--ADSL--+(OVPN)debian--Web | | | client 3 LAN --+ +--eth2--WMAX--+
avec si possible une aggrégation de lien sur eth1 et eth2 qui seraient en secours de eth0.
Bonjour,
je me réponds à moi même. Donc hier, j'ai monté mes 3 liens VPN en mode bridged (interfaces TAP). Je les ai ensuite aggrégés grâce au module bonding, en mode 0 (round robing). J'ai testé et, apparemment, les liens sont aggrégés car j'ai la somme des débits sur un même téléchargement, à priori, mono-thread (wget).
Est-ce normal ? Je me l'explique en disant qu'en "bondant" les liens TAP j'ai bondé en fait 3 réseau ethernet en un seul et que donc au niveau IP c'est transparent, les paquets peuvent passer par un lien ou un autre. Est-ce bon ?
Merci !
je me réponds encore à moi même. Vous allez dire que je suis torturé de la tête :) Je ne comprends pas comment les débits sont aggrégés en download. En upload, c'est clair, on envoie un paquet sur un lien puis un paquet sur l'autre. On a donc bien le double (à quelque chose près) du débit. Mais en download qui envoie un paquet sur un lien puis sur l'autre ? Comment aggréger les débit en download ? Sachant que le mode 6 (alb) ne fonctionne pas car on ne peut pas changer les adresses MAC des interfaces TAP sans en faire un down.
Merci !
On 20/12/2011 11:08, Essomba wrote:
On 19/12/2011 22:32, essomba84 wrote:
Bonjour,
je suis le PO sur fcolc.
Mon problème était le suivant : j'ai une ligne à 2Mbits en ADSL et 2
lignes en wimax à 1M chacune.
Je *voudrais* le schéma suivant :
client 1 LAN --+ +--eth1--WMAX--+
| | |
client 2 LAN --+-switch--debian(OVPN)+--eth0--ADSL--+(OVPN)debian--Web
| | |
client 3 LAN --+ +--eth2--WMAX--+
avec si possible une aggrégation de lien sur eth1 et eth2 qui seraient
en secours de eth0.
Bonjour,
je me réponds à moi même. Donc hier, j'ai monté mes 3 liens VPN en mode
bridged (interfaces TAP). Je les ai ensuite aggrégés grâce au module
bonding, en mode 0 (round robing). J'ai testé et, apparemment, les liens
sont aggrégés car j'ai la somme des débits sur un même téléchargement, à
priori, mono-thread (wget).
Est-ce normal ? Je me l'explique en disant qu'en "bondant" les liens TAP
j'ai bondé en fait 3 réseau ethernet en un seul et que donc au niveau IP
c'est transparent, les paquets peuvent passer par un lien ou un autre.
Est-ce bon ?
Merci !
je me réponds encore à moi même. Vous allez dire que je suis torturé de
la tête :) Je ne comprends pas comment les débits sont aggrégés en
download. En upload, c'est clair, on envoie un paquet sur un lien puis
un paquet sur l'autre. On a donc bien le double (à quelque chose près)
du débit. Mais en download qui envoie un paquet sur un lien puis sur
l'autre ? Comment aggréger les débit en download ? Sachant que le mode 6
(alb) ne fonctionne pas car on ne peut pas changer les adresses MAC des
interfaces TAP sans en faire un down.
Mon problème était le suivant : j'ai une ligne à 2Mbits en ADSL et 2 lignes en wimax à 1M chacune.
Je *voudrais* le schéma suivant :
client 1 LAN --+ +--eth1--WMAX--+ | | | client 2 LAN --+-switch--debian(OVPN)+--eth0--ADSL--+(OVPN)debian--Web | | | client 3 LAN --+ +--eth2--WMAX--+
avec si possible une aggrégation de lien sur eth1 et eth2 qui seraient en secours de eth0.
Bonjour,
je me réponds à moi même. Donc hier, j'ai monté mes 3 liens VPN en mode bridged (interfaces TAP). Je les ai ensuite aggrégés grâce au module bonding, en mode 0 (round robing). J'ai testé et, apparemment, les liens sont aggrégés car j'ai la somme des débits sur un même téléchargement, à priori, mono-thread (wget).
Est-ce normal ? Je me l'explique en disant qu'en "bondant" les liens TAP j'ai bondé en fait 3 réseau ethernet en un seul et que donc au niveau IP c'est transparent, les paquets peuvent passer par un lien ou un autre. Est-ce bon ?
Merci !
je me réponds encore à moi même. Vous allez dire que je suis torturé de la tête :) Je ne comprends pas comment les débits sont aggrégés en download. En upload, c'est clair, on envoie un paquet sur un lien puis un paquet sur l'autre. On a donc bien le double (à quelque chose près) du débit. Mais en download qui envoie un paquet sur un lien puis sur l'autre ? Comment aggréger les débit en download ? Sachant que le mode 6 (alb) ne fonctionne pas car on ne peut pas changer les adresses MAC des interfaces TAP sans en faire un down.
Merci !
Stephane Le Men
On 12/21/2011 09:59 AM, essomba84 wrote:
je me réponds encore à moi même. Vous allez dire que je suis torturé de la tête :)
non non
Je ne comprends pas comment les débits sont aggrégés en download. En upload, c'est clair, on envoie un paquet sur un lien puis un paquet sur l'autre. On a donc bien le double (à quelque chose près) du débit. Mais en download qui envoie un paquet sur un lien puis sur l'autre ? Comment aggréger les débit en download ?
Quand on en est là, on remarque que d'un coté il y un bond de 3 tap, et de l'autre, il y a 1 seul tap, géré par un seul démon openvpn. C'est bien ça ?
Si c'est ça, et qu'on a déjà fait un bond sur du lan, et qui marche, on sait qu'un bond en face un autre truc qui n'est pas "bond", ça marche moyen, enfin, bien que dans un sens.
Le mieux, c'est de mettre une interface bond en face d'une autre interface bond, pour que ça marche comme avec des câbles croisés d'une vrai conf bond sur ethernet, bien dans les deux sens.
Il faut donc un serveur openvpn par client openvpn, pour avoir autant d'interfaces à bonder de chaque coté, si tu utilises le bond ethernet en mode "câbles croisés"
On 12/21/2011 09:59 AM, essomba84 wrote:
je me réponds encore à moi même. Vous allez dire que je suis torturé de
la tête :)
non non
Je ne comprends pas comment les débits sont aggrégés en
download. En upload, c'est clair, on envoie un paquet sur un lien puis
un paquet sur l'autre. On a donc bien le double (à quelque chose près)
du débit. Mais en download qui envoie un paquet sur un lien puis sur
l'autre ? Comment aggréger les débit en download ?
Quand on en est là, on remarque que d'un coté il y un bond de 3 tap, et
de l'autre, il y a 1 seul tap, géré par un seul démon openvpn.
C'est bien ça ?
Si c'est ça, et qu'on a déjà fait un bond sur du lan, et qui marche, on
sait qu'un bond en face un autre truc qui n'est pas "bond", ça marche
moyen, enfin, bien que dans un sens.
Le mieux, c'est de mettre une interface bond en face d'une autre
interface bond, pour que ça marche comme avec des câbles croisés d'une
vrai conf bond sur ethernet, bien dans les deux sens.
Il faut donc un serveur openvpn par client openvpn, pour avoir autant
d'interfaces à bonder de chaque coté, si tu utilises le bond ethernet en
mode "câbles croisés"
je me réponds encore à moi même. Vous allez dire que je suis torturé de la tête :)
non non
Je ne comprends pas comment les débits sont aggrégés en download. En upload, c'est clair, on envoie un paquet sur un lien puis un paquet sur l'autre. On a donc bien le double (à quelque chose près) du débit. Mais en download qui envoie un paquet sur un lien puis sur l'autre ? Comment aggréger les débit en download ?
Quand on en est là, on remarque que d'un coté il y un bond de 3 tap, et de l'autre, il y a 1 seul tap, géré par un seul démon openvpn. C'est bien ça ?
Si c'est ça, et qu'on a déjà fait un bond sur du lan, et qui marche, on sait qu'un bond en face un autre truc qui n'est pas "bond", ça marche moyen, enfin, bien que dans un sens.
Le mieux, c'est de mettre une interface bond en face d'une autre interface bond, pour que ça marche comme avec des câbles croisés d'une vrai conf bond sur ethernet, bien dans les deux sens.
Il faut donc un serveur openvpn par client openvpn, pour avoir autant d'interfaces à bonder de chaque coté, si tu utilises le bond ethernet en mode "câbles croisés"
Pascal Hambourg
Stephane Le Men a écrit :
On 12/21/2011 09:59 AM, essomba84 wrote:
Je ne comprends pas comment les débits sont aggrégés en download. En upload, c'est clair, on envoie un paquet sur un lien puis un paquet sur l'autre. On a donc bien le double (à quelque chose près) du débit. Mais en download qui envoie un paquet sur un lien puis sur l'autre ? Comment aggréger les débit en download ?
Quand on en est là, on remarque que d'un coté il y un bond de 3 tap, et de l'autre, il y a 1 seul tap, géré par un seul démon openvpn. C'est bien ça ?
Openvpn utilise une même et unique interface tap pour tous les tunnels ?
Si c'est ça, et qu'on a déjà fait un bond sur du lan, et qui marche, on sait qu'un bond en face un autre truc qui n'est pas "bond", ça marche moyen, enfin, bien que dans un sens.
Le mieux, c'est de mettre une interface bond en face d'une autre interface bond
C'est bien ce que j'avais suggéré : bonding des deux côtés. Ce qui suppose une interface tap par tunnel de chaque côté.
Stephane Le Men a écrit :
On 12/21/2011 09:59 AM, essomba84 wrote:
Je ne comprends pas comment les débits sont aggrégés en
download. En upload, c'est clair, on envoie un paquet sur un lien puis
un paquet sur l'autre. On a donc bien le double (à quelque chose près)
du débit. Mais en download qui envoie un paquet sur un lien puis sur
l'autre ? Comment aggréger les débit en download ?
Quand on en est là, on remarque que d'un coté il y un bond de 3 tap, et
de l'autre, il y a 1 seul tap, géré par un seul démon openvpn.
C'est bien ça ?
Openvpn utilise une même et unique interface tap pour tous les tunnels ?
Si c'est ça, et qu'on a déjà fait un bond sur du lan, et qui marche, on
sait qu'un bond en face un autre truc qui n'est pas "bond", ça marche
moyen, enfin, bien que dans un sens.
Le mieux, c'est de mettre une interface bond en face d'une autre
interface bond
C'est bien ce que j'avais suggéré : bonding des deux côtés. Ce qui
suppose une interface tap par tunnel de chaque côté.
Je ne comprends pas comment les débits sont aggrégés en download. En upload, c'est clair, on envoie un paquet sur un lien puis un paquet sur l'autre. On a donc bien le double (à quelque chose près) du débit. Mais en download qui envoie un paquet sur un lien puis sur l'autre ? Comment aggréger les débit en download ?
Quand on en est là, on remarque que d'un coté il y un bond de 3 tap, et de l'autre, il y a 1 seul tap, géré par un seul démon openvpn. C'est bien ça ?
Openvpn utilise une même et unique interface tap pour tous les tunnels ?
Si c'est ça, et qu'on a déjà fait un bond sur du lan, et qui marche, on sait qu'un bond en face un autre truc qui n'est pas "bond", ça marche moyen, enfin, bien que dans un sens.
Le mieux, c'est de mettre une interface bond en face d'une autre interface bond
C'est bien ce que j'avais suggéré : bonding des deux côtés. Ce qui suppose une interface tap par tunnel de chaque côté.
essomba84
On 21/12/2011 20:19, Pascal Hambourg wrote:
Openvpn utilise une même et unique interface tap pour tous les tunnels ?
apparemment oui. Il y a une interface tap qui apparaît et qui est celle qui correspond au serveur.
Si c'est ça, et qu'on a déjà fait un bond sur du lan, et qui marche, on sait qu'un bond en face un autre truc qui n'est pas "bond", ça marche moyen, enfin, bien que dans un sens.
Le mieux, c'est de mettre une interface bond en face d'une autre interface bond
C'est bien ce que j'avais suggéré : bonding des deux côtés. Ce qui suppose une interface tap par tunnel de chaque côté.
voilà. Et le problème c'est que je ne sais pas comment avoir une interface tap par client...
On 21/12/2011 20:19, Pascal Hambourg wrote:
Openvpn utilise une même et unique interface tap pour tous les tunnels ?
apparemment oui. Il y a une interface tap qui apparaît et qui est celle
qui correspond au serveur.
Si c'est ça, et qu'on a déjà fait un bond sur du lan, et qui marche, on
sait qu'un bond en face un autre truc qui n'est pas "bond", ça marche
moyen, enfin, bien que dans un sens.
Le mieux, c'est de mettre une interface bond en face d'une autre
interface bond
C'est bien ce que j'avais suggéré : bonding des deux côtés. Ce qui
suppose une interface tap par tunnel de chaque côté.
voilà. Et le problème c'est que je ne sais pas comment avoir une
interface tap par client...
Openvpn utilise une même et unique interface tap pour tous les tunnels ?
apparemment oui. Il y a une interface tap qui apparaît et qui est celle qui correspond au serveur.
Si c'est ça, et qu'on a déjà fait un bond sur du lan, et qui marche, on sait qu'un bond en face un autre truc qui n'est pas "bond", ça marche moyen, enfin, bien que dans un sens.
Le mieux, c'est de mettre une interface bond en face d'une autre interface bond
C'est bien ce que j'avais suggéré : bonding des deux côtés. Ce qui suppose une interface tap par tunnel de chaque côté.
voilà. Et le problème c'est que je ne sais pas comment avoir une interface tap par client...
essomba84
On 21/12/2011 16:31, Stephane Le Men wrote:
Quand on en est là, on remarque que d'un coté il y un bond de 3 tap, et de l'autre, il y a 1 seul tap, géré par un seul démon openvpn. C'est bien ça ?
oui.
Si c'est ça, et qu'on a déjà fait un bond sur du lan, et qui marche, on sait qu'un bond en face un autre truc qui n'est pas "bond", ça marche moyen, enfin, bien que dans un sens.
bon quelque part ce qui m'intéresse surtout c'est l'aggrégation de débit en voie montante. Et ça, ça marche bien :) J'ai mis le bonding en mode 5 (balance-tlb <=> répartition de la charge par lien).
Le mieux, c'est de mettre une interface bond en face d'une autre interface bond, pour que ça marche comme avec des câbles croisés d'une vrai conf bond sur ethernet, bien dans les deux sens.
Il faut donc un serveur openvpn par client openvpn, pour avoir autant d'interfaces à bonder de chaque coté, si tu utilises le bond ethernet en mode "câbles croisés"
il y a un truc qui me perturbe avec openvpn. On dirait qu'il gère le switch de lui même : il reçoit les connexion des clients, il présente une interface tap sur le serveur. On ne peut donc pas utiliser les outils bridge classiques. Sinon on pourrait peut être simuler un bridge 802.3ad...
Des liens qui expliquent comment fonctionne openvpn en mode ethernet bridged ?
Merci
On 21/12/2011 16:31, Stephane Le Men wrote:
Quand on en est là, on remarque que d'un coté il y un bond de 3 tap, et
de l'autre, il y a 1 seul tap, géré par un seul démon openvpn.
C'est bien ça ?
oui.
Si c'est ça, et qu'on a déjà fait un bond sur du lan, et qui marche, on
sait qu'un bond en face un autre truc qui n'est pas "bond", ça marche
moyen, enfin, bien que dans un sens.
bon quelque part ce qui m'intéresse surtout c'est l'aggrégation de débit
en voie montante. Et ça, ça marche bien :) J'ai mis le bonding en mode 5
(balance-tlb <=> répartition de la charge par lien).
Le mieux, c'est de mettre une interface bond en face d'une autre
interface bond, pour que ça marche comme avec des câbles croisés d'une
vrai conf bond sur ethernet, bien dans les deux sens.
Il faut donc un serveur openvpn par client openvpn, pour avoir autant
d'interfaces à bonder de chaque coté, si tu utilises le bond ethernet en
mode "câbles croisés"
il y a un truc qui me perturbe avec openvpn. On dirait qu'il gère le
switch de lui même : il reçoit les connexion des clients, il présente
une interface tap sur le serveur. On ne peut donc pas utiliser les
outils bridge classiques. Sinon on pourrait peut être simuler un bridge
802.3ad...
Des liens qui expliquent comment fonctionne openvpn en mode ethernet
bridged ?
Quand on en est là, on remarque que d'un coté il y un bond de 3 tap, et de l'autre, il y a 1 seul tap, géré par un seul démon openvpn. C'est bien ça ?
oui.
Si c'est ça, et qu'on a déjà fait un bond sur du lan, et qui marche, on sait qu'un bond en face un autre truc qui n'est pas "bond", ça marche moyen, enfin, bien que dans un sens.
bon quelque part ce qui m'intéresse surtout c'est l'aggrégation de débit en voie montante. Et ça, ça marche bien :) J'ai mis le bonding en mode 5 (balance-tlb <=> répartition de la charge par lien).
Le mieux, c'est de mettre une interface bond en face d'une autre interface bond, pour que ça marche comme avec des câbles croisés d'une vrai conf bond sur ethernet, bien dans les deux sens.
Il faut donc un serveur openvpn par client openvpn, pour avoir autant d'interfaces à bonder de chaque coté, si tu utilises le bond ethernet en mode "câbles croisés"
il y a un truc qui me perturbe avec openvpn. On dirait qu'il gère le switch de lui même : il reçoit les connexion des clients, il présente une interface tap sur le serveur. On ne peut donc pas utiliser les outils bridge classiques. Sinon on pourrait peut être simuler un bridge 802.3ad...
Des liens qui expliquent comment fonctionne openvpn en mode ethernet bridged ?
Merci
Stephane Le Men
On 12/21/2011 08:19 PM, Pascal Hambourg wrote:
Openvpn utilise une même et unique interface tap pour tous les tunnels ?
Oui, c'est pour cela que l'agrégation ne se fait quand dans un seul sens du coté client, seulement où il y a le bond. Openvpn fait du vpn, pas du bl, et selon le sens du trafic, il ne passent pas dans les mêmes pipes. Il faut que la conf "bond" soit symétrique pour que l'effet "bond" soit symétrique.
Et cela marche sans l'avis des SFR/Bouygues/FT/Free, pas besoin de lever le doigt et demander leur permission pour se faire nater ou router chez Gandi ou Ovh au travers d'un agrégat de liens chez chacun.
Problème, tu payes trois fois le trafic, une fois sur le dsl, deux fois entrée et sortie chez l'hébergeur. Mais c'est nomal, c'est un service d'opérateur que tu viens de créer, tu prends en charge les coûts de ton réseau.
On 12/21/2011 08:19 PM, Pascal Hambourg wrote:
Openvpn utilise une même et unique interface tap pour tous les tunnels ?
Oui, c'est pour cela que l'agrégation ne se fait quand dans un seul sens
du coté client, seulement où il y a le bond. Openvpn fait du vpn, pas du
bl, et selon le sens du trafic, il ne passent pas dans les mêmes pipes.
Il faut que la conf "bond" soit symétrique pour que l'effet "bond" soit
symétrique.
Et cela marche sans l'avis des SFR/Bouygues/FT/Free, pas besoin de lever
le doigt et demander leur permission pour se faire nater ou router chez
Gandi ou Ovh au travers d'un agrégat de liens chez chacun.
Problème, tu payes trois fois le trafic, une fois sur le dsl, deux fois
entrée et sortie chez l'hébergeur. Mais c'est nomal, c'est un service
d'opérateur que tu viens de créer, tu prends en charge les coûts de ton
réseau.
Openvpn utilise une même et unique interface tap pour tous les tunnels ?
Oui, c'est pour cela que l'agrégation ne se fait quand dans un seul sens du coté client, seulement où il y a le bond. Openvpn fait du vpn, pas du bl, et selon le sens du trafic, il ne passent pas dans les mêmes pipes. Il faut que la conf "bond" soit symétrique pour que l'effet "bond" soit symétrique.
Et cela marche sans l'avis des SFR/Bouygues/FT/Free, pas besoin de lever le doigt et demander leur permission pour se faire nater ou router chez Gandi ou Ovh au travers d'un agrégat de liens chez chacun.
Problème, tu payes trois fois le trafic, une fois sur le dsl, deux fois entrée et sortie chez l'hébergeur. Mais c'est nomal, c'est un service d'opérateur que tu viens de créer, tu prends en charge les coûts de ton réseau.
