<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<tt>Bonjour,<br>
<br>
j’espère commencer quelques chose d'ici peu,<br>
dans un premier temps une version de serveur simplifié ne gérant
qu'un seul client,<br>
ensuite une version multi-client dans le même modèle que
l2tp/mlppp. </tt><br>
<br>
<br>
<img alt="agregation_schema"
src="cid:part1.07090900.08060400@sameswireless.fr" height="835"
width="904"><br>
<tt><br>
A+</tt><br>
<br>
<br>
Le 17/10/2011 12:23, Jérôme Nicolle a écrit :
<blockquote
cite="mid:CAGpsMGZb3T+JckwdZF7VpXv8i8N4Y0iMjyhxbxJJZrSP1O4jFw@mail.gmail.com"
type="cite">
<pre wrap="">Laurent,
Il me semble, dans le cas ou on a plusieurs sorties sur différents
sites avec un IGP en place (BATMAN en l'occurence), qu'on peut avoir
autant de gateway de sortie que de points de sortie réels sur le
réseau.
De cette façon, avec une gateway "statique" par usager du réseau, mais
tant que cette gateway est capable d'utiliser les liens de sortie des
autres gateway, ça peut load-balancer.
Une option serait d'utiliser du loose source routing en plus de
l'astuce iptables+random marking de IELO. Par contre, j'ai jamais
essayé de mettre en oeuvre du LSRR avec un IGP, j'aurais surement
besoin des lumières de Marc pour être sur que ça puisse marcher.
@+
Le 17 octobre 2011 10:19, Laurent GUERBY <a class="moz-txt-link-rfc2396E" href="mailto:laurent@guerby.net"><laurent@guerby.net></a> a écrit :
</pre>
<blockquote type="cite">
<pre wrap="">On Sun, 2011-10-16 at 16:16 +0200, Yanick Delarbre wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Bonjour,
</pre>
</blockquote>
<pre wrap="">
Bonjour,
</pre>
<blockquote type="cite">
<pre wrap="">
On peut passer de maniere relativement simple du cas mono site
au cas
multi site en reservant une route statique entre les deux
sites : le
logiciel de tunnel est alors configuré avec comme gateway non
pas les
deux IP des routeurs ADSL locaux mais une IP routeur ADSL
locale et une
IP qui est routée statiquement sur l'autre site vers le
routeur ADSL. Si
le lien wifi d'interconnection des sites a une capacité deux
fois
superieure a celle de l'ADSL on ne perdra rien en debit final.
L'ADSL
vue a travers le wifi aura bien sur des caracteristiques de
latence
et perte de paquet legerement differente de l'ADSL locale,
mais
on peut esperer peu d'impact.
Le schéma en PJ reprend cette explication.
Si nous avons bien compris, il s'agit d'utiliser (par exemple) deux
sites de sortie (AP2 et AP3 sur le schéma) reliés à l'aide d'une route
statique.
</pre>
</blockquote>
<pre wrap="">
Oui.
</pre>
<blockquote type="cite">
<pre wrap="">Y'aurait-il un intérêt de mettre un tunnel entre ces deux sites de
sortie ? Par exemple pour simplifier le routage/trafic entre les deux
sites de sortie
</pre>
</blockquote>
<pre wrap="">
Pour moi il n'y a pas vraiment de difference entre tunnel
et route statique : l'essentiel est d'avoir un lien
entre les deux.
</pre>
<blockquote type="cite">
<pre wrap="">Il y aurait un site central (AP3) qui est le seul à envoyer des
données sur les deux points de sorties. Du coup, la décision d'envoyer
tel paquet par tel site Internet se ferait sur ce site central.
Les stations (AP1) auront comme route par défaut le site central. Ce
qui signifie pour le trajet d'un paquet, qu'il irait d'abord vers le
site central, puis ce site central décide soit de sortir directement
sur Internet, soit de sortir sur le deuxième site de sortie. Cela
implique un trafic supplémentaire sur la liaison radio (aller-retour)
sur les deux sites. D'après toi, ce trafic supplémentaire est
négligeable au vue de la bande passante d'une liaison radio et de la
BP de l'ADSL.
</pre>
</blockquote>
<pre wrap="">
Oui.
Par exemple sur un reseau bridgé (les ubiquity sont en mode bridge) on
peut bouger l'IP de la gateway sur le deuxieme site sans avoir
a reconfigurer les clients, l'ARP va naturellement marcher,
il faut juste bien supprimer l'IP du premier site avant
de l'annoncer sur le deuxieme site.
</pre>
<blockquote type="cite">
<pre wrap="">Il s'agit donc d'agrégation au niveau du "site central" ? Il va ( pour
caricaturer, c'est certainement une mauvaise stratégie) envoyer un
paquet par son routeur ADSL local, puis un par radio sur l'autre… et
cie (round-robin).
</pre>
</blockquote>
<pre wrap="">
Oui.
</pre>
<blockquote type="cite">
<pre wrap="">
Une évolution possible qu'on envisage (après avoir fait marcher la
précédente):
Au lieu que tous les clients aient comme route par défaut le site
central, les clients auraient par exemple la route par défaut vers la
sortie Internet la plus proche géographiquement. Cependant, tous les
sites ayants une sortie Internet peuvent utiliser les autres sites
reliés sur Internet. Le load-balancing aurait lieu sur tous les sites
ayant une sortie Internet.
</pre>
</blockquote>
<pre wrap="">
On peut faire ce genre d'optimisation.
</pre>
<blockquote type="cite">
<pre wrap="">
A ma connaissance BATMAN ni aucune de ses variantes ne sait
agreger de
lien : comme la plupart des protocoles de routage il se borne
a etablir
un jeu de routes complet et sans boucles, il n'est donc pas
pertinent
pour nos cas d'etude dont l'objectif est l'agregation.
En fait, nous ne voulions pas utiliser BATMAN pour réaliser de
l'agrégation proprement dite. Nous souhaitions étendre BATMAN pour
déterminer les routes empruntables et en répartissant le trafic
(pondérations) dès le premier access-point. Il faut alors être capable
de "noter" les liens ADSL comme on note les liens radio. Au lieu
d'attribuer chez les clients une route par défaut statique, cette
route par défaut serait attribué dynamiquement.
Il s'agit donc de réaliser l'agrégation par l'intermédiaire du routage
dynamique, sans point central. Ce n'est d'ailleurs pas de l'agrégation
à proprement parler mais de la répartition de charge par le routage.
Au final, on partirait sur ta solution proposée que sur BATMAN, au
vue de la complexité soulevée à propos du routage dynamique.
</pre>
</blockquote>
<pre wrap="">
Ok.
Comme je l'ai précisé dans ma premiere réponse la solution du lien
entre les deux sites ADSL est une extension "facile" de l'outil
d'agregation de lien ADSL qui reste l'interet premier du projet
pour les associations wifi.
En effet beaucoup d'association ont un seul site de sortie avec
plusieurs lignes ADSL : c'est toujours difficile d'obtenir
des sites pour faire du wifi, géographiquement et humainement
donc la solution pour accompagner l'augmentation du nombre de membres
est simplement d'ouvrir de nouvelles lignes ADSL sur le meme site.
Pour te donner une idée : trebons.net a 3 lignes sur le meme site avec
une 4eme en preparation, sameswireless 4 lignes, tetaneutral.net a
Saint-Gaudens 2 lignes sur le meme site. La repartition est
faite soit manuellement soit par load balancer par connexion
(ce qui est penible pour utiliser certains sites web).
Je pense qu'il faut vous concentrer sur ce cas la, deux (ou N) liens sur
le meme site car en pratique le plus interessant pour les associations
actuelles et relativement simple a simuler sans depoyer trop de materiel
Bon courage et A+
Laurent
_______________________________________________
projet-agregation mailing list
<a class="moz-txt-link-abbreviated" href="mailto:projet-agregation@lists.tetaneutral.net">projet-agregation@lists.tetaneutral.net</a>
<a class="moz-txt-link-freetext" href="http://lists.tetaneutral.net/listinfo/projet-agregation">http://lists.tetaneutral.net/listinfo/projet-agregation</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<br>
</body>
</html>