Bonjour, brièvement, voici ma problématique : je dispose de 3 connexions ADSL "pro" pour répartir la bande-passante entre services / collaborateurs. Ce n'est pas forcément la meilleure façon de faire, mais ce n'est pas le sujet. Je ne vous surprendrai pas en vous affirmant que ces box plantent régulièrement. Quelques serveurs Linux utilisent une de ces 3 connexions, la plus fiable, via un autre fournisseur d'accès. Mais elle plante aussi... J'aurai aimé que lorsque cette connexion plante, que le serveur utilise une gateway secondaire, une route "failover". Déjà, il faut que le temps de bascule entre route soit plus rapide que les 60s par défaut : net.ipv4.route.gc_timeout = 10 Si j'ajoute une 2ème gateway, régulièrement on passe par celle-ci sans explication, ce qui est pénible. Je ne suis pas le seul à chercher ce type de solution, et les solutions _qui marchent_ relèvent de la bidouille : http://www.muug.mb.ca/** pipermail/roundtable/2005-May/**000881.html<http://www.muug.mb.ca/pipermail/roundtable/2005-May/000881.html> Vos solutions ? -- Greg ______________________________**_________________ Liste de diffusion du FRsAG http://www.frsag.org/

Salut, J'ai eu un peu le même problème que toi. J'ai 3 lignes internes distinctes ici : fibre Completel, SDSL Nerim et SDSL Orange. Pour les faire fonctionner toute de concert, j'ai monté un "routeur" soft, avec base de serveur Supermicro, carte réseau 4 ports, et une Debian :-) J'ai configuré les 3 interfaces "interne" dans mon /etc/network/interfaces directement, mais avec des metric différentes (ce qui permets d'avoir une préférence au niveau des routes). Donc si jamais mon premier lien tombe pour X ou Y raison, je fais simplement un "ifdown" de l'interface, et tout le trafic passe par le second lien, etc etc. J'ai pas encore eu le temps de scripter le failover automatiquement, mais à coup de "ping -I ethX" ça devrait pas être difficile. Au passage, ce setup m'a permis de créer des rules IP particulières : dans mon cas, je force toutes les IPs du subnet des téléphones SIP a utiliser une route de sortie différente de tout le reste du réseau. Mon setup a un inconvénient qui peut être un gros problème en fonction des FAI : pour que ça fonctionne parfaitement et surtout ne pas avoir à t'emmerder avec des règles de NAT dans tous les sens, il faut que toutes les box soient en mode bridge (donc que tu puisses attribuer une IP publique à tes interfaces locales sur le routeur). Au passage, si tu es joueur et que tu veux encore plus "blindé" ton installation, tu ajouter du bonding un peu partout :-) (notamment sur les pattes qui vont vers ton réseau local). Voilà, en espérant que ça t'aide ;-) Le 9 mai 2012 14:13, Gregory Duchatelet &lt;greg-frsag(a)duchatelet.net <mailto:greg-frsag@duchatelet.net>> a écrit : Bonjour, brièvement, voici ma problématique : je dispose de 3 connexions ADSL "pro" pour répartir la bande-passante entre services / collaborateurs. Ce n'est pas forcément la meilleure façon de faire, mais ce n'est pas le sujet. Je ne vous surprendrai pas en vous affirmant que ces box plantent régulièrement. Quelques serveurs Linux utilisent une de ces 3 connexions, la plus fiable, via un autre fournisseur d'accès. Mais elle plante aussi... J'aurai aimé que lorsque cette connexion plante, que le serveur utilise une gateway secondaire, une route "failover". Déjà, il faut que le temps de bascule entre route soit plus rapide que les 60s par défaut : net.ipv4.route.gc_timeout = 10 Si j'ajoute une 2ème gateway, régulièrement on passe par celle-ci sans explication, ce qui est pénible. Je ne suis pas le seul à chercher ce type de solution, et les solutions _qui marchent_ relèvent de la bidouille : http://www.muug.mb.ca/pipermail/roundtable/2005-May/000881.html Vos solutions ? -- Greg _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/ -- Ludovic Cartier _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/

si tes box font déjà du NAT, met le Bsd un routage simple ( un réseau 172.16.x.x pour ton réseau et un 192.168.1.xx pour tes boxs ) pour ne pas a avoir a faire du double NAT bye

Bonjour, brièvement, voici ma problématique : je dispose de 3 connexions ADSL "pro" pour répartir la bande-passante entre services / collaborateurs. Ce n'est pas forcément la meilleure façon de faire, mais ce n'est pas le sujet. Je ne vous surprendrai pas en vous affirmant que ces box plantent régulièrement. Quelques serveurs Linux utilisent une de ces 3 connexions, la plus fiable, via un autre fournisseur d'accès. Mais elle plante aussi... J'aurai aimé que lorsque cette connexion plante, que le serveur utilise une gateway secondaire, une route "failover". Déjà, il faut que le temps de bascule entre route soit plus rapide que les 60s par défaut : net.ipv4.route.gc_timeout = 10 Si j'ajoute une 2ème gateway, régulièrement on passe par celle-ci sans explication, ce qui est pénible. Je ne suis pas le seul à chercher ce type de solution, et les solutions _qui marchent_ relèvent de la bidouille : http://www.muug.mb.ca/pipermail/roundtable/2005-May/000881.html Vos solutions ? -- Greg _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/

Bonjour, Vu qu'il y a des gens qui proposent des choses à base de pings et de scripts, je me permet de proposer NEMO. Au moins c'est adapté ! ;) Cordialement. Emmanuel Thierry Le 9 mai 2012 à 14:13, Gregory Duchatelet a écrit : _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/

Un simple script qui joue avec la route par défaut devrait faire l'affaire non ? En gros il faut tester que les interfaces sont OK : $ ping -I eth0 googe.fr Et ensuite on change juste la route par défaut (eth0 -> eth1) : $ route del default gw 192.168.1.1 dev eth0 $ route add default gw 192.168.1.1 dev eth0 Et on configure la machine pour faire routeur (activer le forward dans /sys/net/ipv4/ip_forward) et paramétrer iptables au besoin. Niveau adressage, on a 2 réseaux internes : * parc informatique -> machine routeur (10.0.0.0/8 ?) * machine routeur -> box (un classique 192.168.1.0/24 par exemple) Niveau matériel, il faut juste une machine physique avec 1 port rj45 vers le parc informatique (vers switch, routeur, ...) et autant d'autres ports que de box. C'est cheap, mais ça devrait faire l'affaire.

Un simple script qui joue avec la route par défaut devrait faire l'affaire non ? En gros il faut tester que les interfaces sont OK : $ ping -I eth0 googe.fr

C'est cheap, mais ça devrait faire l'affaire.

Dans l'idéal, j'aimerai une solution sans ajout de router/fw/box/server ... Je trouve incroyable que ce soit si compliqué d'avoir une gateway de secours sur un serveur Linux.

La même problématique se pose dans un tout autre contexte : imaginons un site web à fort trafic, dont la répartition de charge se fait via le DNS sur 2 sites, chaque site ayant son propre load-balancer configuré en DirectRouting et pouvant envoyer les requêtes sur l'autre site, cet autre site routant les paquets sortants via sa gateway. En cas de plantage partielle du réseau du site en question, j'aimerai que les paquets puissent sortir par l'autre site, tout simplement en changeant la route par défaut ...

Votre solution avec 2 routeurs, un peu plus balèzes que des RouterBOARD, reste tout à fait valable !

Dans l'idéal, j'aimerai une solution sans ajout de router/fw/box/server ... Je trouve incroyable que ce soit si compliqué d'avoir une gateway de secours sur un serveur Linux.

2/ Si une des passerelles disparait, la route par défaut associée disparaît aussi

C'est rudimentaire : - au niveau de la validation du bon fonctionnement d'un FAI ( on ne valide que la présence du next hop ) mais vu la simplicité de la mise en place ça vaut le coup d'essayer.

Un truc me vient à l'esprit : normalement, un routeur avec une interface externe down, il doit renvoyer un 'unreachable' ICMP si on ping l'extérieur. Pourquoi ne pas utiliser ça pour générer un événement qui modifie la route. Je ne connais pas de soft qui fasse ça mais ça me paraît plutôt trivial. Un ping en continu, si unreachable du routeur, je change la route par défaut. Rien de bien méchant. Sans compter que ICMP, au départ, c'est quand même fait pour ça. J'ai faux sur un truc ?

Un truc me vient à l'esprit : normalement, un routeur avec une interface externe down, il doit renvoyer un 'unreachable' ICMP si on ping l'extérieur. Pourquoi ne pas utiliser ça pour générer un événement qui modifie la route. Je ne connais pas de soft qui fasse ça mais ça me paraît plutôt trivial. Un ping en continu, si unreachable du routeur, je change la route par défaut. Rien de bien méchant. Sans compter que ICMP, au départ, c'est quand même fait pour ça.

J'ai faux sur un truc ? Julien _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/

http://mpath-tools.optilian.org/ Le même principe que les scripts mais en version bundlée et avec pas mal d'options

Jean-Marc. -----Message d'origine----- De : frsag-bounces(a)frsag.org [mailto:frsag-bounces@frsag.org] De la part de Gregory Duchatelet Envoyé : mercredi 9 mai 2012 16:20 À : frsag(a)frsag.org Objet : Re: [FRsAG] Route failover ? Le 09/05/2012 15:32, Jérémie Marguerie a écrit : ... C'est le soucis : c'est cheap. Y'a rien de plus robuste ? Jouer avec les metric par exemple ?

Tu serais étonné de voir que bon nombre de scripts sysadm se font de plus en plus en PHP. Je sais très bien que chaque langage a ses propres avantages mais je remarque que du PHP pour du sysadm combiné à php hiphop pour le transformer en C ça devient à la mode pour les scripts sensibles des infras. Certes les rubyneux, pythonneux et les perleux ne se laissent pas faire mais la facilité de faire des scripts et les convertir en C donne un sacré avantage pour les scripts qui doivent se manger des charges importantes.

Non bien sur du C bien écrit ça reste meilleur mais c'est beaucoup plus long à concevoir que du PHP.

On peut pondre du C rapidement mais faire une excellente qualité sans leak de mémoire du premier coup c'est rare, ces dev qui en sont capables travaillent plutôt en pur dev en C et ne font pas ou alors à de très rares exceptions du sysadm. En PHP/Perl/Python ca va quand même beaucoup plus vite pour scripter.

Il y a également un portage de BSD CARP sous linux http://www.pureftpd.org/project/ucarp a voir s'il est encore maintenu. Entre du monitoring de SLM, du Smokeping (ou autre) externe (pouquoi pas un par fai ?) sur les IP publiques, l'ajout d'un équipement niveau 2 transparent qui va permettre de mesurer la qualité des liens (ping, jitter, fps, ...) en amont des box, du ntop, (...), toute solution qui marche raisonnablement est bonne. Tout dépendra à mon avis de l'exploitabilité de la solution.

Une remarque sur le round robin dns je ne pense pas que ce soit adéquate dans ce cas. Un proxy DNS GLB qui ne modifie que les entrée A/AAAA en fonction d'un SLM par fournisseurs d'accès me semble plus pertinant car elle tient compte de la disponibilité de l'IP contrairement au RR. Je suis cependant d'accord avec le fait que ces fonctions relèvent d'un protocole de routage fait pour (comme l'OSPF, l'HSRP/VRRP, ...) mais c'est plus cher ...

Ce qui rend les choses compliques, ce'st l'utilisation des "box" (que tue peux pas trop controler) en tant que gateway Internet, avec une situation encore pire si ce sont les box qui font le NAT.

Zeroshell le fait assez bien aussi.

Le Mon, May 21, 2012 at 10:35:03PM +0200, Jérôme Benoit a écrit: J'en conviens, mais ça répond assez bien à la question de base de l'OP: comment répartir de multiples connexions avec failover de la façon la plus simple et/ou la moins crade possible. Le petit shuttle avec plusieurs cartes réseaux et un zeroshell (backupé) dessus, ça répond très bien au cahier des charges. Arnaud. _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/