[Ran] dyngw revisité

Didier Lebrun dl at vaour.net
Ven 15 Sep 20:56:45 CEST 2006


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

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