Ben les mises.à jour de Kernel, ça fait pas de mal de temps en temps quand même :)
C’est pas parce que c’est linux que c’est parfait depuis 20 ans.

Si c’est virtualisé, c’est vite fait de revenir en arrière si ça déconne.
Evidememnt, en bare-metal, c’est plus délicat….

T’as essayé quand même: ip route flush A.B.C.D/32 ?

Le 15 janv. 2019 à 17:42, Sebastien Coureau <lifo@lifo.fr> a écrit :

Merci David !

Pour le « flush », non, aucun effet, d’autant que la commande « ip route ls » ne l’affiche pas... La seule commande que j’ai trouvé qui m’a permis de voir l’existence de cette route est « ip route get A.B.C.D », et la seule solution - parce que toujours dans l’urgence -  a été le reboot (plutot que d’installer la tétrachiée de mise à jour qui auraient pu induire bien pire....)

Donc ca « confirme » la couche « bug du kernel » à laquelle je m’attendais un peu, mais (ok, je switch pas les IPFO tous les jours...) le reboot ne peut/doit pas être la seule solution ???

-- 
Sébastien Coureau
Graal Network

Le 15 janv. 2019 à 17:35, David Ponzone <david.ponzone@gmail.com> a écrit :

ip route flush cache

Ça marche pas ?

Apparement, le GC qui est censé nettoyer le cache toutes les 300s est buggué dans certains kernels 3.x:

Resolution
This issue was resolved in RHSA-2016-2574 with package kernel-3.10.0-514.el7.
Root Cause
The sysctl net.ipv4.route.gc_timeout should control the route cache expiration time (in seconds). It defaults to 300 seconds. The route cache garbage collection routines appear to never run.


Le 15 janv. 2019 à 17:23, Sebastien Coureau <lifo@lifo.fr> a écrit :

Paul,
Désolé... gérer réseau, mails, et emmerdes au quotidien ne fait pas forcément bon ménage lorsque l’on cherche à exprimer quelque chose ;)

Donc... MachineA et MachineB handlent en permanence l’IPFO en /32 (donc avec la mac de eth0 de chacun des 2 serveurs).

Je modifie le routage directement dans ma GW via les commandes Cisco qui vont bien (no ip route IPFO/32 MachineA;; ip route IPFO/32 MachineB)

Le seul soucis d’arp (et donc seulement pendant 300 secondes max) se passe au niveau du routeur, sauf si on lui dit de virer l’entrée ARP de IPFO et/ou en la forcant sur la mac de MachineB.

Mon « vrai » soucis est que MachineM maintient en cache une table de routage RIP (via ICMP Redirects), et cette table ne me semble absolument pas nettoyable. Une fois encore cette « route » n’est visible que par la commande « ip route get A.B.C.D »

J’ai creusé les RTFM-by-Google et il semblerait que ce genre de soucis remontent à certains kernel 3.x++ (sans garantie ni certitude)

Est-ce plus clair ?


--
Sébastien Coureau

Le 15 janv. 2019 à 17:06, Paul Rolland (ポール・ロラン) <rol+frsag@witbe.net> a écrit :

Salut Sebastien,

On Tue, 15 Jan 2019 16:56:22 +0100
Sebastien Coureau <lifo@lifo.fr> wrote:

Re,

Plusieurs questions :
- as-tu regarde ton cache ARP ?
- est-ce que ton IP FO change d'ARP quand elle passe de machine A a
machine B ?
- quelle est la techno que tu utilises pour le FO ?  

Alors:
- cache arp vide, et quand bien même, vu qu’on est pas sur le même réseau
(au sens subnet du terme), pas d’arp autre que celle de la eth0:0 (ou
équivalent)
- j’avais bien évidement fait un « ip clear arp xxxx.yyyy » sur le dit
routeur (Cisco)
- la techno utilisée pour transférer l’IP est l’équivalent d’un simple «
no ip route / ip route »

MA vraie problématique est qu’en ajoutant sur MachineM un « route add
-host IPFO gw MachineB » ca fonctionne, alors que les inetpeers « ip
route get » montrent toujours la table de routage vers l’ancienne
marchine....

Attends, y'a un truc pas clair... Tu as ecrit :
Un petit exemple un poil plus précis:
Machine A: 10.10.149.182/24
Machine B: 10.10.149.128/24
Machine M(onitor): 10.10.149.42/24
GW: 10.10.149.1

Mon IP FO et la suivante: 10.10.194.42/32

A la lecture de ces elements, j'ai suppose que tu avais une typo sur
ton IP FO et que tu voulais ecrire 10.10._149_.42 (et pas _194_).
Ca veut dire que toutes les machines sont dans le meme reseau, et donc ARP
peut avoir son role a jouer...

Mais avec ton explication de bascule via "ip route add/del", la je suis
perdu sur ton setup...

Pau
--
Paul Rolland                                E-Mail : rol(at)witbe.net
CTO - Witbe.net SA                          Tel. +33 (0)1 47 67 77 77
Les Collines de l'Arche                     Fax. +33 (0)1 47 67 77 99
F-92057 Paris La Defense                    RIPE : PR12-RIPE

Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un
navigateur "Some people dream of success... while others wake up and work
hard at it"

"I worry about my child and the Internet all the time, even though she's
too young to have logged on yet. Here's what I worry about. I worry that 10
or 15 years from now, she will come to me and say 'Daddy, where were you
when they took freedom of the press away from the Internet?'"
--Mike Godwin, Electronic Frontier Foundation

_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/