[Ran] dyngw revisité

Didier Lebrun dl at vaour.net
Jeu 14 Sep 15:45:43 CEST 2006


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 ?

@+

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