[Ran] dyngw revisité

Didier Lebrun dl at vaour.net
Jeu 21 Sep 06:57:13 CEST 2006


Bonjour,

Je suis revenu encore une fois sur l'amélioration de la fonctionalité 
DynGW de Freifunk, pour aller un peu plus loin dans le perfectionnement 
de l'engin.

Le problème qui subsistait était que je n'arrivais pas à donner la 
priorité à une passerelle éloignée à meilleur débit (ADSL 256/2048K) 
plutôt qu'à une passerelle proche à débit médiocre (SAT 128/512K), en 
conservant toutefois la possibilité de basculer automatiquement sur la 
passerelle médiocre lorsque la liaison avec la passerelle éloignée est 
rompue, et inversement lorsque la liaison se rétablit.

Pour y arriver, il fallait revoir de fond en comble l'implémentation de 
la fonctionalité DynGW, en dissociant la détection du statut de 
passerelle de la métrique, de manière à pouvoir libérer la métrique pour 
  infléchir les priorités des différentes passerelles. Ca m'a pris deux 
jours, mais j'y suis arrivé. J'ai testé le mécanisme de failover dans 
les deux sens, et ça marche impec :-)

Pour donner une métrique arbitraire à une passerelle, il suffit de 
déclarer sa route par défaut au moyen d'une route statique. On peut 
alors spécifier la métrique qu'on souhaite.

syntaxe: ipdestination:masquesousréseau:ippasserelle:métrique:interface
exemple: 0.0.0.0:0.0.0.0:84.254.175.37:6:vlan1

Dans ce cas, je définit une métrique de 6, supérieure à la distance 
séparant les deux passerelles, qui varie entre 3 et 5 selon l'état des 
noeuds du réseau du plateau cordais. De cette manière la route locale 
passe derrière la route de l'autre passerelle tant que celle-ci fonctionne.

Avec cette méthode, il est possible également de faire aller un peu plus 
de trafic vers une passerelle que vers une autre, en définissant une 
métrique inférieure à la distance entre les deux. Le mécanisme 
fonctionne évidemment pareil avec plus de deux passerelles.

Voir:
http://www.vaour.net/wiki/Freifunk/AdditifsV1-2-5#toc6

@+

Didier Lebrun a écrit :
> Didier Lebrun a écrit :
>> Didier Lebrun a écrit :
>>> salut,
>>>
>>> Je me suis repenché sur la question du plugin dyngw d'OLSR, qui 
>>> fonctionne bien, sauf pour les clients qui sont directement raccordés 
>>> sur les ports LAN ou WLAN d'une passerelle dont la connexion est tombée. 
>>> Tout le reste du réseau est redirigé automatiquement vers les autres 
>>> passerelles, mais les clients locaux ont toujours comme route la défaut 
>>> la connexion défaillante.
>>>
>>> En consultant "ip route" et "ip rule", j'ai vu que dyngw crée une table 
>>> "dyngw", avec une ip rule qui s'intercale avant "main":
>>>
>>> root at vn1-dl:~# ip rule show
>>> 0:      from all lookup local
>>> 32765:  from all iif lo lookup dyngw
>>> 32766:  from all lookup main
>>> 32767:  from all lookup default
>>> root at vn1-dl:~#
>>>
>>> Quand la connexion locale est en service, la table dyngw est vide et la 
>>> table main contient les divers passerelles par défaut, dans l'ordre 
>>> correspondant à leur métrique. La route par défaut s'établit donc via la 
>>> première entrée "default ..." de la table main:
>>>
>>> root at vn1-dl:~# ip route show table dyngw (<= table dyngw vide)
>>> root at vn1-dl:~# ip route show table main
>>> ..
>>> default via 84.254.175.37 dev vlan1 (<= default utilisée)
>>> default via 10.169.170.1 dev eth1  metric 3 (<= default de secours)
>>> root at vn1-dl:~#
>>>
>>> Quand la connexion locale est HS, le plugin dyngw peuple la table dyngw 
>>> avec qqs entrées, et fait disparaître la route défaillante de la table 
>>> main.  La route par défaut des clients locaux s'établit donc via 
>>> l'entrée "default ..." de la table dyngw, qui pointe toujours vers la 
>>> connexion défaillante, et la route valide, qui est dans main, est ignorée:
>>>
>>> root at vn1-dl:~# ip route show table dyngw
>>> throw 84.254.175.36/30
>>> throw 192.168.0.0/24
>>> throw 10.168.0.0/14
>>> default via 84.254.175.37 dev vlan1 (<= default utilisée localement)
>>> root at vn1-dl:~# ip route show table main
>>> ..
>>> default via 10.169.170.1 dev eth1  metric 3 (<= default des autres)
>>> root at vn1-dl:~#
>>>
>>> C'est pas tout à fait un bug en ce sens que l'entrée default de la table 
>>> dyngw est nécessaire pour pouvoir continuer à pinguer vers l'extérieur, 
>>> dans l'espoir que la connexion se rétablisse. Par contre, c'est pas 
>>> pratique pour les clients locaux :-( Pour que ça soit top, il faudrait 
>>> restreindre le champ des entrées de la table dyngw aux seuls besoins des 
>>> ping, et laisser le reste à la table main.
>>>
>>> root at vn1-dl:~# ip route show table dyngw
>>> 12.34.56.78 via 84.254.175.37 dev vlan1 (<= adresse ping n°1)
>>> 123.45.67.89 via 84.254.175.37 dev vlan1 (<= adresse ping n°2)
>>> 87.65.43.21 via 84.254.175.37 dev vlan1 (<= adresse ping n°3)
>>> root at vn1-dl:~# ip route show table main
>>> ..
>>> default via 10.169.170.1 dev eth1  metric 3 (<= default pour tous)
>>> root at vn1-dl:~#
>>>
>>> NB: Les entrées throw ne sont plus nécessaires ici, puisque qu'elles 
>>> servaient seulement à exclure les routes locales de default, de manière 
>>> à aller les chercher dans main.
>>>
>>> La seule restriction qui subsiste alors est d'éviter de donner comme 
>>> adresses à pinguer des adresses que les clients du noeud local risquent 
>>> d'utiliser.
>>>
>>> J'ai essayé ça en modifiant les entrées de la table dyngw à la main, et 
>>> ça fonctionne bien comme prévu :-) Par contre, j'ai pas trouvé les 
>>> lignes de code du plugin dyngw qui fabriquent les entrées de la table 
>>> dyngw, de manière à les modifier en conséquence. Une alternative serait 
>>> de laisser le plugin dyngw tel quel, et de rajouter un script qui fasse 
>>> les modifs par dessus, avec une entrée de crontab qui teste l'état de la 
>>> table dyngw au même intervalle que les ping de dyngw ?
>>>
>>> Est-ce que quelqu'un a de meilleures idées à ce sujet ?
>>>
>>> @+
>>>
>> En continuant à creuser la question, j'ai trouvé que c'est dans 
>> /usr/sbin/cron.minutely que ça se passe. C'est ce script qui modifie les 
>> tables de routage en fonction de l'état de la connexion, en testant la 
>> connectivité par des commandes traceroute effectuées d'après une liste 
>> d'adresses indiquées de manière statique dans le script.
>>
>> Ce faisant, je me suis aperçu que les paramètres PlParam "Ping" 
>> "ADRESSE_IP" que j'avais mis dans /etc/olsrd.conf comptent pour du 
>> beurre, bien qu'ils figurent en tant que KEY,VALUE dans l'interface ! 
>> J'ai vérifié ça en faisant logger par le firewall les Ping aux adresses 
>> en question et en ne voyant rien venir, alors que si je lance un Ping 
>> manuel sur ces adresses, les logs du firewall le signalent bien. je 
>> suppose que l'option "Ping" du plugin a été désactivée dans Freifunk 
>> 1.2.5 au profit du test par traceroute dans le script !?
>>
>> Je commence à y voir plus clair, et je crois que je vais arriver à 
>> résoudre le problème en bidouillant un peu ce script.
>>
>> A suivre...
>>
> 
> Ca y est ! J'ai finalisé et expérimenté avec succès une variante du 
> script cron.minutely qui se comporte de manière satisfaisante :-) Je 
> l'ai mis sur le site de Vaournet:
> 
> 	http://www.vaour.net/wiki/Freifunk/AdditifsV1-2-5#toc6
> 
> @+
> 



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