[Ran] dyn_gw

Didier Lebrun dl at vaour.net
Ven 8 Sep 03:20:05 CEST 2006


Sylvain LORIOT a écrit :
> Bonjour,
> 
> je ne sais pas ce que tu entends par comporter comme des noeuds OLSR,
> mais sur Viviers, nous modifions quelques fichiers d'OpenWRT pourqu'il
> prenne en compte le LAN dans les interfaces à router via OLSR.
> 
> Dans le fichier : /etc/local.olsrd.conf, il suffit de rajouter les
> lignes correspondant à l'interface LAN (si celle-ci est br0, cela
> donne :
> 
> Interface "br0"
> {
>         HelloInterval           5.0
>         HelloValidityTime       90.0
>         TcInterval              2.0
>         TcValidityTime          270.0
>         MidInterval             15.0
>         MidValidityTime         90.0
>         HnaInterval             15.0
>         HnaValidityTime         90.0
> 
> 
> 
> }
> qui est l'identique des lignes de olsrd.conf pour eth0 (interface wifi).
> 

Merci Sylvain :-) En fait, la config de l'interface LAN ou WAN se fait 
automatiquement à partir du moment où l'IP + netmask est configurée dans 
la plage du réseau OLSR. Par contre, ça suppose que tous les clients 
rattachés directement aux passerelles fassent tourner OLSR, et ils ne 
sont ni firewallés ni nattés. Je pense que je vais plutôt opter pour une 
seconde machine aux passerelles, genre IPcop + OLSR, ce qui permettrait 
en outre de doser le LQ multiplier du tronçon entre les deux pour 
prioritiser certaines passerlles.

@+

> Ainsi, tout ce qui est branché sur le LAN et qui parle OLSR est reconnu
> par le point d'accès, et apparait dans les tables de routages de tout
> ton réseau.
> 
> Soit :
> 
> prennons un point d'accès que nous appellerons Bocuse, parce qu'il va
> pas mal déguster avec ses interfaces configurées comme suis :
> 	lan :  192.168.13.1
> 	wifi : 192.168.1.13
> 
> Si par le wifi, les tables de routages de Bocuse donnent :
> 	192.168.1.51  via 192.168.1.20 dev eth1 metric 5
> 	192.168.1.32  via 192.168.1.20 dev eth1 metric 3
> 	192.168.1.33  via 192.168.1.20 dev eth1 metric 3 
> 	192.168.1.34  via 192.168.1.20 dev eth1 metric 2
> 
> et que vous connecter un pc, que nous n'appelerons pas parce qu'il
> tourne sous windows, avec pour adresse IP : 192.168.13.100, les tables
> de routages de Bocuse donneront :
> 	192.168.1.51  via 192.168.1.20 dev eth1 metric 5
> 	192.168.1.32  via 192.168.1.20 dev eth1 metric 3
> 	192.168.1.33  via 192.168.1.20 dev eth1 metric 3 
> 	192.168.1.34  via 192.168.1.20 dev eth1 metric 2
> 	192.168.13.100 dev br0 scope link metric 1
> 
> ainsi que sur le PC :
> 	192.168.1.51  via 192.168.13.1 dev eth1 metric 5
> 	192.168.1.32  via 192.168.13.1 dev eth1 metric 3
> 	192.168.1.33  via 192.168.13.1 dev eth1 metric 3 
> 	192.168.1.34  via 192.168.13.1 dev eth1 metric 2
> 	192.168.13.1 dev eth0 scope link metric 1
> 
> Et voilà.
> 
> En espérant avoir fait avancer le schmilblick...
> 
> 
> A pluch'.
> 
> Sylvain
> 	
> 
> Le jeudi 07 septembre 2006 à 15:11 +0200, Didier Lebrun a écrit :
>> salut,
>>
>> Maintenant qu'on a réalisé la jonction entre les réseaux de Vaournet et 
>> du Plateau Cordais, on tombe dans le cas d'un réseau multi-passerelles 
>> en OLSR, d'autant qu'on recherche au moins une connexion ADSL 
>> supplémentaire pour écouler le trafic de nos deux réseaux.
>>
>> J'ai testé le plugin DYN_GW en renseignant quelques PlParam "Ping" dans 
>> /etc/init.d/S53olsrd et en enlevant l'entrée statique du HNA4 dans la 
>> config. Ca fonctionne nickel, à un détail près.
>>
>> Le détail en question, c'est que le réacheminement vers les autres 
>> passerelles s'opère pour tout le réseau,... sauf pour ceux qui sont 
>> directement raccordés à la passerelle en question (ports LAN et clients 
>> wifi connectés par WLDHCP). C'est dû au fait que la connexion internet 
>> fait l'objet d'une route statique (wan_gateway) sur le routeur en 
>> question, qui n'est pas affectée par le routage OLSR. C'est notre cas 
>> avec la modem sat, qui se comporte comme une passerelle, et c'est sans 
>> doute aussi le cas avec les FreeBox, AliceBox, LiveBox, etc... Ca ne 
>> serait sans doute pas le cas avec une connexion PPPoE directement reliée 
>> au port WAN, dont la route disparaît quand la connexion tombe.
>>
>> En revanche, les autres noeuds OLSR du réseau wifi sont bien réacheminés 
>> vers les autres passerelles, y compris ceux qui transitent par le noeud 
>> de la passerelle. J'ai pu contourner le problème en raccordant les 
>> postes clients via wifi, en tant que noeud OLSR (carte wifi + démon 
>> OLSR), mais je me demande s'il ne serait pas possible de faire en sorte 
>> que les clients LAN se comportent comme des noeuds OLSR ? Est-ce que 
>> quelqu'un a déjà fait ça ou a des infos à ce propos ?
>>
>> @+
>>


-- 
Didier Lebrun
Le bourg - 81140 - Vaour (France)
tél: 05.63.53.73.41 (après-midi et soirée, même très tard ;-)
mailto:dl at vaour.net
http://didier.vaour.net/





More information about the Ran mailing list