[Ran] dyngw revisité

Didier Lebrun dl at vaour.net
Sam 16 Sep 21:29:33 CEST 2006


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