Aggrégation débit - IP fallback

On 12/21/2011 09:18 PM, essomba84 wrote:

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).

Il faut faire la même chose de l'autre coté, coté serveur et
l'agrégation marchera dans l'autre sens aussi. Pour lancer un serveur
openvpn par client, tu n'as qu'à dupliquer ta conf serveur et changer
l'ip (si elle est dispo sur ta machine) ou simplement le port d'écoute.

Avec des openvpn serveurs sur la même ip mais différents port udp/tcp,
tu seras obligé de router ton serveur avec le multi-table routing coté
client.

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...

Oui openvpn doit opérer un peu comme un switch quand il est configuré en
L2, à part qu'il n'aura jamais la même mac vers deux clients différents
alors que sur un switch tu peux avoir la même mac sur différents ports.

Des liens qui expliquent comment fonctionne openvpn en mode ethernet
bridged ?

Oublie cette histoire de bridge, la conf que tu veux faire c'est celle
d'un lien bond sur Ethernet virtuel. Le bridge, il est déjà implémenté
entre client et serveur, et optionnellement entre clients sur openvpn.

Pour agréger la bande passante entre deux machines avec plusieurs
interfaces sur un lan par des câbles croisés, tu ne vas pas utiliser le
bridge, ca va pas marcher. Alors, que les câbles croisés soit réel ou
virtuel, en terme fonctionnel cela ne change rien, c'est le module
d'agrégation bond qu'il faut utiliser.

Après, que le bond final sur interface Ethernet virtuel tap n'ait pas
exactement le même comportement, quand tu perds un lien par exemple, en
de temps de réponse, c'est normal, car les interfaces tap d'openvpn ne
sont pas de réelle interface Ethernet.

La simple disponibilité de cette config bond ne sera pas aussi simple à
faire marcher que l'agrégation, une des raisons étant que lorsqu'un
client se déconnecte du serveur, ce qui correspond à débrancher un câble
croisé dans une config bond réelle, l'interface du serveur openvpn ne
tombe pas comme sur ethernet. Alors que débrancher un câble sur un bond
réel peu chargé est transparent car il est immédiatement pris en compte
par le module bond des deux cotés, avec les interface tap d'openvpn cela
ne va pas se passer aussi simplement.

En fait le vrai job de cette conf est là, s'assurer que quand un client
vpn se déconnecte du serveur ou x ou y raisons, que cela ne foute pas la
grouille sur la totalité des sessions en cour. Si tu envoies 1 paquet
sur 3 dans un cul de sac, les applies au dessus vont avoir comme un
sifflet de coupé "erk erk erk" ça va faire à l'écran

Stephane Le Men a écrit :

Il faut faire la même chose de l'autre coté, coté serveur et
l'agrégation marchera dans l'autre sens aussi. Pour lancer un serveur
openvpn par client, tu n'as qu'à dupliquer ta conf serveur et changer
l'ip (si elle est dispo sur ta machine) ou simplement le port d'écoute.

Avec des openvpn serveurs sur la même ip mais différents port udp/tcp,
tu seras obligé de router ton serveur avec le multi-table routing coté
client.

Sauf erreur, c'est déjà ce qui a dû être fait dans la configuration
actuelle, car il faut bien que chaque tunnel passe par un lien différent
pour cumuler les débits vers le serveur. J'imagine que le plus simple
est en fixant l'adresse ou le port source dans la configuration de
chaque tunnel afin de s'en servir comme clé de routage.

Après, que le bond final sur interface Ethernet virtuel tap n'ait pas
exactement le même comportement, quand tu perds un lien par exemple, en
de temps de réponse, c'est normal, car les interfaces tap d'openvpn ne
sont pas de réelle interface Ethernet.

Openvpn ne fait pas tomber l'interface quand le tunnel tombe ?
Dans ce cas il reste la possibilité de faire la détection de panne par
surveillance d'ARP au lieu de surveillance de l'interface.

On 12/22/2011 08:34 PM, Pascal Hambourg wrote:

Sauf erreur, c'est déjà ce qui a dû être fait dans la configuration
actuelle, car il faut bien que chaque tunnel passe par un lien différent
pour cumuler les débits vers le serveur. J'imagine que le plus simple
est en fixant l'adresse ou le port source dans la configuration de
chaque tunnel afin de s'en servir comme clé de routage.

Il peut se passer du multi-table routing s'il DNAT plus loin sur les IAD
(les box) par exemple. Sans faire du DNAT, je ne vois pas comment le
faire sans multi-table.

Openvpn ne fait pas tomber l'interface quand le tunnel tombe ?

Sur le serveur, c'est interdit, les autres clients hurleraient au vol,
et coté client, mon expérience d'openvpn m'a montré qu'elle reste up.
Il y a peut être une conf spéciale qui la fait tomber, mais je connais pas.

Dans ce cas il reste la possibilité de faire la détection de panne par
surveillance d'ARP au lieu de surveillance de l'interface.

En fait, dans la conf openvpn, j'ai jeté un oeil cette aprem, il y a
tout les hooks pour y insérer les scripts pour gérer les transitions
d'etat de la cnx. C'est toutes les options --pre-down --down --up ...

Une détection par le arp j'y crois moyen car les interfaces membres
d'une interface spéciale sont "confisquées" par l'interface spéciale. Au
niveau kernel je trouve la démarche légitime voir nécessaire. Du coup tu
n'as aucun moyen d'envoyer ou recevoir par un membre spécifique d'une
interface spéciale. Le seul moyen de surveillance que je vois, c'est de
s'assurer par les heartbeat interne d'openvpn que du trafic résiduel
circule en permanence, et de le vérifier sur les compteurs de
l'interface membre, qui eux restent valides et accessibles

Stephane Le Men a écrit :

On 12/22/2011 08:34 PM, Pascal Hambourg wrote:

Sauf erreur, c'est déjà ce qui a dû être fait dans la configuration
actuelle, car il faut bien que chaque tunnel passe par un lien différent
pour cumuler les débits vers le serveur. J'imagine que le plus simple
est en fixant l'adresse ou le port source dans la configuration de
chaque tunnel afin de s'en servir comme clé de routage.

Il peut se passer du multi-table routing s'il DNAT plus loin sur les IAD
(les box) par exemple. Sans faire du DNAT, je ne vois pas comment le
faire sans multi-table.

Le DNAT en "sortie" (vers l'extérieur), je doute que ce soit une
fonctionnalité courante sur les "box".

Openvpn ne fait pas tomber l'interface quand le tunnel tombe ?

Sur le serveur, c'est interdit, les autres clients hurleraient au vol,
et coté client, mon expérience d'openvpn m'a montré qu'elle reste up.

Je pensais plutôt à la configuration pair à pair et non client-serveur.

Dans ce cas il reste la possibilité de faire la détection de panne par
surveillance d'ARP au lieu de surveillance de l'interface.

[...]

Une détection par le arp j'y crois moyen car les interfaces membres
d'une interface spéciale sont "confisquées" par l'interface spéciale. Au
niveau kernel je trouve la démarche légitime voir nécessaire. Du coup tu
n'as aucun moyen d'envoyer ou recevoir par un membre spécifique d'une
interface spéciale.

La surveillance de chaque lien par ARP est assurée par le bonding, cf.
les options arp_interval et arp_ip_target du module. Personnellement je
trouve que ce n'est pas génial dans le sens où c'est une violation du
modèle en couches, mais faute de mieux...

On 22/12/2011 22:36, Stephane Le Men wrote:

On 12/22/2011 08:34 PM, Pascal Hambourg wrote:

Sauf erreur, c'est déjà ce qui a dû être fait dans la configuration
actuelle, car il faut bien que chaque tunnel passe par un lien différent
pour cumuler les débits vers le serveur. J'imagine que le plus simple
est en fixant l'adresse ou le port source dans la configuration de
chaque tunnel afin de s'en servir comme clé de routage.

Il peut se passer du multi-table routing s'il DNAT plus loin sur les IAD
(les box) par exemple. Sans faire du DNAT, je ne vois pas comment le
faire sans multi-table.

ben il y a du DNAT qui est fait sur la machine où tourne le serveur
openvpn. Les box ne servent qu'à la communication entre les deux
serveurs. Je me permet de remettre un schéma du montage :

client 1 LAN --+ +--eth1--WMAX--+
| | |
client 2 LAN --+-switch--debian1(OVPN)+--eth0--ADSL--+(OVPN)debian2--Web
| | |
client 3 LAN --+ +--eth2--WMAX--+


Le bonding est présent sur debian1, le serveur openvpn et le dnat sur
debian2.

Openvpn ne fait pas tomber l'interface quand le tunnel tombe ?

Sur le serveur, c'est interdit, les autres clients hurleraient au vol,
et coté client, mon expérience d'openvpn m'a montré qu'elle reste up.
Il y a peut être une conf spéciale qui la fait tomber, mais je connais pas.

non l'interface ne tombe pas. Et c'est une bonne chose car si
l'interface tombe, elle est sortie du bonding. Les interfaces sont
surveillées par mii si j'ai bien compris.
Ça a l'air de pas trop mal fonctionner, quand je fais tomber un tunnel,
il n'y a pas d'interruption de service.

essomba84 a écrit :

Openvpn ne fait pas tomber l'interface quand le tunnel tombe ?

Sur le serveur, c'est interdit, les autres clients hurleraient au vol,

non l'interface ne tombe pas. Et c'est une bonne chose car si
l'interface tombe, elle est sortie du bonding.

Temporairement. Dès qu'elle remonte elle est réintégrée.

Les interfaces sont
surveillées par mii si j'ai bien compris.

MII ou ARP, selon les options passées. Par défaut il n'y a pas de
surveillance.

On 12/23/2011 09:40 AM, Pascal Hambourg wrote:

Le DNAT en "sortie" (vers l'extérieur), je doute que ce soit une
fonctionnalité courante sur les "box".

Vu qu'en France, on a une archie DSL de merde, on a des box de merde.
Moi, je conseille à quelqu'un qui monte cette config de toutes les
passer en bridge et de gérer les cnx dsl depuis un pc à 100 euros
fanless. A ce tarif là, tu peux prendre deux, tu t'offres, redondance,
la total de linux, et la centralisation de l'admin

Je pensais plutôt à la configuration pair à pair et non client-serveur.

Je ne connais pas d'autre tunnel Ethernet sur IP sur Linux qu'Openvpn.
Et Ethernet est obligatoire pour le bond.
En pair à pair sans client-serveur, je ne vois que les tunnel IP dans IP
avec l'équilibrage des routes.

Une série de tunnels L2TP avec du ppp multilink devrait marcher direct
aussi et peut etre plus simplement qu'avec openvpn puisque le bonding
est gérer directement par pppd. Mais c'est client serveur aussi, et j'ai
jamais fait ce type de tunnel avec linux donc je peux rien dire.

La surveillance de chaque lien par ARP est assurée par le bonding, cf.
les options arp_interval et arp_ip_target du module. Personnellement je
trouve que ce n'est pas génial dans le sens où c'est une violation du
modèle en couches, mais faute de mieux...

En tu t'en fous qu'il ne respecte pas le modèle en couche, ce qui compte
c'est que les specs des composants d'entrées match avec les specs sorties.
Comment c'est fait dedans, je ne veux pas le savoir, mais je suis
bien obligé de m'y intéresser si un de mes tests ne passent pas.
S'il y a une violation du modèle en couche et que tous mes tests
passent, c'est le cadet de mes soucis. D'ailleurs IP respecte très
moyennement cet efficace modèle conceptuel et cela marche très bien sans
empêcher quiconque de dormir.

On 12/23/2011 03:55 PM, essomba84 wrote:

ben il y a du DNAT qui est fait sur la machine où tourne le serveur
openvpn. Les box ne servent qu'à la communication entre les deux
serveurs. Je me permet de remettre un schéma du montage :

client 1 LAN --+ +--eth1--WMAX--+
| | |
client 2 LAN --+-switch--debian1(OVPN)+--eth0--ADSL--+(OVPN)debian2--Web
| | |
client 3 LAN --+ +--eth2--WMAX--+


Le bonding est présent sur debian1, le serveur openvpn et le dnat sur
debian2.

Ton dessin n'est pas très clair, je ne sais pas combien tu as
d'interface sur debian2, mais à priori 1 seule.

Si c'est le cas, ton hébergeur te route au moins 3 Ip vers ton système,
mais tu as configuré qu'une. Dans ce cas, vaut mieux oublier le DNAT et
multi-table routing et configurer 2 alias ethernet pour assigner 1
openvpn par ip. Moins tu as de soft à configurer, et plus le résultat
sera simple et performant.

Openvpn ne fait pas tomber l'interface quand le tunnel tombe ?

Sur le serveur, c'est interdit, les autres clients hurleraient au vol,
et coté client, mon expérience d'openvpn m'a montré qu'elle reste up.
Il y a peut être une conf spéciale qui la fait tomber, mais je connais
pas.

non l'interface ne tombe pas. Et c'est une bonne chose car si
l'interface tombe, elle est sortie du bonding. Les interfaces sont
surveillées par mii si j'ai bien compris.

mii-tool -v tap0
SIOCGMIIPHY on 'tap0' failed: Operation not supported

ça ne peut pas être ça.

Ça a l'air de pas trop mal fonctionner, quand je fais tomber un tunnel,
il n'y a pas d'interruption de service.

Le mieux, c'est de passer le bond en verbose pendant les tests et de
voir quels messages remontent. Avec un ping flood des deux cotés pour
voir combien paquets tu perds. L'émulation ethernet d'openvpn doit
forcement gérer un sous ensembles des messages out-of-band de l'état
d'un port ethernet et ce sont ces messages qui doivent faire réagir le
bond. Le tous, c'est de s'en assurer.

Stephane Le Men a écrit :

On 12/23/2011 09:40 AM, Pascal Hambourg wrote:

Je pensais plutôt à la configuration pair à pair et non client-serveur.

Je ne connais pas d'autre tunnel Ethernet sur IP sur Linux qu'Openvpn.
Et Ethernet est obligatoire pour le bond.
En pair à pair sans client-serveur, je ne vois que les tunnel IP dans IP
avec l'équilibrage des routes.

Je parlais du mode classique point à point (p2p) d'openvpn, avec une
interface tun/tap par tunnel.

On 23/12/2011 19:38, Stephane Le Men wrote:

On 12/23/2011 03:55 PM, essomba84 wrote:

ben il y a du DNAT qui est fait sur la machine où tourne le serveur
openvpn. Les box ne servent qu'à la communication entre les deux
serveurs. Je me permet de remettre un schéma du montage :

client 1 LAN --+ +--eth1--WMAX--+
| | |
client 2 LAN --+-switch--debian1(OVPN)+--eth0--ADSL--+(OVPN)debian2--Web
| | |
client 3 LAN --+ +--eth2--WMAX--+


Le bonding est présent sur debian1, le serveur openvpn et le dnat sur
debian2.

Ton dessin n'est pas très clair, je ne sais pas combien tu as
d'interface sur debian2, mais à priori 1 seule.

non. Debian2 est connecté à un seul réseau, réseau par lequel arrive les
3 VPN. En gros debian2 est un serveur dédié qui possède une seule
adresse IP avec un serveur VPN qui écoute dessus. Les clients VPN se
connectent à debian2.

non l'interface ne tombe pas. Et c'est une bonne chose car si
l'interface tombe, elle est sortie du bonding. Les interfaces sont
surveillées par mii si j'ai bien compris.

mii-tool -v tap0
SIOCGMIIPHY on 'tap0' failed: Operation not supported

ça ne peut pas être ça.

oui mais :

root@laurent-Latitude-E4200:/home/laurent# cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)

Bonding Mode: transmit load balancing
Primary Slave: None
Currently Active Slave: tap0
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0

Slave Interface: tap0
MII Status: up
Speed: 10 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 3e:4a:50:e8:51:5c
Slave queue ID: 0

alors qui a raison ? :)

Ça a l'air de pas trop mal fonctionner, quand je fais tomber un tunnel,
il n'y a pas d'interruption de service.

Le mieux, c'est de passer le bond en verbose pendant les tests et de
voir quels messages remontent. Avec un ping flood des deux cotés pour
voir combien paquets tu perds. L'émulation ethernet d'openvpn doit
forcement gérer un sous ensembles des messages out-of-band de l'état
d'un port ethernet et ce sont ces messages qui doivent faire réagir le
bond. Le tous, c'est de s'en assurer.

je vais effectivement tester le ping flood pour voir le nombre de paquet
perdu. Pour le moment, j'ai juste testé avec un scp qui copie un fichier
à distance.