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
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 ).
(snip)
Sinon pensez-vous qu'on puisse mettre en place un système de route multipath ? Sachant que ce qui m'intéresse c'est surtout le débit en voie montante. Auriez vous un bon tuto concernant ce routing multipath car pour être franc je n'y ai pas compris grand chose :)
On 24/02/2012 16:56, Essomba wrote:
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 ).
(snip)
Sinon pensez-vous qu'on puisse mettre en place un système de route
multipath ? Sachant que ce qui m'intéresse c'est surtout le débit en
voie montante. Auriez vous un bon tuto concernant ce routing multipath
car pour être franc je n'y ai pas compris grand chose :)
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 ).
(snip)
Sinon pensez-vous qu'on puisse mettre en place un système de route multipath ? Sachant que ce qui m'intéresse c'est surtout le débit en voie montante. Auriez vous un bon tuto concernant ce routing multipath car pour être franc je n'y ai pas compris grand chose :)
Tonton Th
On 02/26/2012 10:53 AM, essomba84 wrote:
Question idiote : en mettant deux tunnels dans le lien rapide, ça ne pourrait pas assurer aussi le bon remplissage, puisque les quatres seraient identiques ?
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...
Je viens de lire ça (régulation de débit qui oscille), et ça m'a rappelé un article que j'ai vu récemment dans GLMF à propos d'une étude de Google sur une nouvelle façon de gérer ce genre de souci. Faut juste que je remette la main dessus...
--
Nous vivons dans un monde étrange/ http://foo.bar.quux.over-blog.com/
On 02/26/2012 10:53 AM, essomba84 wrote:
Question idiote : en mettant deux tunnels dans le lien rapide,
ça ne pourrait pas assurer aussi le bon remplissage, puisque
les quatres seraient identiques ?
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...
Je viens de lire ça (régulation de débit qui oscille), et ça
m'a rappelé un article que j'ai vu récemment dans GLMF à propos
d'une étude de Google sur une nouvelle façon de gérer ce genre
de souci. Faut juste que je remette la main dessus...
--
Nous vivons dans un monde étrange/
http://foo.bar.quux.over-blog.com/
Question idiote : en mettant deux tunnels dans le lien rapide, ça ne pourrait pas assurer aussi le bon remplissage, puisque les quatres seraient identiques ?
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...
Je viens de lire ça (régulation de débit qui oscille), et ça m'a rappelé un article que j'ai vu récemment dans GLMF à propos d'une étude de Google sur une nouvelle façon de gérer ce genre de souci. Faut juste que je remette la main dessus...
--
Nous vivons dans un monde étrange/ http://foo.bar.quux.over-blog.com/
Pascal Hambourg
essomba84 a écrit :
On 25/02/2012 11:04, Pascal Hambourg wrote:
essomba84 a écrit :
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 ?
Je n'ai pas beacoup d'expérience de ce genre d'analyse, donc d'autres avis sont bienvenus. L'outil de base est la capture de paquets (tcpdump, wireshark...) qui permet de voir les paquets émis et reçus, l'ordre de réception. Il me semble que certains affichent quand les numéros de séquence sont non consécutifs, signe que les segments TCP sont reçus dans le désordre ou manquants, ou les doublons, signe de retransmission donc de non-réception de l'acquittement.
Tu as essayé d'augmenter la valeur de tcp_reordering du destinataire ? J'ai calculé qu'avec un temps approximatif de transmission de 15 ms par paquet sur 1 MBit/s, un écart de latence moyenne de 60 ms pouvait faire que plus de trois paquets soient reçus par le lien ADSL entre deux segments reçus par les liens Wimax.
essomba84 a écrit :
On 25/02/2012 11:04, Pascal Hambourg wrote:
essomba84 a écrit :
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 ?
Je n'ai pas beacoup d'expérience de ce genre d'analyse, donc d'autres
avis sont bienvenus. L'outil de base est la capture de paquets (tcpdump,
wireshark...) qui permet de voir les paquets émis et reçus, l'ordre de
réception. Il me semble que certains affichent quand les numéros de
séquence sont non consécutifs, signe que les segments TCP sont reçus
dans le désordre ou manquants, ou les doublons, signe de retransmission
donc de non-réception de l'acquittement.
Tu as essayé d'augmenter la valeur de tcp_reordering du destinataire ?
J'ai calculé qu'avec un temps approximatif de transmission de 15 ms par
paquet sur 1 MBit/s, un écart de latence moyenne de 60 ms pouvait faire
que plus de trois paquets soient reçus par le lien ADSL entre deux
segments reçus par les liens Wimax.
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 ?
Je n'ai pas beacoup d'expérience de ce genre d'analyse, donc d'autres avis sont bienvenus. L'outil de base est la capture de paquets (tcpdump, wireshark...) qui permet de voir les paquets émis et reçus, l'ordre de réception. Il me semble que certains affichent quand les numéros de séquence sont non consécutifs, signe que les segments TCP sont reçus dans le désordre ou manquants, ou les doublons, signe de retransmission donc de non-réception de l'acquittement.
Tu as essayé d'augmenter la valeur de tcp_reordering du destinataire ? J'ai calculé qu'avec un temps approximatif de transmission de 15 ms par paquet sur 1 MBit/s, un écart de latence moyenne de 60 ms pouvait faire que plus de trois paquets soient reçus par le lien ADSL entre deux segments reçus par les liens Wimax.
Pascal Hambourg
essomba84 a écrit :
Sinon pensez-vous qu'on puisse mettre en place un système de route multipath ? Sachant que ce qui m'intéresse c'est surtout le débit en voie montante. Auriez vous un bon tuto concernant ce routing multipath car pour être franc je n'y ai pas compris grand chose :)
Tu parles du multipath avec ip route add ... nexthop ... nexthop ... ? L'inconvénient est que la répartition du trafic entre les liens se fait sur la base du couple d'adresses source et destination, et non pour chaque paquet individuel. L'équilibrage ne peut donc se faire qu'avec plusieurs sources et/ou destinataires. Un autre inconvénient est que cela n'apporte pas de redondance, je pense. Par contre l'avantage est que, les paquets d'un même flux empruntant le même chemin, cela réduit les éventuels problèmes liés à l'écart de latence et la réception dans le désordre.
essomba84 a écrit :
Sinon pensez-vous qu'on puisse mettre en place un système de route
multipath ? Sachant que ce qui m'intéresse c'est surtout le débit en
voie montante. Auriez vous un bon tuto concernant ce routing multipath
car pour être franc je n'y ai pas compris grand chose :)
Tu parles du multipath avec ip route add ... nexthop ... nexthop ... ?
L'inconvénient est que la répartition du trafic entre les liens se fait
sur la base du couple d'adresses source et destination, et non pour
chaque paquet individuel. L'équilibrage ne peut donc se faire qu'avec
plusieurs sources et/ou destinataires. Un autre inconvénient est que
cela n'apporte pas de redondance, je pense. Par contre l'avantage est
que, les paquets d'un même flux empruntant le même chemin, cela réduit
les éventuels problèmes liés à l'écart de latence et la réception dans
le désordre.
Sinon pensez-vous qu'on puisse mettre en place un système de route multipath ? Sachant que ce qui m'intéresse c'est surtout le débit en voie montante. Auriez vous un bon tuto concernant ce routing multipath car pour être franc je n'y ai pas compris grand chose :)
Tu parles du multipath avec ip route add ... nexthop ... nexthop ... ? L'inconvénient est que la répartition du trafic entre les liens se fait sur la base du couple d'adresses source et destination, et non pour chaque paquet individuel. L'équilibrage ne peut donc se faire qu'avec plusieurs sources et/ou destinataires. Un autre inconvénient est que cela n'apporte pas de redondance, je pense. Par contre l'avantage est que, les paquets d'un même flux empruntant le même chemin, cela réduit les éventuels problèmes liés à l'écart de latence et la réception dans le désordre.
essomba84
On 26/02/2012 12:36, Pascal Hambourg wrote:
essomba84 a écrit :
Sinon pensez-vous qu'on puisse mettre en place un système de route multipath ? Sachant que ce qui m'intéresse c'est surtout le débit en voie montante. Auriez vous un bon tuto concernant ce routing multipath car pour être franc je n'y ai pas compris grand chose :)
Tu parles du multipath avec ip route add ... nexthop ... nexthop ... ? L'inconvénient est que la répartition du trafic entre les liens se fait sur la base du couple d'adresses source et destination, et non pour chaque paquet individuel. L'équilibrage ne peut donc se faire qu'avec plusieurs sources et/ou destinataires. Un autre inconvénient est que cela n'apporte pas de redondance, je pense. Par contre l'avantage est que, les paquets d'un même flux empruntant le même chemin, cela réduit les éventuels problèmes liés à l'écart de latence et la réception dans le désordre.
je parle de ce genre de truc : http://lartc.org/howto/lartc.rpdb.multiple-links.html ... Qu'en penses-tu ?
On 26/02/2012 12:36, Pascal Hambourg wrote:
essomba84 a écrit :
Sinon pensez-vous qu'on puisse mettre en place un système de route
multipath ? Sachant que ce qui m'intéresse c'est surtout le débit en
voie montante. Auriez vous un bon tuto concernant ce routing multipath
car pour être franc je n'y ai pas compris grand chose :)
Tu parles du multipath avec ip route add ... nexthop ... nexthop ... ?
L'inconvénient est que la répartition du trafic entre les liens se fait
sur la base du couple d'adresses source et destination, et non pour
chaque paquet individuel. L'équilibrage ne peut donc se faire qu'avec
plusieurs sources et/ou destinataires. Un autre inconvénient est que
cela n'apporte pas de redondance, je pense. Par contre l'avantage est
que, les paquets d'un même flux empruntant le même chemin, cela réduit
les éventuels problèmes liés à l'écart de latence et la réception dans
le désordre.
je parle de ce genre de truc :
http://lartc.org/howto/lartc.rpdb.multiple-links.html ... Qu'en penses-tu ?
Sinon pensez-vous qu'on puisse mettre en place un système de route multipath ? Sachant que ce qui m'intéresse c'est surtout le débit en voie montante. Auriez vous un bon tuto concernant ce routing multipath car pour être franc je n'y ai pas compris grand chose :)
Tu parles du multipath avec ip route add ... nexthop ... nexthop ... ? L'inconvénient est que la répartition du trafic entre les liens se fait sur la base du couple d'adresses source et destination, et non pour chaque paquet individuel. L'équilibrage ne peut donc se faire qu'avec plusieurs sources et/ou destinataires. Un autre inconvénient est que cela n'apporte pas de redondance, je pense. Par contre l'avantage est que, les paquets d'un même flux empruntant le même chemin, cela réduit les éventuels problèmes liés à l'écart de latence et la réception dans le désordre.
je parle de ce genre de truc : http://lartc.org/howto/lartc.rpdb.multiple-links.html ... Qu'en penses-tu ?
Pascal Hambourg
essomba84 a écrit :
On 26/02/2012 12:36, Pascal Hambourg wrote:
essomba84 a écrit :
Sinon pensez-vous qu'on puisse mettre en place un système de route multipath ? Sachant que ce qui m'intéresse c'est surtout le débit en voie montante. Auriez vous un bon tuto concernant ce routing multipath car pour être franc je n'y ai pas compris grand chose :)
Tu parles du multipath avec ip route add ... nexthop ... nexthop ... ? L'inconvénient est que la répartition du trafic entre les liens se fait sur la base du couple d'adresses source et destination, et non pour chaque paquet individuel. L'équilibrage ne peut donc se faire qu'avec plusieurs sources et/ou destinataires. Un autre inconvénient est que cela n'apporte pas de redondance, je pense. Par contre l'avantage est que, les paquets d'un même flux empruntant le même chemin, cela réduit les éventuels problèmes liés à l'écart de latence et la réception dans le désordre.
je parle de ce genre de truc : http://lartc.org/howto/lartc.rpdb.multiple-links.html ... Qu'en penses-tu ?
Paragraphe 4.2.2 ? C'est ce que j'évoquais ci-dessus. L'équilibrage sera d'autant meilleur que le nombre de sources et/ou destinataires est important. Autre avantage que j'avais oublié de mentionner : la pondération des liens.
essomba84 a écrit :
On 26/02/2012 12:36, Pascal Hambourg wrote:
essomba84 a écrit :
Sinon pensez-vous qu'on puisse mettre en place un système de route
multipath ? Sachant que ce qui m'intéresse c'est surtout le débit en
voie montante. Auriez vous un bon tuto concernant ce routing multipath
car pour être franc je n'y ai pas compris grand chose :)
Tu parles du multipath avec ip route add ... nexthop ... nexthop ... ?
L'inconvénient est que la répartition du trafic entre les liens se fait
sur la base du couple d'adresses source et destination, et non pour
chaque paquet individuel. L'équilibrage ne peut donc se faire qu'avec
plusieurs sources et/ou destinataires. Un autre inconvénient est que
cela n'apporte pas de redondance, je pense. Par contre l'avantage est
que, les paquets d'un même flux empruntant le même chemin, cela réduit
les éventuels problèmes liés à l'écart de latence et la réception dans
le désordre.
je parle de ce genre de truc :
http://lartc.org/howto/lartc.rpdb.multiple-links.html ... Qu'en penses-tu ?
Paragraphe 4.2.2 ? C'est ce que j'évoquais ci-dessus.
L'équilibrage sera d'autant meilleur que le nombre de sources et/ou
destinataires est important.
Autre avantage que j'avais oublié de mentionner : la pondération des liens.
Sinon pensez-vous qu'on puisse mettre en place un système de route multipath ? Sachant que ce qui m'intéresse c'est surtout le débit en voie montante. Auriez vous un bon tuto concernant ce routing multipath car pour être franc je n'y ai pas compris grand chose :)
Tu parles du multipath avec ip route add ... nexthop ... nexthop ... ? L'inconvénient est que la répartition du trafic entre les liens se fait sur la base du couple d'adresses source et destination, et non pour chaque paquet individuel. L'équilibrage ne peut donc se faire qu'avec plusieurs sources et/ou destinataires. Un autre inconvénient est que cela n'apporte pas de redondance, je pense. Par contre l'avantage est que, les paquets d'un même flux empruntant le même chemin, cela réduit les éventuels problèmes liés à l'écart de latence et la réception dans le désordre.
je parle de ce genre de truc : http://lartc.org/howto/lartc.rpdb.multiple-links.html ... Qu'en penses-tu ?
Paragraphe 4.2.2 ? C'est ce que j'évoquais ci-dessus. L'équilibrage sera d'autant meilleur que le nombre de sources et/ou destinataires est important. Autre avantage que j'avais oublié de mentionner : la pondération des liens.
essomba84
On 26/02/2012 14:00, Pascal Hambourg wrote:
Paragraphe 4.2.2 ? C'est ce que j'évoquais ci-dessus. L'équilibrage sera d'autant meilleur que le nombre de sources et/ou destinataires est important. Autre avantage que j'avais oublié de mentionner : la pondération des liens.
donc la pondération des liens permettrai d'écouler deux fois plus de trafic sur le lien deux fois plus rapide. J'ai bon ? Par contre je suis surpris de l'absence de redondance. Si une route tombe, le noyau n'enverra pas les paquets sur l'autre route ?
Sinon puis-je forcer le trafic sur un port à passer par une passerelle et le trafic sur un autre port par une autre ? Est-ce que un truc du genre ci-dessous ferait ce que je veux (à savoir router le trafic vers le port 80 par bond0 et par le port 443 par eth0) ?
Paragraphe 4.2.2 ? C'est ce que j'évoquais ci-dessus.
L'équilibrage sera d'autant meilleur que le nombre de sources et/ou
destinataires est important.
Autre avantage que j'avais oublié de mentionner : la pondération des liens.
donc la pondération des liens permettrai d'écouler deux fois plus de
trafic sur le lien deux fois plus rapide. J'ai bon ? Par contre je suis
surpris de l'absence de redondance. Si une route tombe, le noyau
n'enverra pas les paquets sur l'autre route ?
Sinon puis-je forcer le trafic sur un port à passer par une passerelle
et le trafic sur un autre port par une autre ? Est-ce que un truc du
genre ci-dessous ferait ce que je veux (à savoir router le trafic vers
le port 80 par bond0 et par le port 443 par eth0) ?
Paragraphe 4.2.2 ? C'est ce que j'évoquais ci-dessus. L'équilibrage sera d'autant meilleur que le nombre de sources et/ou destinataires est important. Autre avantage que j'avais oublié de mentionner : la pondération des liens.
donc la pondération des liens permettrai d'écouler deux fois plus de trafic sur le lien deux fois plus rapide. J'ai bon ? Par contre je suis surpris de l'absence de redondance. Si une route tombe, le noyau n'enverra pas les paquets sur l'autre route ?
Sinon puis-je forcer le trafic sur un port à passer par une passerelle et le trafic sur un autre port par une autre ? Est-ce que un truc du genre ci-dessous ferait ce que je veux (à savoir router le trafic vers le port 80 par bond0 et par le port 443 par eth0) ?
Paragraphe 4.2.2 ? C'est ce que j'évoquais ci-dessus. L'équilibrage sera d'autant meilleur que le nombre de sources et/ou destinataires est important. Autre avantage que j'avais oublié de mentionner : la pondération des liens.
donc la pondération des liens permettrai d'écouler deux fois plus de trafic sur le lien deux fois plus rapide. J'ai bon ?
Idéalement, oui.
Par contre je suis surpris de l'absence de redondance. Si une route tombe, le noyau n'enverra pas les paquets sur l'autre route ?
J'ai peur que non. Mais il faudrait tester. De toute façon, la notion de "une route tombe" est assez dificile à définir. Ça n'implique pas forcément que l'interface associée tombe.
Sinon puis-je forcer le trafic sur un port à passer par une passerelle et le trafic sur un autre port par une autre ? Est-ce que un truc du genre ci-dessous ferait ce que je veux (à savoir router le trafic vers le port 80 par bond0 et par le port 443 par eth0) ?
Non, pas du tout. Ces règles font du NAT d'adresse source en fonction du port destination et de l'interface de sortie, elles n'ont aucune influence sur le routage. Il faut marquer les paquets avec iptables et les router avec une règle de routage basée sur la marque, cf. <http://lartc.org/howto/lartc.netfilter.html>. Le marquage doit se faire dans PREROUTING pour les paquets "routés" (reçus et retransmis) et dans OUTPUT pour les paqués émis localement.
essomba84 a écrit :
On 26/02/2012 14:00, Pascal Hambourg wrote:
Paragraphe 4.2.2 ? C'est ce que j'évoquais ci-dessus.
L'équilibrage sera d'autant meilleur que le nombre de sources et/ou
destinataires est important.
Autre avantage que j'avais oublié de mentionner : la pondération des liens.
donc la pondération des liens permettrai d'écouler deux fois plus de
trafic sur le lien deux fois plus rapide. J'ai bon ?
Idéalement, oui.
Par contre je suis
surpris de l'absence de redondance. Si une route tombe, le noyau
n'enverra pas les paquets sur l'autre route ?
J'ai peur que non. Mais il faudrait tester. De toute façon, la notion de
"une route tombe" est assez dificile à définir. Ça n'implique pas
forcément que l'interface associée tombe.
Sinon puis-je forcer le trafic sur un port à passer par une passerelle
et le trafic sur un autre port par une autre ? Est-ce que un truc du
genre ci-dessous ferait ce que je veux (à savoir router le trafic vers
le port 80 par bond0 et par le port 443 par eth0) ?
Non, pas du tout. Ces règles font du NAT d'adresse source en fonction du
port destination et de l'interface de sortie, elles n'ont aucune
influence sur le routage. Il faut marquer les paquets avec iptables et
les router avec une règle de routage basée sur la marque, cf.
<http://lartc.org/howto/lartc.netfilter.html>.
Le marquage doit se faire dans PREROUTING pour les paquets "routés"
(reçus et retransmis) et dans OUTPUT pour les paqués émis localement.
Paragraphe 4.2.2 ? C'est ce que j'évoquais ci-dessus. L'équilibrage sera d'autant meilleur que le nombre de sources et/ou destinataires est important. Autre avantage que j'avais oublié de mentionner : la pondération des liens.
donc la pondération des liens permettrai d'écouler deux fois plus de trafic sur le lien deux fois plus rapide. J'ai bon ?
Idéalement, oui.
Par contre je suis surpris de l'absence de redondance. Si une route tombe, le noyau n'enverra pas les paquets sur l'autre route ?
J'ai peur que non. Mais il faudrait tester. De toute façon, la notion de "une route tombe" est assez dificile à définir. Ça n'implique pas forcément que l'interface associée tombe.
Sinon puis-je forcer le trafic sur un port à passer par une passerelle et le trafic sur un autre port par une autre ? Est-ce que un truc du genre ci-dessous ferait ce que je veux (à savoir router le trafic vers le port 80 par bond0 et par le port 443 par eth0) ?
Non, pas du tout. Ces règles font du NAT d'adresse source en fonction du port destination et de l'interface de sortie, elles n'ont aucune influence sur le routage. Il faut marquer les paquets avec iptables et les router avec une règle de routage basée sur la marque, cf. <http://lartc.org/howto/lartc.netfilter.html>. Le marquage doit se faire dans PREROUTING pour les paquets "routés" (reçus et retransmis) et dans OUTPUT pour les paqués émis localement.
xavier
Essomba wrote:
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 ).
Je me permets d'intervenir dans un fil que j'ai suivi depuis le début, ainsi que le précédent, même si ça sort un peu de mon domaine de compétence.
Il y a-t-il une raison technique/économique/pédagogique de mettre en place une telle solution ?
Parce que la solution hardware (j'en connais au mois deux, Cisco et Bintec/Funwerk) sait faire de l'aggrégation et du failover au niveau ATM, et c'est quand même fichtrement plus confortable. Par contre, j'ignore ce qu'il en est du lien Wimax, je n'ai jamais approché ce genre de matériel.
Cordialement,
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear. (Jethro Tull)
Essomba <essomba421@yahou.com.invalid> wrote:
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 ).
Je me permets d'intervenir dans un fil que j'ai suivi depuis le début,
ainsi que le précédent, même si ça sort un peu de mon domaine de
compétence.
Il y a-t-il une raison technique/économique/pédagogique de mettre en
place une telle solution ?
Parce que la solution hardware (j'en connais au mois deux, Cisco et
Bintec/Funwerk) sait faire de l'aggrégation et du failover au niveau
ATM, et c'est quand même fichtrement plus confortable. Par contre,
j'ignore ce qu'il en est du lien Wimax, je n'ai jamais approché ce genre
de matériel.
Cordialement,
--
XAv
In your pomp and all your glory you're a poorer man than me,
as you lick the boots of death born out of fear.
(Jethro Tull)
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 ).
Je me permets d'intervenir dans un fil que j'ai suivi depuis le début, ainsi que le précédent, même si ça sort un peu de mon domaine de compétence.
Il y a-t-il une raison technique/économique/pédagogique de mettre en place une telle solution ?
Parce que la solution hardware (j'en connais au mois deux, Cisco et Bintec/Funwerk) sait faire de l'aggrégation et du failover au niveau ATM, et c'est quand même fichtrement plus confortable. Par contre, j'ignore ce qu'il en est du lien Wimax, je n'ai jamais approché ce genre de matériel.
Cordialement,
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear. (Jethro Tull)
Tonton Th
On 02/26/2012 11:14 AM, Tonton Th wrote:
Je viens de lire ça (régulation de débit qui oscille), et ça m'a rappelé un article que j'ai vu récemment dans GLMF à propos d'une étude de Google sur une nouvelle façon de gérer ce genre de souci. Faut juste que je remette la main dessus...
LinuxMag numéro 146, Février 2012 - Kernel corner.
Le papier de Google : http://research.google.com/pubs/archive/37486.pdf
--
Nous vivons dans un monde étrange/ http://foo.bar.quux.over-blog.com/
On 02/26/2012 11:14 AM, Tonton Th wrote:
Je viens de lire ça (régulation de débit qui oscille), et ça
m'a rappelé un article que j'ai vu récemment dans GLMF à propos
d'une étude de Google sur une nouvelle façon de gérer ce genre
de souci. Faut juste que je remette la main dessus...
LinuxMag numéro 146, Février 2012 - Kernel corner.
Le papier de Google :
http://research.google.com/pubs/archive/37486.pdf
--
Nous vivons dans un monde étrange/
http://foo.bar.quux.over-blog.com/
Je viens de lire ça (régulation de débit qui oscille), et ça m'a rappelé un article que j'ai vu récemment dans GLMF à propos d'une étude de Google sur une nouvelle façon de gérer ce genre de souci. Faut juste que je remette la main dessus...
LinuxMag numéro 146, Février 2012 - Kernel corner.
Le papier de Google : http://research.google.com/pubs/archive/37486.pdf
--
Nous vivons dans un monde étrange/ http://foo.bar.quux.over-blog.com/
