[projet-agregation] mesurer la capacité d'un lien sans en gêner le fonctionnement.

[Yanick Delarbre]

Bonjour,

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.

*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

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.

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

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.


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

*Amicalement,*
Yanick Delarbre,
Elève ingénieur en Génie Informatique (UTC).
Tél: 06 84 86 16 27


Le 12 octobre 2011 11:33, Laurent GUERBY <laurent at guerby.net> a écrit :

> Le cas de lignes ADSL sur plusieurs sites est le cas "compliqué",
> autant commencer par le cas simple de deux lignes ADSL sur le meme
> site :).
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.tetaneutral.net/pipermail/projet-agregation/attachments/20111016/5d1db3c3/attachment-0001.html>
-------------- section suivante --------------
Une pièce jointe autre que texte a été nettoyée...
Nom: clarification_agreg_statique.svg
Type: image/svg+xml
Taille: 137859 octets
Desc: non disponible
URL: <http://lists.tetaneutral.net/pipermail/projet-agregation/attachments/20111016/5d1db3c3/attachment-0001.svg>
-------------- section suivante --------------
Une pièce jointe autre que texte a été nettoyée...
Nom: clarification_agreg_statique.pdf
Type: application/pdf
Taille: 58440 octets
Desc: non disponible
URL: <http://lists.tetaneutral.net/pipermail/projet-agregation/attachments/20111016/5d1db3c3/attachment-0001.pdf>