On peut voir ici (c'est ce qui va nous intéresser par la suite) la
route vers 172.31.6.61 lorsqu'on veut joindre l'hôte 195.221.98.17.
Le truc qui m'a surpris, c'est que, lors d'un :
ping 195.221.98.17
sur ce serveur, tcpdump m'indiquait que les trames qui partaient de xenbr0
n'avaient pas pour adresse MAC de destination l'adresse MAC de 172.31.6.61
mais celle d'une autre interface d'une autre machine. Or, pourtant l'interface
172.31.6.61 se situe sur le *même* réseau ethernet (sur le même switch en fait).
D'ailleurs, quand je pinge directement l'IP 172.31.6.61, j'ai bien
des trames qui partent avec comme adresse MAC de destination celle de
l'interface 172.31.6.61.
Après de longues recherches infructueuses, un collège m'a indiqué la solution.
En effet, suite à une panne, la route
a été inaccessible pendant un certain temps. Et apparemment, sous de telles
conditions, il y aurait une fonctionnalité du kernel qui ferait sauter la
route statique (pensant bien faire) et qui malheureusement ne la restituerait
pas automatiquement une fois la route accessible.
Ce qui m'a coûté pas mal de temps, c'est que la commande « route -n » ne
le dit pas (voir ci-dessus), la commande « ip route list » non plus. En fait,
on peut le voir avec ça : (je mets en évidence les lignes intéressantes)
~# ip route show cache
local 172.31.253.7 from 195.221.98.181 dev lo src 172.31.253.7
cache <local> ipid 0x535f iif xenbr0
broadcast 255.255.255.255 dev lo src 192.168.19.7
cache <local,brd> iif xenbr1
broadcast 192.168.19.255 from 192.168.19.151 dev lo src 192.168.19.7
cache <local,brd,src-direct> iif xenbr1
local 127.0.0.1 dev lo src 127.0.0.1
cache <local>
multicast 224.0.0.1 from 192.168.19.151 dev lo src 192.168.19.7
cache <local,mc> iif xenbr1
broadcast 172.31.255.255 from 172.31.0.151 dev lo src 172.31.253.7
cache <local,brd> iif xenbr3
172.31.0.62 from 172.31.253.7 dev xenbr0
cache ipid 0x5a11
multicast 224.0.0.1 from 172.31.0.151 dev lo src 172.31.253.7
cache <local,mc> iif xenbr3
local 127.0.0.1 from 127.0.0.1 dev lo
cache <local>
multicast 224.0.0.1 dev lo src 192.168.21.7
cache <local,mc> iif xenbr3
local 172.31.253.7 from 172.31.0.182 dev lo src 172.31.253.7
cache <local,src-direct> iif xenbr0
172.31.0.182 from 172.31.253.7 dev xenbr0
cache
multicast 224.0.0.1 dev lo src 172.31.253.7
cache <local,mc> iif xenbr0
local 172.31.253.7 from 172.31.6.61 dev lo src 172.31.253.7
cache <local,src-direct> ipid 0x535f iif xenbr0
195.221.98.181 from 172.31.253.7 via 172.31.6.61 dev xenbr0
cache
172.31.0.36 from 172.31.253.7 dev xenbr0
cache ipid 0x3a4e rtt 10ms rttvar 6ms cwnd 10
172.31.0.36 from 172.31.253.7 tos lowdelay dev xenbr0
cache ipid 0x3a4e rtt 10ms rttvar 6ms cwnd 10
broadcast 172.31.255.255 from 172.31.0.151 dev lo src 172.31.253.7
cache <local,brd,src-direct> iif xenbr0
broadcast 192.168.19.255 from 192.168.19.119 dev lo src 192.168.19.7
cache <local,brd,src-direct> iif xenbr1
local 172.31.253.7 from 195.221.98.17 dev lo src 172.31.253.7
cache <local> ipid 0x535f iif xenbr0
multicast 224.0.0.1 dev lo src 192.168.20.7
cache <local,mc> iif xenbr2
172.31.1.132 from 172.31.253.7 dev xenbr0
cache ipid 0x0e4a rtt 35ms rttvar 38ms cwnd 10
local 172.31.253.7 from 172.31.0.62 dev lo src 172.31.253.7
cache <local,src-direct> iif xenbr0
local 172.31.253.7 from 172.31.0.36 dev lo src 172.31.253.7
cache <local,src-direct> ipid 0x535f iif xenbr0
local 172.31.253.7 from 172.31.0.36 tos lowdelay dev lo src 172.31.253.7
cache <local,src-direct> ipid 0x535f iif xenbr0
172.31.23.201 from 172.31.253.7 dev xenbr0
cache ipid 0xd7c3 rtt 8ms rttvar 8ms cwnd 10
multicast 224.0.0.1 dev lo src 192.168.19.7
cache <local,mc> iif xenbr1
multicast 224.0.0.1 from 172.31.0.151 dev lo src 172.31.253.7
cache <local,mc> iif xenbr0
local 172.31.253.7 from 172.31.23.201 dev lo src 172.31.253.7
cache <local,src-direct> iif xenbr0
broadcast 192.168.19.255 from 192.168.19.120 dev lo src 192.168.19.7
cache <local,brd,src-direct> iif xenbr1
172.31.1.132 dev xenbr0 src 172.31.253.7
cache ipid 0x0e4a rtt 35ms rttvar 38ms cwnd 10
local 172.31.253.7 from 172.31.1.132 dev lo src 172.31.253.7
cache <local,src-direct> iif xenbr0
----------------------LÀ----------------------
195.221.98.17 from 172.31.253.7 via 62.210.98.62 dev xenbr0
cache <redirected> ipid 0x2909 ts 0xb92dfb1 tsage 204566sec rtt 38ms rttvar 18ms cwnd 10
----------------------LÀ----------------------
195.221.98.17 via 62.210.98.62 dev xenbr0 src 172.31.253.7
cache <redirected> ipid 0x2909 ts 0xb92dfb1 tsage 204566sec rtt 38ms rttvar 18ms cwnd 10
broadcast 172.31.255.255 from 172.31.87.93 dev lo src 172.31.253.7
cache <local,brd,src-direct> iif xenbr0
172.31.0.62 dev xenbr0 src 172.31.253.7
cache ipid 0x5a11
broadcast 172.31.255.255 from 172.31.87.93 dev lo src 172.31.253.7
cache <local,brd> iif xenbr3
Comme on peut voir, pour mon plus grand bien, le kernel a
décidé qu'un paquet vers 195.221.98.17 serait routé non pas
vers 172.31.6.61, comme indiqué en tant que route statique,
mais vers 62.210.98.62 ce qui explique pourquoi l'adresse MAC
de destination ne correspondait pas à celle de 172.31.6.61
(qui est pourtant sur le même réseau physique).
Je ne l'ai pas fait encore car je préfère garder le serveur
en l'état pour divers tests, mais il paraît qu'après un :
ip route flush cache
Tout redevient « normal ». En gros, si je comprends bien, cela vide
le cache des routes du kernel et on repart de zéro.
Voici ma question : comment faire pour que cette fonctionnalité
de « mise à jour » automatique des routes statiques ne se fasse
pas et que, le kernel me garde ma route statique vaille que vaille ?
À moins que ce soit une mauvaise idée de faire ça ? Je suis
ouvert à toute remarque et discussion sur le sujet.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Francois Lafont
Le 17/02/2014 12:45, Francois Lafont a écrit :
Voici ma question : comment faire pour que cette fonctionnalité de « mise à jour » automatique des routes statiques ne se fasse pas et que, le kernel me garde ma route statique vaille que vaille ? À moins que ce soit une mauvaise idée de faire ça ? Je suis ouvert à toute remarque et discussion sur le sujet.
J'ajoute ceci également comme question : comment reproduire cette mise à jour de route statique ? Il faut faire tomber l'IP de destination (195.221.97.17 dans mon cas) ? Si oui pendant combien de temps avant que la mise à jour se fasse ?
-- François Lafont
Le 17/02/2014 12:45, Francois Lafont a écrit :
Voici ma question : comment faire pour que cette fonctionnalité
de « mise à jour » automatique des routes statiques ne se fasse
pas et que, le kernel me garde ma route statique vaille que vaille ?
À moins que ce soit une mauvaise idée de faire ça ? Je suis
ouvert à toute remarque et discussion sur le sujet.
J'ajoute ceci également comme question : comment reproduire cette
mise à jour de route statique ? Il faut faire tomber l'IP de
destination (195.221.97.17 dans mon cas) ? Si oui pendant combien
de temps avant que la mise à jour se fasse ?
Voici ma question : comment faire pour que cette fonctionnalité de « mise à jour » automatique des routes statiques ne se fasse pas et que, le kernel me garde ma route statique vaille que vaille ? À moins que ce soit une mauvaise idée de faire ça ? Je suis ouvert à toute remarque et discussion sur le sujet.
J'ajoute ceci également comme question : comment reproduire cette mise à jour de route statique ? Il faut faire tomber l'IP de destination (195.221.97.17 dans mon cas) ? Si oui pendant combien de temps avant que la mise à jour se fasse ?
-- François Lafont
Francois Lafont
Le 17/02/2014 14:21, Francois Lafont a écrit :
J'ajoute ceci également comme question : comment reproduire cette mise à jour de route statique ? Il faut faire tomber l'IP de destination (195.221.97.17 dans mon cas) ?
^^^^^^^^^^^^^
Je voulais écrire 195.221.98.17 bien sûr.
-- François Lafont
Le 17/02/2014 14:21, Francois Lafont a écrit :
J'ajoute ceci également comme question : comment reproduire cette
mise à jour de route statique ? Il faut faire tomber l'IP de
destination (195.221.97.17 dans mon cas) ?
J'ajoute ceci également comme question : comment reproduire cette mise à jour de route statique ? Il faut faire tomber l'IP de destination (195.221.97.17 dans mon cas) ?
^^^^^^^^^^^^^
Je voulais écrire 195.221.98.17 bien sûr.
-- François Lafont
Fred
On 17/02/2014 12:45, Francois Lafont wrote:
Bonjour à tous,
Salut
Voici ma question : comment faire pour que cette fonctionnalité de « mise à jour » automatique des routes statiques ne se fasse pas et que, le kernel me garde ma route statique vaille que vaille ?
Il y a une option du kernel "IP: advanced router" qui se trouve dans Networking support / Networking option / TCP/IP networking et qui pourrait être responsable de ton problème.
L'option n'est pas activée par défaut donc pas indispensable.
Elle est activée sur slackware par exemple.
Si tu as les sources installées, tu peux le voir avec ça: grep CONFIG_IP_ADVANCED_ROUTER /usr/src/linux/.config
À moins que ce soit une mauvaise idée de faire ça ?
Si ça évite de se retrouver avec une table de routage incomplete.
Voici ma question : comment faire pour que cette fonctionnalité
de « mise à jour » automatique des routes statiques ne se fasse
pas et que, le kernel me garde ma route statique vaille que vaille ?
Il y a une option du kernel "IP: advanced router" qui se trouve dans
Networking support / Networking option / TCP/IP networking et qui
pourrait être responsable de ton problème.
L'option n'est pas activée par défaut donc pas indispensable.
Elle est activée sur slackware par exemple.
Si tu as les sources installées, tu peux le voir avec ça:
grep CONFIG_IP_ADVANCED_ROUTER /usr/src/linux/.config
À moins que ce soit une mauvaise idée de faire ça ?
Si ça évite de se retrouver avec une table de routage incomplete.
Voici ma question : comment faire pour que cette fonctionnalité de « mise à jour » automatique des routes statiques ne se fasse pas et que, le kernel me garde ma route statique vaille que vaille ?
Il y a une option du kernel "IP: advanced router" qui se trouve dans Networking support / Networking option / TCP/IP networking et qui pourrait être responsable de ton problème.
L'option n'est pas activée par défaut donc pas indispensable.
Elle est activée sur slackware par exemple.
Si tu as les sources installées, tu peux le voir avec ça: grep CONFIG_IP_ADVANCED_ROUTER /usr/src/linux/.config
À moins que ce soit une mauvaise idée de faire ça ?
Si ça évite de se retrouver avec une table de routage incomplete.
Il y a une option du kernel "IP: advanced router" qui se trouve dans Networking support / Networking option / TCP/IP networking et qui pourrait être responsable de ton problème.
L'option n'est pas activée par défaut donc pas indispensable.
Si je comprends bien, tu parles ici d'options de compilation du noyau. N'y a-t-il pas des options que l'on peut passer directement au noyau sans avoir besoin de recompiler ?
-- François Lafont
Bonsoir,
Le 17/02/2014 15:29, Fred a écrit :
Il y a une option du kernel "IP: advanced router" qui se trouve dans
Networking support / Networking option / TCP/IP networking et qui
pourrait être responsable de ton problème.
L'option n'est pas activée par défaut donc pas indispensable.
Si je comprends bien, tu parles ici d'options de compilation du noyau.
N'y a-t-il pas des options que l'on peut passer directement au
noyau sans avoir besoin de recompiler ?
Il y a une option du kernel "IP: advanced router" qui se trouve dans Networking support / Networking option / TCP/IP networking et qui pourrait être responsable de ton problème.
L'option n'est pas activée par défaut donc pas indispensable.
Si je comprends bien, tu parles ici d'options de compilation du noyau. N'y a-t-il pas des options que l'on peut passer directement au noyau sans avoir besoin de recompiler ?
-- François Lafont
Eric Belhomme
Le Mon, 17 Feb 2014 15:29:54 +0100, Fred a écrit :
Il y a une option du kernel "IP: advanced router" qui se trouve dans Networking support / Networking option / TCP/IP networking et qui pourrait être responsable de ton problème.
L'option n'est pas activée par défaut donc pas indispensable.
Elle est activée sur slackware par exemple.
Si tu as les sources installées, tu peux le voir avec ça: grep CONFIG_IP_ADVANCED_ROUTER /usr/src/linux/.config
Cette option de compilation sert seulement à positioner à 1 par défaut la valeur de /proc/sys/net/ipv4/ip_forward En clair, elle se contente d'activer le routage dès le boot time, rien à voir avec le problème soulevé par François.
Concernant le problème initialement soulevé, désolé, ca peut peut être du à la configuration de tes interfaces ? As-tu regardé du coté de /proc/sys/net/ipv4/conf/*/accept_redirects ?
-- Rico
Le Mon, 17 Feb 2014 15:29:54 +0100, Fred a écrit :
Il y a une option du kernel "IP: advanced router" qui se trouve dans
Networking support / Networking option / TCP/IP networking et qui
pourrait être responsable de ton problème.
L'option n'est pas activée par défaut donc pas indispensable.
Elle est activée sur slackware par exemple.
Si tu as les sources installées, tu peux le voir avec ça:
grep CONFIG_IP_ADVANCED_ROUTER /usr/src/linux/.config
Cette option de compilation sert seulement à positioner à 1 par défaut la
valeur de /proc/sys/net/ipv4/ip_forward
En clair, elle se contente d'activer le routage dès le boot time, rien à
voir avec le problème soulevé par François.
Concernant le problème initialement soulevé, désolé, ca peut peut être du
à la configuration de tes interfaces ? As-tu regardé du coté de
/proc/sys/net/ipv4/conf/*/accept_redirects ?
Le Mon, 17 Feb 2014 15:29:54 +0100, Fred a écrit :
Il y a une option du kernel "IP: advanced router" qui se trouve dans Networking support / Networking option / TCP/IP networking et qui pourrait être responsable de ton problème.
L'option n'est pas activée par défaut donc pas indispensable.
Elle est activée sur slackware par exemple.
Si tu as les sources installées, tu peux le voir avec ça: grep CONFIG_IP_ADVANCED_ROUTER /usr/src/linux/.config
Cette option de compilation sert seulement à positioner à 1 par défaut la valeur de /proc/sys/net/ipv4/ip_forward En clair, elle se contente d'activer le routage dès le boot time, rien à voir avec le problème soulevé par François.
Concernant le problème initialement soulevé, désolé, ca peut peut être du à la configuration de tes interfaces ? As-tu regardé du coté de /proc/sys/net/ipv4/conf/*/accept_redirects ?
-- Rico
Nicolas George
Eric Belhomme , dans le message <53030eae$0$2211$, a écrit :
Cette option de compilation sert seulement à positioner à 1 par défaut la valeur de /proc/sys/net/ipv4/ip_forward En clair, elle se contente d'activer le routage dès le boot time, rien à voir avec le problème soulevé par François.
« The answer to this question won't directly affect the kernel: answering N will just cause the configurator to skip all the questions about advanced routing. »
Eric Belhomme , dans le message <53030eae$0$2211$426a74cc@news.free.fr>,
a écrit :
Cette option de compilation sert seulement à positioner à 1 par défaut la
valeur de /proc/sys/net/ipv4/ip_forward
En clair, elle se contente d'activer le routage dès le boot time, rien à
voir avec le problème soulevé par François.
« The answer to this question won't directly affect the kernel: answering N
will just cause the configurator to skip all the questions about advanced
routing. »
Eric Belhomme , dans le message <53030eae$0$2211$, a écrit :
Cette option de compilation sert seulement à positioner à 1 par défaut la valeur de /proc/sys/net/ipv4/ip_forward En clair, elle se contente d'activer le routage dès le boot time, rien à voir avec le problème soulevé par François.
« The answer to this question won't directly affect the kernel: answering N will just cause the configurator to skip all the questions about advanced routing. »
