Agrégation de liens

Le
JKB
Bonjour à tous,

J'avais déjà posé une question sur l'agrégation de liens il y a
quelques mois de cela, mais cela ne fonctionnait pas en raison d'une
subtilité du pilote agr de NetBSD. Le problème ayant trouvé une
solution, je m'y replonge.

Considérons un site A (Linux) avec deux connexions : une ADSL (18Mbps)
et une VDSL2 (30Mbps).

Le site B est connecté malheureusement en Wimax, uniquement en ipv4.
Le routeur tourne sous NetBSD.

J'arrive à créer un VPN/UDP entre eth1 (ADSL) de A et tap0 de B. Un
second VPN/UDP existe entre eth2 (VDSL2) de A et tap1 de B.
De A vers B, le premier VPN plafonne à 1 Mbps. Le second, sur
VDSL2, à 3 Mbps

Je compte agréger les deux VPN et pour éviter les problèmes de
réordonnancement, essayer de coller là-dessus un troisième VPN/UDP
sans authentification ni chiffrement (ça, c'est pour expérimenter).

Côté B, je peux laisser l'algorithme par défaut round-robin.

Côté A, comment faire pour obtenir le maximum de bande passante ?
Je suppose que si j'utilise le mode RR de Linux, je ne vais
plafonner qu'à deux vois la vitesse de l'interface la plus lente.

Il y a un mode balance-tlb dans la documentation. Mais j'avoue que
cette doc n'est pas très claire. Est-ce que cela pourrait résoudre
mon problème ? Et sinon, comment faire ?

Bien cordialement,

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Pascal Hambourg
Le #26430446
Le 27/03/2017 à 22:44, JKB a écrit :
J'arrive à créer un VPN/UDP entre eth1 (ADSL) de A et tap0 de B. Un
second VPN/UDP existe entre eth2 (VDSL2) de A et tap1 de B.
De A vers B, le premier VPN plafonne à 1 Mbps. Le second, sur
VDSL2, à 3 Mbps
Je compte agréger les deux VPN et pour éviter les problèmes de
réordonnancement, essayer de coller là-dessus un troisième VPN/UDP
sans authentification ni chiffrement (ça, c'est pour expérimenter).

En quoi cela va-t-il éviter les problèmes de réordonnancement ? Et quels
problèmes, d'ailleurs ?
Côté A, comment faire pour obtenir le maximum de bande passante ?
Je suppose que si j'utilise le mode RR de Linux, je ne vais
plafonner qu'à deux vois la vitesse de l'interface la plus lente.
Il y a un mode balance-tlb dans la documentation. Mais j'avoue que
cette doc n'est pas très claire. Est-ce que cela pourrait résoudre
mon problème ?

Extrait de la documentation :
balance-tlb or 5
Adaptive transmit load balancing: channel bonding that
does not require any special switch support. The
outgoing traffic is distributed according to the
current load (computed relative to the speed) on each
slave. (...)
Prerequisite:
Ethtool support in the base drivers for retrieving the
speed of each slave.
Pas sûr qu'on puisser récupérer la "vitesse" d'une interface VPN. Mais
si c'est le cas, alors il faut qu'elle reflète la vitesse du lien
sous-jacent.
Pour rappel, les algorithmes de répartition basés sur la vitesse du lien
ne marchent que si c'est la véritable vitesse du lien xDSL, et pas la
vitesse de la liaison ethernet entre la machine et le modem xDSL par
exemple. Même chose pour les algorithmes basés sur le remplissage du
tampon d'émission : se baser sur le tampon d'émission de l'interface
ethernet ne sert à rien puisque c'est celui du modem qui se remplit le
plus vite.
JKB
Le #26430467
Le Tue, 28 Mar 2017 00:29:44 +0200,
Pascal Hambourg
Le 27/03/2017 à 22:44, JKB a écrit :
J'arrive à créer un VPN/UDP entre eth1 (ADSL) de A et tap0 de B. Un
second VPN/UDP existe entre eth2 (VDSL2) de A et tap1 de B.
De A vers B, le premier VPN plafonne à 1 Mbps. Le second, sur
VDSL2, à 3 Mbps
Je compte agréger les deux VPN et pour éviter les problèmes de
réordonnancement, essayer de coller là-dessus un troisième VPN/UDP
sans authentification ni chiffrement (ça, c'est pour expérimenter).

En quoi cela va-t-il éviter les problèmes de réordonnancement ? Et quels
problèmes, d'ailleurs ?

Si c'est de l'UDP qui passe sur le lien, je partais du principe que
le problème de l'ordonnancement des sessions TCP était géré par le
VPN un peu mieux que par les mécanismes TCP classiques.
Côté A, comment faire pour obtenir le maximum de bande passante ?
Je suppose que si j'utilise le mode RR de Linux, je ne vais
plafonner qu'à deux vois la vitesse de l'interface la plus lente.
Il y a un mode balance-tlb dans la documentation. Mais j'avoue que
cette doc n'est pas très claire. Est-ce que cela pourrait résoudre
mon problème ?

Extrait de la documentation :
balance-tlb or 5
Adaptive transmit load balancing: channel bonding that
does not require any special switch support. The
outgoing traffic is distributed according to the
current load (computed relative to the speed) on each
slave. (...)
Prerequisite:
Ethtool support in the base drivers for retrieving the
speed of each slave.
Pas sûr qu'on puisser récupérer la "vitesse" d'une interface VPN. Mais
si c'est le cas, alors il faut qu'elle reflète la vitesse du lien
sous-jacent.
Pour rappel, les algorithmes de répartition basés sur la vitesse du lien
ne marchent que si c'est la véritable vitesse du lien xDSL, et pas la
vitesse de la liaison ethernet entre la machine et le modem xDSL par
exemple. Même chose pour les algorithmes basés sur le remplissage du
tampon d'émission : se baser sur le tampon d'émission de l'interface
ethernet ne sert à rien puisque c'est celui du modem qui se remplit le
plus vite.

Oui, ça, je sais. Donc pour mon problème, aucune solution ?
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Pascal Hambourg
Le #26430725
Le 28/03/2017 à 08:47, JKB a écrit :
Pascal Hambourg
Le 27/03/2017 à 22:44, JKB a écrit :
Je compte agréger les deux VPN et pour éviter les problèmes de
réordonnancement, essayer de coller là-dessus un troisième VPN/UDP
sans authentification ni chiffrement (ça, c'est pour expérimenter).

En quoi cela va-t-il éviter les problèmes de réordonnancement ? Et quels
problèmes, d'ailleurs ?

Si c'est de l'UDP qui passe sur le lien, je partais du principe que
le problème de l'ordonnancement des sessions TCP était géré par le
VPN un peu mieux que par les mécanismes TCP classiques.

Je ne suis pas sûr de comprendre de quoi tu parles. UDP ne gère pas
l'ordonnancement des paquets. Tu veux parler d'éviter le transport de
TCP dans TCP et les problèmes qui vont avec (latence, retransmission
excessive) ?
Côté A, comment faire pour obtenir le maximum de bande passante ?
Je suppose que si j'utilise le mode RR de Linux, je ne vais
plafonner qu'à deux vois la vitesse de l'interface la plus lente.
Il y a un mode balance-tlb dans la documentation. Mais j'avoue que
cette doc n'est pas très claire. Est-ce que cela pourrait résoudre
mon problème ?

Pas sûr qu'on puisser récupérer la "vitesse" d'une interface VPN. Mais
si c'est le cas, alors il faut qu'elle reflète la vitesse du lien
sous-jacent.


(...)
Oui, ça, je sais. Donc pour mon problème, aucune solution ?

A moins que le VPN utilisé supporte ethtool et permette de configurer un
débit annoncé par ce biais, je ne pense pas que le bonding ethernet soit
la solution pour faire de l'équilibrage pondéré. Je n'ai rien de concret
à proposer mais diverses pistes à explorer :
- le driver égaliseur eql et son programme de configuration eql_enslave
qui permet de spécifier le débit de chaque lien, cf.
- le routage multipath d'ip route avec l'option weight qui permet de
pondérer l'égalisation ; cela ne s'appliquait pas à un flux unique à
cause du cache de routage, mais la suppression de ce dernier dans les
noyaux récents a peut-être modifié le comportement
- l'égaliseur teql avec tc ; je n'ai pas l'impression qu'on puisse
pondérer les liens, mais je n'ai jamais réussi à comprendre le
fonctionnement de tc, cf.
JKB
Le #26430755
Le Wed, 29 Mar 2017 00:12:51 +0200,
Pascal Hambourg
Le 28/03/2017 à 08:47, JKB a écrit :
Pascal Hambourg
Le 27/03/2017 à 22:44, JKB a écrit :
Je compte agréger les deux VPN et pour éviter les problèmes de
réordonnancement, essayer de coller là-dessus un troisième VPN/UDP
sans authentification ni chiffrement (ça, c'est pour expérimenter).

En quoi cela va-t-il éviter les problèmes de réordonnancement ? Et quels
problèmes, d'ailleurs ?

Si c'est de l'UDP qui passe sur le lien, je partais du principe que
le problème de l'ordonnancement des sessions TCP était géré par le
VPN un peu mieux que par les mécanismes TCP classiques.

Je ne suis pas sûr de comprendre de quoi tu parles. UDP ne gère pas
l'ordonnancement des paquets. Tu veux parler d'éviter le transport de
TCP dans TCP et les problèmes qui vont avec (latence, retransmission
excessive) ?

Oui, raccourci de langage.
Côté A, comment faire pour obtenir le maximum de bande passante ?
Je suppose que si j'utilise le mode RR de Linux, je ne vais
plafonner qu'à deux vois la vitesse de l'interface la plus lente.
Il y a un mode balance-tlb dans la documentation. Mais j'avoue que
cette doc n'est pas très claire. Est-ce que cela pourrait résoudre
mon problème ?

Pas sûr qu'on puisser récupérer la "vitesse" d'une interface VPN. Mais
si c'est le cas, alors il faut qu'elle reflète la vitesse du lien
sous-jacent.


(...)
Oui, ça, je sais. Donc pour mon problème, aucune solution ?

A moins que le VPN utilisé supporte ethtool et permette de configurer un
débit annoncé par ce biais, je ne pense pas que le bonding ethernet soit
la solution pour faire de l'équilibrage pondéré. Je n'ai rien de concret
à proposer mais diverses pistes à explorer :

Le VPN est OpenVPN.
- le driver égaliseur eql et son programme de configuration eql_enslave
qui permet de spécifier le débit de chaque lien, cf.
- le routage multipath d'ip route avec l'option weight qui permet de
pondérer l'égalisation ; cela ne s'appliquait pas à un flux unique à
cause du cache de routage, mais la suppression de ce dernier dans les
noyaux récents a peut-être modifié le comportement

Je vais préciser mon architecture parce qu'il y a des contraintes.
La machine distante est un NetBSD. Il initie un VPN (OpenVPN) vers
le serveur Linux, donc vers une adresse IP qu'il connaît, en
l'occurence celle de la connexion VDSL2.
Je suis contraint d'utiliser OpenVPN et j'ai déjà dû raler pour
obtenir l'ouverture du port 1194/UDP vers cett machine. Tous les
ports entrants (_TOUS_) sont fermés par le fournisseur d'accès
autoritairement.
J'ai réussi à négocier l'ouverture d'un autre port UDP, ce qui me
permet d'avoir un second VPN ouvert vers la connexion ADSL2 du
serveur.
J'ai l'impression que le multipath ne va pas m'aider (OpenVPN
affecte déjà une adresse IP différente sur les deux liens).
Peut-être EQL. Si côté Linux, je vois à peu près comment cela
fonctionne, comment remettre les deux liens ensemble côté NetBSD ?
- l'égaliseur teql avec tc ; je n'ai pas l'impression qu'on puisse
pondérer les liens, mais je n'ai jamais réussi à comprendre le
fonctionnement de tc, cf.

Je considère que tc est une immense saleté. J'ai réussi à configurer
des règles de trafic à une certaine époque avec plusieurs litres de
café noir et quelques Actrons, mais je serais bien incapable de les
reprendre. Le fonctionnement est, disons, ésotérique pour rester
poli.
Bien cordialement,
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Pascal Hambourg
Le #26430830
Le 29/03/2017 à 09:09, JKB a écrit :
Pascal Hambourg
Pas sûr qu'on puisser récupérer la "vitesse" d'une interface VPN. Mais
si c'est le cas, alors il faut qu'elle reflète la vitesse du lien
sous-jacent.


(...)
Oui, ça, je sais. Donc pour mon problème, aucune solution ?

A moins que le VPN utilisé supporte ethtool et permette de configurer un
débit annoncé par ce biais, je ne pense pas que le bonding ethernet soit
la solution pour faire de l'équilibrage pondéré. Je n'ai rien de concret
à proposer mais diverses pistes à explorer :

Le VPN est OpenVPN.

Je connais OpenVPN d'assez loin, mais comme il est basé sur le pilote
TUN/TAP du noyau, je suppose que ça dépend du support d'ethtool par ce
dernier. D'après son code source dans le noyau Linux
(drivers/net/tun.c), le pilote TUN/TAP supporte ethtool mais la gestion
de la vitesse du lien semble se limiter à annoncer 10 Mbit/s.
Je suis contraint d'utiliser OpenVPN et j'ai déjà dû raler pour
obtenir l'ouverture du port 1194/UDP vers cett machine. Tous les
ports entrants (_TOUS_) sont fermés par le fournisseur d'accès
autoritairement.

Les paquets de réponse sont quand même acceptés, n'est-ce pas, sinon la
résolution DNS ne fonctionnerait pas ? Si c'est cette machine qui initie
les VPN, il devrait y avoir moyen de faire en sorte que tous les paquets
UDP entrants soient considérés comme des paquets de réponse, avec des
keep-alive pour maintenir la "connexion" ouverte.
J'ai l'impression que le multipath ne va pas m'aider (OpenVPN
affecte déjà une adresse IP différente sur les deux liens).

En fait, j'envisageais plutôt le multipath avec les routes pour les
destinations situées au-delà des liens.
Peut-être EQL. Si côté Linux, je vois à peu près comment cela
fonctionne, comment remettre les deux liens ensemble côté NetBSD ?

En réception ? Je ne connais pas NetBSD, mais il ne devrait pas y avoir
à faire quoi que ce soit de spécial, juste recevoir et accepter les
paquets par deux interfaces différentes, comme du multihoming.
- l'égaliseur teql avec tc ; je n'ai pas l'impression qu'on puisse
pondérer les liens, mais je n'ai jamais réussi à comprendre le
fonctionnement de tc, cf.

Je considère que tc est une immense saleté. J'ai réussi à configurer
des règles de trafic à une certaine époque avec plusieurs litres de
café noir et quelques Actrons, mais je serais bien incapable de les
reprendre. Le fonctionnement est, disons, ésotérique pour rester
poli.

Ah, merci de confirmer que ce n'est pas juste moi qui suis bouché.
JKB
Le #26430840
Le Wed, 29 Mar 2017 22:19:56 +0200,
Pascal Hambourg
Le 29/03/2017 à 09:09, JKB a écrit :
Pascal Hambourg
Pas sûr qu'on puisser récupérer la "vitesse" d'une interface VPN. Mais
si c'est le cas, alors il faut qu'elle reflète la vitesse du lien
sous-jacent.


(...)
Oui, ça, je sais. Donc pour mon problème, aucune solution ?

A moins que le VPN utilisé supporte ethtool et permette de configurer un
débit annoncé par ce biais, je ne pense pas que le bonding ethernet soit
la solution pour faire de l'équilibrage pondéré. Je n'ai rien de concret
à proposer mais diverses pistes à explorer :

Le VPN est OpenVPN.

Je connais OpenVPN d'assez loin, mais comme il est basé sur le pilote
TUN/TAP du noyau, je suppose que ça dépend du support d'ethtool par ce
dernier. D'après son code source dans le noyau Linux
(drivers/net/tun.c), le pilote TUN/TAP supporte ethtool mais la gestion
de la vitesse du lien semble se limiter à annoncer 10 Mbit/s.

Exactement.
Je suis contraint d'utiliser OpenVPN et j'ai déjà dû raler pour
obtenir l'ouverture du port 1194/UDP vers cett machine. Tous les
ports entrants (_TOUS_) sont fermés par le fournisseur d'accès
autoritairement.

Les paquets de réponse sont quand même acceptés, n'est-ce pas, sinon la
résolution DNS ne fonctionnerait pas ? Si c'est cette machine qui initie
les VPN, il devrait y avoir moyen de faire en sorte que tous les paquets
UDP entrants soient considérés comme des paquets de réponse, avec des
keep-alive pour maintenir la "connexion" ouverte.

Ne fonctionne pas. Et le problème du DNS n'en est pas un car le
modem fait relais DNS. J'ai dû explicitement demander l'ouverture de
deux ports entrants et râler très fort.
J'ai l'impression que le multipath ne va pas m'aider (OpenVPN
affecte déjà une adresse IP différente sur les deux liens).

En fait, j'envisageais plutôt le multipath avec les routes pour les
destinations situées au-delà des liens.

Oui mais non. Je cherche à augmenter le débit entre ces deux
machines. Pas vers ce qui est au-delà des liens.
Peut-être EQL. Si côté Linux, je vois à peu près comment cela
fonctionne, comment remettre les deux liens ensemble côté NetBSD ?

En réception ? Je ne connais pas NetBSD, mais il ne devrait pas y avoir
à faire quoi que ce soit de spécial, juste recevoir et accepter les
paquets par deux interfaces différentes, comme du multihoming.

Là, je ne te suis plus. Ça doit être l'heure tardive.
Les deux chemins possibles entre les deux machines sont deux VPN
utilisant tap0 et tap1 des deux côtés. Comment penses-tu grouper
cela avec EQL ?
- l'égaliseur teql avec tc ; je n'ai pas l'impression qu'on puisse
pondérer les liens, mais je n'ai jamais réussi à comprendre le
fonctionnement de tc, cf.

Je considère que tc est une immense saleté. J'ai réussi à configurer
des règles de trafic à une certaine époque avec plusieurs litres de
café noir et quelques Actrons, mais je serais bien incapable de les
reprendre. Le fonctionnement est, disons, ésotérique pour rester
poli.

Ah, merci de confirmer que ce n'est pas juste moi qui suis bouché.

Service ;-)
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Pascal Hambourg
Le #26430920
Le 29/03/2017 à 23:49, JKB a écrit :
Pascal Hambourg
Le 29/03/2017 à 09:09, JKB a écrit :
Tous les
ports entrants (_TOUS_) sont fermés par le fournisseur d'accès
autoritairement.

Les paquets de réponse sont quand même acceptés, n'est-ce pas, sinon la
résolution DNS ne fonctionnerait pas ? Si c'est cette machine qui initie
les VPN, il devrait y avoir moyen de faire en sorte que tous les paquets
UDP entrants soient considérés comme des paquets de réponse, avec des
keep-alive pour maintenir la "connexion" ouverte.

Ne fonctionne pas. Et le problème du DNS n'en est pas un car le
modem fait relais DNS.

Tu veux dire qu'on ne peut pas envoyer de requêtes vers un autre serveur
DNS que le relais du modem ?
J'ai l'impression que le multipath ne va pas m'aider (OpenVPN
affecte déjà une adresse IP différente sur les deux liens).

En fait, j'envisageais plutôt le multipath avec les routes pour les
destinations situées au-delà des liens.

Oui mais non. Je cherche à augmenter le débit entre ces deux
machines. Pas vers ce qui est au-delà des liens.

Dans ce cas le multipath peut aussi être utilisé pour une autre adresse
IP appartenant à la machine que celles des interfaces VPN, comme celle
de l'interface reliée au LAN par exemple.
Peut-être EQL. Si côté Linux, je vois à peu près comment cela
fonctionne, comment remettre les deux liens ensemble côté NetBSD ?

En réception ? Je ne connais pas NetBSD, mais il ne devrait pas y avoir
à faire quoi que ce soit de spécial, juste recevoir et accepter les
paquets par deux interfaces différentes, comme du multihoming.

Là, je ne te suis plus. Ça doit être l'heure tardive.

L'interface eql n'est pas bidirectionnelle comme une interface de pont,
VLAN ou tunnel. Elle ne sert que pour l'émission. Elle ne reçoit rien,
les paquets entrants sont reçus directement sur les interfaces des liens
(côté Linux, attention à rp_filter si tu l'utilises).
Les deux chemins possibles entre les deux machines sont deux VPN
utilisant tap0 et tap1 des deux côtés. Comment penses-tu grouper
cela avec EQL ?

Côté Linux, en asservissant les deux interfaces tap à l'interface eql
avec eql_enslave. Côté BSD, n'y connaissant rien du tout, j'ignore s'il
existe un mécanisme équivalent.
JKB
Le #26430935
Le Thu, 30 Mar 2017 21:01:55 +0200,
Pascal Hambourg
Le 29/03/2017 à 23:49, JKB a écrit :
Pascal Hambourg
Le 29/03/2017 à 09:09, JKB a écrit :
Tous les
ports entrants (_TOUS_) sont fermés par le fournisseur d'accès
autoritairement.

Les paquets de réponse sont quand même acceptés, n'est-ce pas, sinon la
résolution DNS ne fonctionnerait pas ? Si c'est cette machine qui initie
les VPN, il devrait y avoir moyen de faire en sorte que tous les paquets
UDP entrants soient considérés comme des paquets de réponse, avec des
keep-alive pour maintenir la "connexion" ouverte.

Ne fonctionne pas. Et le problème du DNS n'en est pas un car le
modem fait relais DNS.

Tu veux dire qu'on ne peut pas envoyer de requêtes vers un autre serveur
DNS que le relais du modem ?

C'est tout à fait cela.
J'ai l'impression que le multipath ne va pas m'aider (OpenVPN
affecte déjà une adresse IP différente sur les deux liens).

En fait, j'envisageais plutôt le multipath avec les routes pour les
destinations situées au-delà des liens.

Oui mais non. Je cherche à augmenter le débit entre ces deux
machines. Pas vers ce qui est au-delà des liens.

Dans ce cas le multipath peut aussi être utilisé pour une autre adresse
IP appartenant à la machine que celles des interfaces VPN, comme celle
de l'interface reliée au LAN par exemple.

As-tu un pointeur sur un howto, une documentation adaptée ? J'ai du
mal à voir comment le multipath pourrait être configuré.
Typiquement, chez moi :
Linux :
- eth0 : LAN (192.168.0.128)
- eth1 + eth1:[1-6] : WAN1 ADSL (192.168.254.1)
- eth2 : WAN2 VDSL2 (192.168.253.1)
- tap0 (VPN/TCP) : 192.168.100.1
- tap1 (VPN/UDP) : 192.168.1.1
- tap2 (VPN/UDP) : 192.168.101.1
NetBSD :
- wm0 : WAN Wimax (youpi) sur 192.168.15.14
- agr0 (wm1 + wm2) en 802.3.ad sur 192.168.10.128
- tap0 (192.168.100.2)
- tap1 (192.168.101.2)
En fait, je ne vois pas trop comment faire un truc intelligent de
tout ça.
Peut-être EQL. Si côté Linux, je vois à peu près comment cela
fonctionne, comment remettre les deux liens ensemble côté NetBSD ?

En réception ? Je ne connais pas NetBSD, mais il ne devrait pas y avoir
à faire quoi que ce soit de spécial, juste recevoir et accepter les
paquets par deux interfaces différentes, comme du multihoming.

Là, je ne te suis plus. Ça doit être l'heure tardive.

L'interface eql n'est pas bidirectionnelle comme une interface de pont,
VLAN ou tunnel. Elle ne sert que pour l'émission. Elle ne reçoit rien,
les paquets entrants sont reçus directement sur les interfaces des liens
(côté Linux, attention à rp_filter si tu l'utilises).

Bon, c'est un peu plus clair. Juste un peu.
Donc je crée deux tunnels tap0 et tap1 côté Linux. Je crée là-dessus
une interface EQL et je lui assigne une adresse. Très bien pour
l'émission. Mais je ne vois toujours pas par quel mécanisme se fait
le retour. En admettant que j'assigne à eql0 10.100.170.1, il me
faut bien une adresse IP côté NetBSD qui soit sur le même sous
réseau, non ?
Les deux chemins possibles entre les deux machines sont deux VPN
utilisant tap0 et tap1 des deux côtés. Comment penses-tu grouper
cela avec EQL ?

Côté Linux, en asservissant les deux interfaces tap à l'interface eql
avec eql_enslave. Côté BSD, n'y connaissant rien du tout, j'ignore s'il
existe un mécanisme équivalent.

Je n'ai pas l'impression qu'il existe quelque chose d'équivalent
côté BSD. Mais mon problème est surtout l'agrégation des liens
sortant du serveur. Côté client le problème est un peu différent.
Cordialement,
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Pascal Hambourg
Le #26431019
Le 30/03/2017 à 23:26, JKB a écrit :
Pascal Hambourg
Tu veux dire qu'on ne peut pas envoyer de requêtes vers un autre serveur
DNS que le relais du modem ?

C'est tout à fait cela.

Donc j'imagine que les autres protocoles basés sur UDP comme NTP ou SIP
ne passent pas non plus ?
Si c'est vendu comme de l'accès internet et pas un simple minitel de
luxe, il y a tromperie sur la marchandise.
J'ai l'impression que le multipath ne va pas m'aider (OpenVPN
affecte déjà une adresse IP différente sur les deux liens).

En fait, j'envisageais plutôt le multipath avec les routes pour les
destinations situées au-delà des liens.

Oui mais non. Je cherche à augmenter le débit entre ces deux
machines. Pas vers ce qui est au-delà des liens.

Dans ce cas le multipath peut aussi être utilisé pour une autre adresse
IP appartenant à la machine que celles des interfaces VPN, comme celle
de l'interface reliée au LAN par exemple.

As-tu un pointeur sur un howto, une documentation adaptée ? J'ai du
mal à voir comment le multipath pourrait être configuré.

Il y a un paragraphe consacré au routage multipath dans le LARTC howto.
Typiquement, chez moi :
Linux :
- eth0 : LAN (192.168.0.128)
- eth1 + eth1:[1-6] : WAN1 ADSL (192.168.254.1)
- eth2 : WAN2 VDSL2 (192.168.253.1)
- tap0 (VPN/TCP) : 192.168.100.1

Pourquoi sur TCP plutôt qu'UDP ?
- tap1 (VPN/UDP) : 192.168.1.1

Où est l'autre bout de ce VPN ? Je ne le vois pas sur NetBSD.
- tap2 (VPN/UDP) : 192.168.101.1
NetBSD :
- wm0 : WAN Wimax (youpi) sur 192.168.15.14
- agr0 (wm1 + wm2) en 802.3.ad sur 192.168.10.128

Que sont wm1 et wm2 ?
- tap0 (192.168.100.2)
- tap1 (192.168.101.2)
En fait, je ne vois pas trop comment faire un truc intelligent de
tout ça.
Donc je crée deux tunnels tap0 et tap1 côté Linux. Je crée là-dessus
une interface EQL et je lui assigne une adresse. Très bien pour
l'émission. Mais je ne vois toujours pas par quel mécanisme se fait
le retour.

Le retour est du ressort de la machine NetBSD. La machine Linux recevra
ce que la machine NetBSD lui envoie. Si chacun des débits descendants
des liens xDSL est supérieur au débit montant du lien Wimax, il n'est
pas forcément utile de faire de l'agrégation de liens dans ce sens de
transmission.
En admettant que j'assigne à eql0 10.100.170.1, il me
faut bien une adresse IP côté NetBSD qui soit sur le même sous
réseau, non ?

Non, pour quoi faire ? Il suffit que les bonnes routes soient présentes
des deux côtés. Les sous-réseaux, ça ne sert qu'à créer implicitement
des routes. On peut très bien s'en passer et créer directement les routes.
JKB
Le #26431188
Le Fri, 31 Mar 2017 23:19:29 +0200,
Pascal Hambourg
Le 30/03/2017 à 23:26, JKB a écrit :
Pascal Hambourg
Tu veux dire qu'on ne peut pas envoyer de requêtes vers un autre serveur
DNS que le relais du modem ?

C'est tout à fait cela.

Donc j'imagine que les autres protocoles basés sur UDP comme NTP ou SIP
ne passent pas non plus ?

Ne passent que sur le VPN. En direct, le modem fait aussi proxy NTP.
Si c'est vendu comme de l'accès internet et pas un simple minitel de
luxe, il y a tromperie sur la marchandise.

Sauf que c'est comme ça et que si je veux autre chose, j'ai le choix
entre le RTC et le satellite.
J'ai l'impression que le multipath ne va pas m'aider (OpenVPN
affecte déjà une adresse IP différente sur les deux liens).

En fait, j'envisageais plutôt le multipath avec les routes pour les
destinations situées au-delà des liens.

Oui mais non. Je cherche à augmenter le débit entre ces deux
machines. Pas vers ce qui est au-delà des liens.

Dans ce cas le multipath peut aussi être utilisé pour une autre adresse
IP appartenant à la machine que celles des interfaces VPN, comme celle
de l'interface reliée au LAN par exemple.

As-tu un pointeur sur un howto, une documentation adaptée ? J'ai du
mal à voir comment le multipath pourrait être configuré.

Il y a un paragraphe consacré au routage multipath dans le LARTC howto.

Je vais de ce pas regarder.
Typiquement, chez moi :
Linux :
- eth0 : LAN (192.168.0.128)
- eth1 + eth1:[1-6] : WAN1 ADSL (192.168.254.1)
- eth2 : WAN2 VDSL2 (192.168.253.1)
- tap0 (VPN/TCP) : 192.168.100.1

Pourquoi sur TCP plutôt qu'UDP ?

Parce que ce VPN est utilisé très occasionnellement dans des cas où
l'UDP ne passe pas.
- tap1 (VPN/UDP) : 192.168.1.1

Où est l'autre bout de ce VPN ? Je ne le vois pas sur NetBSD.

J'ai oublié tap0 192.168.1.2 côté NetBSD.
- tap2 (VPN/UDP) : 192.168.101.1
NetBSD :
- wm0 : WAN Wimax (youpi) sur 192.168.15.14
- agr0 (wm1 + wm2) en 802.3.ad sur 192.168.10.128

Que sont wm1 et wm2 ?

Les interfaces côté LAN qui vont dans un switch gérant l'agrégation
agr0.
- tap0 (192.168.100.2)
- tap1 (192.168.101.2)


Fatigué... Tap0 est 192.168.1.2.
En fait, je ne vois pas trop comment faire un truc intelligent de
tout ça.

Donc je crée deux tunnels tap0 et tap1 côté Linux. Je crée là-dessus
une interface EQL et je lui assigne une adresse. Très bien pour
l'émission. Mais je ne vois toujours pas par quel mécanisme se fait
le retour.

Le retour est du ressort de la machine NetBSD. La machine Linux recevra
ce que la machine NetBSD lui envoie. Si chacun des débits descendants
des liens xDSL est supérieur au débit montant du lien Wimax, il n'est
pas forcément utile de faire de l'agrégation de liens dans ce sens de
transmission.

Jusque-là, je suis d'accord.
En admettant que j'assigne à eql0 10.100.170.1, il me
faut bien une adresse IP côté NetBSD qui soit sur le même sous
réseau, non ?

Non, pour quoi faire ? Il suffit que les bonnes routes soient présentes
des deux côtés. Les sous-réseaux, ça ne sert qu'à créer implicitement
des routes. On peut très bien s'en passer et créer directement les routes.

Là, je n'ai pas saisi. Je vais faire un essai local pour creuser un
peu.
Cordialement,
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Publicité
Poster une réponse
Anonyme