Hello la liste, et bonne année à toutes et tous !!
Je viens de me confronter à un joli truc bien chiant lié à ces fameux icmp redirects. Pour des raisons plus ou moins à la noix, j'ai besoin de les accepter. Jusque là, en théorie aucun problème.
Mon soucis est que je récupère certains redirects pour joindre des IP FailOver (logique, non ??) mais quand cette jolie IP FO est déplacée de serveur, ben je ne peux plus la joindre depuis le LAN de mes serveurs.
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
Je la pos sur machine A, tout va bien, elle est visible de partout, y compris et surtout depuis MachineM. Je la déplace sur machine B, et tout le monde hors le réseau 10.10.149.0/24 la vois bien (le routeur fait bien son taf en 149.1)
Mais MachineM ne la ping plus du tout. Après recherche, je suis tombé sur le fait que: - ip route cache show => ne me donne rien du tout - ip route get 10.10.194.42 me donne: 10.10.194.24 via 10.10.149.182 dev eth0 src 10.10.149.42 cache <redirected>
Les commandes "ip route flush", "ip route flush cache" ou encore "ip route list cache match 10.10.194.42" ne changent absolument rien à ma problématique.
Un "simple" reboot corrige les choses (même si ce n'et pas viable sur le moyen/long terme), ou forcer une route spécifique qui override les inetpeer...
Est-ce qeu vous avez déjà rencontré ce problème, et si oui, quelle en a été la solution de votre coté ???
La MAC de ta FO est identique ou elle change ? blocage des arps ? Dans tous cas lors d’un failover je force un gratuitious arp. machine virtuelle ? filtrage dans l’hyperviseur ?
bref une tonne de possibilité… remonte les couches OSI. Je commencerais par les tables ARPs.
On 15 January 2019 at 16:12:52, Sébastien COUREAU (lifo@lifo.fr) wrote:
Hello la liste, et bonne année à toutes et tous !!
Je viens de me confronter à un joli truc bien chiant lié à ces fameux icmp redirects. Pour des raisons plus ou moins à la noix, j'ai besoin de les accepter. Jusque là, en théorie aucun problème.
Mon soucis est que je récupère certains redirects pour joindre des IP FailOver (logique, non ??) mais quand cette jolie IP FO est déplacée de serveur, ben je ne peux plus la joindre depuis le LAN de mes serveurs.
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
Je la pos sur machine A, tout va bien, elle est visible de partout, y compris et surtout depuis MachineM. Je la déplace sur machine B, et tout le monde hors le réseau 10.10.149.0/24 la vois bien (le routeur fait bien son taf en 149.1)
Mais MachineM ne la ping plus du tout. Après recherche, je suis tombé sur le fait que: - ip route cache show => ne me donne rien du tout - ip route get 10.10.194.42 me donne: 10.10.194.24 via 10.10.149.182 dev eth0 src 10.10.149.42 cache <redirected>
Les commandes "ip route flush", "ip route flush cache" ou encore "ip route list cache match 10.10.194.42" ne changent absolument rien à ma problématique.
Un "simple" reboot corrige les choses (même si ce n'et pas viable sur le moyen/long terme), ou forcer une route spécifique qui override les inetpeer...
Est-ce qeu vous avez déjà rencontré ce problème, et si oui, quelle en a été la solution de votre coté ???
Hello,
On Tue, 15 Jan 2019 16:12:04 +0100 Sébastien COUREAU lifo@lifo.fr wrote:
Mon soucis est que je récupère certains redirects pour joindre des IP FailOver (logique, non ??) mais quand cette jolie IP FO est déplacée de serveur, ben je ne peux plus la joindre depuis le LAN de mes serveurs.
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 Un "simple" reboot corrige les choses (même si ce n'et pas viable sur le moyen/long terme), ou forcer une route spécifique qui override les inetpeer...
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 ?
Pau
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....
Pour moi, de ce que j’ai vu en tout cas, pas de soucis d’arp à proprement parler... et je ne vais pas déplacer la eth0 de MachineA lorsque je veux basculer IPFO vers MachineB (même si je suppose fortement que cela serait opérationnel.....)
@++
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, 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 ?
Hello,
Je viens mettre mon grain de sel car je ne suis pas certain d'avoir bien compris. Tu dis que tes deux machines A et B partagent l'IP failover simultanément et que tu changes des routes pour basculer de l'une à l'autre ? Ai-je bien compris ?
Pourquoi ne pas utiliser de solution de failover genre corosync ?
Joël
-----Message d'origine----- De : FRsAG [mailto:frsag-bounces@frsag.org] De la part de Sebastien Coureau Envoyé : mardi 15 janvier 2019 17:23 À : Paul Rolland (ポール・ロラン) Cc : frsag@frsag.org Objet : Re: [FRsAG] Linux kernels - ICMP redirects
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 ?
Joël, C’est exactement cela pour la première partie de ton mail. Pour la seconde... Je vais me faire fouter, bruler, épingler et bien pire encore avec la réponse: parce que 1°) je ne connaissais pas, 2°) tout seul, les journées ne font que 24h (et seulement un court temps ^^)
Désolé pour FRnOG qui lit en parallèle, shame on me !!!
Sébastien,
Rapidement, quelques questions de comprehension :
1/ Pourquoi l'IP FO n'est pas dans le même subnet? contrainte metier? ou "erreur" de débutant?
Dans le cas ou c'est une contrainte métier : 2/ Pourquoi ne pas utiliser un IGP pour gérer le routage comme il se doit? ça n'évitera pas toutes* les merdes de cache des ICMP redirect, mais ça aura au moins le merite de changer la route tout seul.
Encore que, si tu a ton bird/quagga/FRR sur toutes les machines, tout peut se mettre à jour tout seul. Mais ça deviens plus lourd à gérer.
Bref, 2/3 petites questions rapides pour comprendre :)
Cordialement,
Le 2019-01-15 17:34, Sebastien Coureau a écrit :
Joël, C’est exactement cela pour la première partie de ton mail. Pour la seconde... Je vais me faire fouter, bruler, épingler et bien pire encore avec la réponse: parce que 1°) je ne connaissais pas, 2°) tout seul, les journées ne font que 24h (et seulement un court temps ^^)
Désolé pour FRnOG qui lit en parallèle, shame on me !!!
-- Sébastien Coureau Graal Network
Le 15 janv. 2019 à 17:30, Joel DEREFINKO joel.derefinko@118218.fr a écrit :
Hello,
Je viens mettre mon grain de sel car je ne suis pas certain d'avoir bien compris. Tu dis que tes deux machines A et B partagent l'IP failover simultanément et que tu changes des routes pour basculer de l'une à l'autre ? Ai-je bien compris ?
Pourquoi ne pas utiliser de solution de failover genre corosync ?
Joël
-----Message d'origine----- De : FRsAG [mailto:frsag-bounces@frsag.org] De la part de Sebastien Coureau Envoyé : mardi 15 janvier 2019 17:23 À : Paul Rolland (ポール・ロラン) Cc : frsag@frsag.org Objet : Re: [FRsAG] Linux kernels - ICMP redirects
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/
Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour,
On Tue, 15 Jan 2019 17:34:58 +0100 Sebastien Coureau lifo@lifo.fr wrote:
C’est exactement cela pour la première partie de ton mail.
La meme IP sur deux machines ? Hmmm, @Home, c'est un "Please don't !"
J'espere que ton IP en question n'est pas visible sur le LAN, parce que sinon, ca doit etre un peu fun cote MAC/ARP...
Par contre, si tu la mets sur une loopback, et que ton ip route add/del, tu le fais en dirigeant IPFO vers l'IP des eth0 (qui sont elles differentes), ca peut le faire un peu mieux...
Pau
Bonsoir,
La meme IP sur deux machines ? Hmmm, @Home, c'est un "Please don't !"
;)
J'espere que ton IP en question n'est pas visible sur le LAN, parce que sinon, ca doit etre un peu fun cote MAC/ARP...
C'est pour ca qu'elle n'est pas dans le même /24 ;)
Par contre, si tu la mets sur une loopback, et que ton ip route add/del, tu le fais en dirigeant IPFO vers l'IP des eth0 (qui sont elles differentes), ca peut le faire un peu mieux...
Fût une époque où je les aurais mêmes mise sur une tun/tap quelconque ;) Mais oui, il faut (faut qu'on, y'a qu'a....) que je me penche très sérieusement sur ces choses...
[..]
1/ Pourquoi l'IP FO n'est pas dans le même subnet? contrainte metier? ou "erreur" de débutant?
Pour la raison plus haut, et surtout parce que si il y a bien un truc que j'ai appris dans ma petite expérience c'est de ne surtout pas faire confiance aux utilisateurs "root"... Donc la réponse est "contrainte métier"
2/ Pourquoi ne pas utiliser un IGP pour gérer le routage comme il se doit? ça n'évitera pas toutes* les merdes de cache des ICMP redirect, mais ça aura au moins le merite de changer la route tout seul.
A moins de ne dire une grosse bêtise, l'IGP ne me permettra que de répliquer le routage sur ma GW-slave-HSRP-and-co, ou alors je pose l'IGP entre les 2 box linux, et là clairement le client derrière (pour lequel mon $job n'est "que" l'hébergeur) va encore être plus paumé que d'habitude.... non ?
Encore que, si tu a ton bird/quagga/FRR sur toutes les machines, tout peut se mettre à jour tout seul. Mais ça deviens plus lourd à gérer.
Pour suivre également FRnOG - pour pleins de raisons, mais la principale étant la culture et l'apprentissage de choses inexistantes à $job - ca fait partie des choses que j'aimerais creuser... Mais $job, même si il possède son AS et quelques IPv4 et quelques (beaucoup trop ^^) IPv6 ne fait que annoncer les LANs connectés en BGP à $FAI/$ISP/$Transits Donc pour moi (aurais-je tord ???), c'est un peu comme mettre un moteur de Ferrari dans une Ford pour rouler juste au dessus des limites de vitesses.... (j'aime bien les F ^^)
[..]
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....
Ouep... Du bon gros Serv-1U qui pique de tous les cotés.... et malheureusement, $client n'a pas forcément envie de rebooter - y compris pour de la bonne MAJ de kernel, et encore moins pour de la mise en place de TLSv1.3 alors pour un kernel "qui fonctionne, y'a pas besoin" (ben en fait, si, peut-être...)
T'as essayé quand même: ip route flush A.B.C.D/32 ?
Méa culpa ! Je n'ai même pas pensé à ajouter le subnet dans le flush.. pourtant flusher une route sans subnet c'est quand même très risqué... Will see next time !
En tous cas, merci à toutes vos réponses !!!
Et si jamais quelqu'un avec un zouli kernel 3.x a une soluce, je prends, parce que même si ledit kernel sera updaté très rapidement, ca ne coûte rien d'apprendre - bien au contraire...
Hello,
J'ai regardé ce thread, assez rapidement il est vrai, mais des questions se posent :)
Quand tu ajoute 'l'ip en .42', le fais-tu en ip alias ou un /32 sur le loopback. Je pense que tu dois probablement le mettre en ip alias sur eth0 (ou équivalent).
Le problème des linux (qui existe depuis la nuit des temps), c'est que quand tu ajoute une ip sur eth0, le kernel ne fait pas de gratuitous arp, en gros ne fait pas sur le reseau "coucou je m'appelle 00:11:22:33:44:55 et j'ai aussi l'ip 10.10.xx.42. Conclusion les autres OS n'invalident pas le cache ET SURTOUT le cisco devant.
C'est un bug^H^H^Hfeature de Linux que les autres OS n'ont pas. Il faut alors avec l'outil adéquat (lequel, je ne sais plus, je suis en train d'éradiquer tous les linux de mon taf pour y mettre des freebsd), afin de faire ce gratuitous arp.
Attention comme dis David aux machins qui font proxy arp... qui peuvent foutre la zone.
/Xavier
Le Tue, Jan 15, 2019 at 05:34:58PM +0100, Sebastien Coureau a écrit:
Pourquoi ne pas utiliser de solution de failover genre corosync ?
Pour la seconde... Je vais me faire fouter, bruler, épingler et bien pire encore avec la réponse: parce que 1°) je ne connaissais pas, 2°) tout seul, les journées ne font que 24h (et seulement un court temps ^^)
Ou un keepalived: http://www.keepalived.org/
Ca fait très bien le boulot aussi. Question de goût, je suppose.
Arnaud.
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/
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 ???
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 mailto: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 mailto: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 mailto:rol+frsag@witbe.net> a écrit :
Salut Sebastien,
On Tue, 15 Jan 2019 16:56:22 +0100 Sebastien Coureau <lifo@lifo.fr mailto: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 http://witbe.net/ CTO - Witbe.net http://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/ http://www.frsag.org/
Vérifie s’il y a pas un proxy-arp activé par défaut qqpart, on sait jamais.
Le 15 janv. 2019 à 16:56, Sebastien Coureau lifo@lifo.fr a écrit :
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....
Pour moi, de ce que j’ai vu en tout cas, pas de soucis d’arp à proprement parler... et je ne vais pas déplacer la eth0 de MachineA lorsque je veux basculer IPFO vers MachineB (même si je suppose fortement que cela serait opérationnel.....)
@++
Sébastien Coureau Graal Network
Pau
Paul Rolland E-Mail : rol(at)witbe.net http://witbe.net/ CTO - Witbe.net http://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 navigateu "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/
Le 15 janv. 2019 à 17:10, David Ponzone david.ponzone@gmail.com a écrit :
Vérifie s’il y a pas un proxy-arp activé par défaut qqpart, on sait jamais.
Merci David, je n’avais pas pensé à regarder cela, mais sans succès.... En même temps, à moins d’écrire une bêtise plus grosse que moi (bon, pas compliqué non plus....) la table des inetpeers ne bosse pas sur les mac-addr, mais bien sur les IPv(4|6) non ?
-
Arnaud Launay -
David Ponzone -
Joel DEREFINKO -
Paul Rolland (ポール・ロラン) -
professor geek -
Richard DEMONGEOT -
Sébastien COUREAU -
Xavier Beaudouin