Aggrégation débit - IP fallback

On 12/24/2011 01:22 AM, essomba84 wrote:

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.

Est-ce que tu peux expliquer les mesures que tu as prises coté debian1
pour t'assurer que le trafic vers cette unique IP de debian2 entre et
sort bien sur chacun des liens dsl de façon symétrique ?

j'ai toujours pas compris désolé. Parce que sans multi-table routing sur
debian1, ou sans DNAT sur les box, je ne vois pas comment cela peut
marcher. Il reste plus que la possibilité de mettre les clients openvpn
sur debian2 pour les connecter aux ip d'interco dsl qui ont chacun dans
leur box debian1 en DMZ ou en virtual server. Mais ce n'est pas ce que
tu as fait. Alors ?

alors qui a raison ? :)

Les logs ont toujours raison, c'est comme les flics.

La couche Mii, c'est un interface pour gérer l'aspect physique d'un port
ethernet, full-duplex ou pas, speed et remonter l’état opérationnel
électrique du port Ethernet. Cela n'a aucun sens pour un VPN sur
UDP/TCP. Alors, il est possible openvpn reflète sur état électrique du
port Ethernet vpn par l'etat de la session du vpn vu depuis openvpn.
C'est possible que si un timer pète dans openvpn pour considérer l'etat
à down de la session vpn, openvpn passe l'etat "electrique" de
l'interface tap à "down", et que ce soit ce message qui fasse sortir
l'interface du bond. Mais cela doit se vérifier aux logs.

Si c'est ce qui se passe, et bien il n'y a rien à faire de spécial pour
gérer un bond sur ethernet virtuelle par rapport à un bond normal sur
ethernet réelle.

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.

Empile-en plusieurs même parce que bien que "flood", ping ne flood pas
toujours autant qu'on le voudrait.

On 24/12/2011 07:18, Stephane Le Men wrote:

On 12/24/2011 01:22 AM, essomba84 wrote:

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.

Est-ce que tu peux expliquer les mesures que tu as prises coté debian1
pour t'assurer que le trafic vers cette unique IP de debian2 entre et
sort bien sur chacun des liens dsl de façon symétrique ?

oui tu as raison. En fait je suis en train de simuler la solution car je
dois la déployer dans un autre pays. Et je me connectais juste avec 3
clients openvpn en passant toujours par la même route par défaut. Alors
bien sûr ça marchait sans problème.

J'ai donc voulu pousser la simulation en rajoutant un modem (l'android
3G). J'ai donc eu 2 routes par défaut pour sortir sur le web et j'ai
compris ta question :)

Pour contourner, j'ai donc pris 2 ip failover chez OVH (debian2 est chez
OVH) et je route la connexion à une IP distante par une certaine
passerelle.
Par exemple, le premier tunnel se connecte à l'adresse 1.1.1.1, le 2ieme
à l'adresse 1.1.1.2 en spécifiant dans la table de routage que pour
rejoindre 1.1.1.1 on passe par la passerelle de free et pour rejoindre
1.1.1.2 on passe par la passerelle d'orange.
Donc ça, c'est parfait, ça me permet de passer par un lien ou par un
autre. Problème : apparemment OpenVPN a du mal avec les interface
virtuelles (eth0:0, eth0:1, ...) et j'ai donc du créer plusieurs
instances d'openvpn sur chaque adresse failover (directive local dans
les fichiers de conf).

Je me retrouve donc maintenant avec 3 interfaces tap sur le serveur.
Faut il que je les bond entre elles ? Si oui, comment ça va marcher vu
que avec du bonding en "transmit load balancing", il est spécifié que tu
reçois les réponses sur un seul lien (le lien slave). Si je met un
bonding côté serveur, le serveur va aussi répartir la charge sur les
différents liens et donc le bond côté client recevra les réponses sur
tous ses liens plutôt que sur un seul. Cela va t'il marcher ?

Les logs ont toujours raison, c'est comme les flics.

(...)

Si c'est ce qui se passe, et bien il n'y a rien à faire de spécial pour
gérer un bond sur ethernet virtuelle par rapport à un bond normal sur
ethernet réelle.

je ne sais pas qui s'occupe de la surveillance. Reste que dans les logs
j'ai :
134382.248127] bonding: bond0: link status definitely down for interface
tap0, disabling it
[134382.248142] bonding: bond0: making interface tap1 the new active one.

quand le VPN tombe sur l'interface tap0.

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.

Empile-en plusieurs même parce que bien que "flood", ping ne flood pas
toujours autant qu'on le voudrait.

ok je vais voir.

Merci !

essomba84 a écrit :

Donc ça, c'est parfait, ça me permet de passer par un lien ou par un
autre. Problème : apparemment OpenVPN a du mal avec les interface
virtuelles (eth0:0, eth0:1, ...)

Normal : ce ne sont pas des interfaces (même pas virtuelles) mais des
"alias IP", un artifice obsolète et inutile pour attribuer plusieurs
adresses IP à une même interface.

et j'ai donc du créer plusieurs
instances d'openvpn sur chaque adresse failover (directive local dans
les fichiers de conf).

De toute façon c'est ce qu'il fallait faire pour avoir une interface tap
par tunnel.

Je me retrouve donc maintenant avec 3 interfaces tap sur le serveur.
Faut il que je les bond entre elles ?

Oui, comme sur l'autre Debian.

Si oui, comment ça va marcher vu
que avec du bonding en "transmit load balancing", il est spécifié que tu
reçois les réponses sur un seul lien (le lien slave). Si je met un
bonding côté serveur, le serveur va aussi répartir la charge sur les
différents liens et donc le bond côté client recevra les réponses sur
tous ses liens plutôt que sur un seul. Cela va t'il marcher ?

Je ne vois pas trop l'intérêt du mode balance-tlb dans cette
configuration ou les deux extrémités font du bonding, et avec des
interfaces virtuelles dont la vitesse n'a aucune signification. Pourquoi
pas du simple balance-rr ?

On 24/12/2011 14:22, Pascal Hambourg wrote:

essomba84 a écrit :

Donc ça, c'est parfait, ça me permet de passer par un lien ou par un
autre. Problème : apparemment OpenVPN a du mal avec les interface
virtuelles (eth0:0, eth0:1, ...)

Normal : ce ne sont pas des interfaces (même pas virtuelles) mais des
"alias IP", un artifice obsolète et inutile pour attribuer plusieurs
adresses IP à une même interface.

intéressant. Tu as l'air de dire qu'on peut faire autrement pour
attribuer plusieurs adresse par interface. Comment ?

et j'ai donc du créer plusieurs
instances d'openvpn sur chaque adresse failover (directive local dans
les fichiers de conf).

De toute façon c'est ce qu'il fallait faire pour avoir une interface tap
par tunnel.

certes. Mais avant openvpn faisait le bridge donc je n'en avais pas besoin.

Je me retrouve donc maintenant avec 3 interfaces tap sur le serveur.
Faut il que je les bond entre elles ?

Oui, comme sur l'autre Debian.

je crée donc juste un bond sur le serveur et ils vont se débrouiller
entre eux ?

Si oui, comment ça va marcher vu
que avec du bonding en "transmit load balancing", il est spécifié que tu
reçois les réponses sur un seul lien (le lien slave). Si je met un
bonding côté serveur, le serveur va aussi répartir la charge sur les
différents liens et donc le bond côté client recevra les réponses sur
tous ses liens plutôt que sur un seul. Cela va t'il marcher ?

Je ne vois pas trop l'intérêt du mode balance-tlb dans cette
configuration ou les deux extrémités font du bonding, et avec des
interfaces virtuelles dont la vitesse n'a aucune signification. Pourquoi
pas du simple balance-rr ?

car comme tu l'as justement souligné dans un autre post, si je fais du
rr, le lien le plus rapide sera sous-exploité. Non ?

essomba84 a écrit :

On 24/12/2011 14:22, Pascal Hambourg wrote:

essomba84 a écrit :

Problème : apparemment OpenVPN a du mal avec les interface
virtuelles (eth0:0, eth0:1, ...)

Normal : ce ne sont pas des interfaces (même pas virtuelles) mais des
"alias IP", un artifice obsolète et inutile pour attribuer plusieurs
adresses IP à une même interface.

intéressant. Tu as l'air de dire qu'on peut faire autrement pour
attribuer plusieurs adresses par interface. Comment ?

ip add addr <addresse>[/<masque>|<lg_prefixe>] dev <interface>

Je me retrouve donc maintenant avec 3 interfaces tap sur le serveur.
Faut il que je les bond entre elles ?

Oui, comme sur l'autre Debian.

je crée donc juste un bond sur le serveur et ils vont se débrouiller
entre eux ?

Chaque bond va répartir les paquets émis dans les différents tunnels.

Je ne vois pas trop l'intérêt du mode balance-tlb dans cette
configuration ou les deux extrémités font du bonding, et avec des
interfaces virtuelles dont la vitesse n'a aucune signification. Pourquoi
pas du simple balance-rr ?

car comme tu l'as justement souligné dans un autre post, si je fais du
rr, le lien le plus rapide sera sous-exploité. Non ?

En effet, c'est pourquoi j'avais suggéré dans un message précédent de
créer un premier bond avec les deux liaisons 1 Mbit/s et de l'agréger
avec la liaison 2 Mbit/s dans un second bond. Le mode tlb requiert que
l'information de vitesse venant des interfaces tap est fiable, ce dont
je doute puisque ce sont des interfaces virtuelles.

On 12/24/2011 02:02 PM, essomba84 wrote:

J'ai donc voulu pousser la simulation en rajoutant un modem (l'android
3G). J'ai donc eu 2 routes par défaut pour sortir sur le web et j'ai
compris ta question :)

Alors, il faut savoir que 2 routes vers la même destination dans la même
table cela ne sert quasiment à rien. Le kernel quand il parcours la
table pour chercher la destination tombera toujours sur la même route.
Cela ne peut servir uniquement si l'interface utilisée peut
"disparaitre" du kernel, dans ce cas, si la deuxième route n'est pas
attaché à la même interface, c'est elle qui prend le relais.

Par exemple, le premier tunnel se connecte à l'adresse 1.1.1.1, le 2ieme
à l'adresse 1.1.1.2 en spécifiant dans la table de routage que pour
rejoindre 1.1.1.1 on passe par la passerelle de free et pour rejoindre
1.1.1.2 on passe par la passerelle d'orange.

Parfait, ça, c'est la conf simple en "simple table routing"

Je me retrouve donc maintenant avec 3 interfaces tap sur le serveur.
Faut il que je les bond entre elles ?

Oui, il faut le faire des deux cotés.

Si oui, comment ça va marcher vu
que avec du bonding en "transmit load balancing", il est spécifié que tu
reçois les réponses sur un seul lien (le lien slave). Si je met un
bonding côté serveur, le serveur va aussi répartir la charge sur les
différents liens et donc le bond côté client recevra les réponses sur
tous ses liens plutôt que sur un seul. Cela va t'il marcher ?

http://www.linuxfoundation.org/collaborate/workgroups/networking/bonding#Install_ifenslave_Control_Utility

je cite:

"balance-rr
This mode is the only mode that will permit a single TCP/IP
connection to stripe traffic across multiple interfaces."

Donc, cela devrait marcher si tu respectes quelques règles.

134382.248127] bonding: bond0: link status definitely down for interface
tap0, disabling it
[134382.248142] bonding: bond0: making interface tap1 the new active one.

Amha, c'est pas bon ca, si tap1 devient "the new active one", c'est
qu'avant, elle était "the old inactive one".

Je préférais un message du genre "removing failed interface from bond rr
policy"

ok je vais voir.

Installe sar sur ton systeme (sysstat), ou iptraf il est encore plus
joli. Ils te seront utiles.
sar -n DEV 5
pour surveiller le réseau

On 12/24/2011 04:07 PM, essomba84 wrote:

car comme tu l'as justement souligné dans un autre post, si je fais du
rr, le lien le plus rapide sera sous-exploité. Non ?

A priori, c'est ce qu'on serait en droit de croire. Mais Saint Thomas ne
croit que ce qu'il voit, montre le d'abord. La raison qui m'incite à
penser que ce n'est pas ce qui va se passer c'est que sur chaque
interface, il y a une file d'attente des paquets à transmettre, comme
sur une rangé de tire-fesse en station de ski.

Et franchement, si le programmeur du bond a décidé de mettre ses paquets
dans un file d'attente pleine alors qu'il y a en une de vide, j'irai pas
faire du ski avec lui. (et je ne reconnaitrais pas mon linux)

Tu peux régler la longueur des transmit-queue avec ifconfig. Je
conseille des longueurs en rapport avec la BP dispo, deux fois plus
longues si deux fois plus rapide.

Avant de toucher à cela, fait un test avec une conf par défaut.
Si cela ne marche pas, tripatouille les longueurs de queue, et si cela
marche toujours pas, fait l'archie que Pascal propose, un bond de bond
avec un tap.

Autrement, je t'ai dis une bêtise, tu auras à coup sûr à faire quelque
chose pour gérer les déconnexions des clients coté serveur parce que
l'interface tap du serveur ne doit pas changer d'état à la déconnexion
d'un client, contrairement au client openvpn.