Salut,

pourquoi pas un truc genre pfsense? ca marche pas trop mal

http://www.pfsense.org/

Cdt

Ludovic Cartier mailto:cartier.ludovic@gmail.com mercredi 9 mai 2012 14:23 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 ;-)

-- Ludovic Cartier _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/ Gregory Duchatelet mailto:greg-frsag@duchatelet.net mercredi 9 mai 2012 14:13 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 ?

Bonjour,

Le 09/05/2012 14:39, Hugues Max a écrit :

un petit script shell a base de ping de la passerelle du FAI toutes les minutes

http://www.openbsd.org/cgi-bin/man.cgi?query=ifstated&sektion=8 peut aider pour la gestion des événements.

Denis

jamais testé mais ça la l'air de fait la même chose en mieux...

Pour info je vérifiais aussi le DNS du FAI , c'est souvent lui qui est en panne plutôt que la connexion

Le 09/05/2012 14:50, Denis F. a écrit :

Bonjour,

Le 09/05/2012 14:39, Hugues Max a écrit :

...

un petit script shell a base de ping de la passerelle du FAI toutes les minutes

http://www.openbsd.org/cgi-bin/man.cgi?query=ifstated&sektion=8 peut aider pour la gestion des événements.

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

bonjour à tous,

Ça fait un bail que je suis la liste en spectateur, je me permet une légère remarque sur pfsense:

Ça marche plutôt pas mal du tout, mais il y a une grosse limitation pour du failover si on veut faire du pppoe sur toutes les interfaces: il faut que les gateway diffèrent entre elles pour que pfsense gère ça comme il faut.

c'est ce que j'ai ici comme problème pour 2 lignes: résultat, j'ai une interface en pppoe direct et l'autre avec un NAT 1:1 pour contourner cette limitation. chez moi c'est pas gênant, mais ça peut être ennuyeux dans certaines configurations.

Le 09/05/2012 12:26, Gary a écrit :

Salut,

pourquoi pas un truc genre pfsense? ca marche pas trop mal

http://www.pfsense.org/

Cdt

...

Ludovic Cartier mailto:cartier.ludovic@gmail.com mercredi 9 mai 2012 14:23 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 ;-)

-- Ludovic Cartier _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/ Gregory Duchatelet mailto:greg-frsag@duchatelet.net mercredi 9 mai 2012 14:13 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 ?

---

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

Le 9 mai 2012 15:18, Gregory Duchatelet greg-frsag@duchatelet.net a écrit :

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.

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.

Salut,

On Wed, May 09, 2012 at 04:20:20PM +0200, Gregory Duchatelet wrote:

C'est le soucis : c'est cheap. Y'a rien de plus robuste ? Jouer avec les metric par exemple ?

Si, n'importe quel protocole de routage dynamique fait pour ça, comme OSPF, mais ça va de pair avec des connexions non cheap.

Connexion cheap => failover cheap.

Solution de contournement: monter des tunnels sur les connex cheap et faire de l'OSPF par dessus.

Sylvain

Le Wed May 9 16:27:05 2012, Jean-Marc Jacquot a écrit :

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@frsag.org [mailto:frsag-bounces@frsag.org] De la part de Gregory Duchatelet Envoyé : mercredi 9 mai 2012 16:20 À : frsag@frsag.org Objet : Re: [FRsAG] Route failover ?

Le 09/05/2012 15:32, Jérémie Marguerie a écrit :

...

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.

C'est le soucis : c'est cheap. Y'a rien de plus robuste ? Jouer avec les metric par exemple ?

Il y a tres longtemps (avant l'an 2000 c'est pour dire) j'avais fait qqchose du genre avec de l'iptables pour faire du fwmark et de l'iproute2 pour avoir plusieurs gateways. avec fwmark je marquais les paquets et avec iproute2 je les envoyais vers la bonne gateway en fonction du marking en couplant cela avec des tests de ping/dns/whatever tu peux faire de la redondance et de la selectivité de lien.

Mais pour redire le deja-dit, avec un budget proche du neant, les solutions sont forcement dans le meme ensemble :D

Bonjour,

Le 10/05/2012 07:41, Julien Escario a écrit :

Parce qu'on aime pas que les machines 'clientes' se mèlent de routage. Le routage, ce sont les routeurs qui gèrent.

Là, tu es dans un cas où les routeurs font mal le boulot.

Perso, je mettrais deux routerboard (65 € par bestiole pour 30/50 Mbps), du VRRP/Carp entre les deux et je bidouillerais mes règles de routage dessus.

Mais comme tu l'as dit, ca rajoute du matos devant tes routeurs, pas ce que tu veux (et pourtant la meilleure façon de faire).

Merci pour l'explication, j'approuve ;) Mais je crois que je vais tester mpath-tools d'abord.

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 !

Le 10/05/2012 09:13, Julien Escario a écrit :

Petit soucis là : le client demande au serveur ayant l'ip a.a.a.a la page web mais reçoit une réponse de b.b.b.b. Pas de session TCP, pas de page. (ou alors je n'ai pas compris l'infra).

Effectivement, je parle d'une infra qui est en prod depuis plus d'un an.

L'ip a.a.a.a arrive sur le LB du site T, qui DirectRoute le paquet sur le site Y, dont le serveur répond avec l'IP a.a.a.a via la gateway de son site b.b.b.1

Il suffit de 2 conditions : - que l'ip a.a.a.a soit en loopback sur le serveur qui réponds http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.LVS-DR.html - que la gateway soit autorisée à router le réseau a.a.a.a/nn

Le 09/05/2012 15:32, Jérémie Marguerie a écrit :

...

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.

C'est le soucis : c'est cheap. Y'a rien de plus robuste ? Jouer avec les metric par exemple ?

c'est ce qui parait le plus simple : Deux passerelles par défaut avec des métriques différentes :

1/ si les passerelles sont disponibles c'est celle qui a la métrique la plus basse qui est utilisée # route add default gw ip_gw1 metric 1 # route add default gw ip_gw2 metric 2 .. # route -n (pour afficher les routes avec leur métrique associée)

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. - il n'y a pas de répartition de charge sur les liens, mais cela peut se faire en rajoutant des routes, toujours en jouant sur les métriques

++

David

-- Greg

---

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

Le 10/05/2012 14:23, Radu-Adrian Feurdean a écrit :

...

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.

Meme pas. Meme le first-hop, il faut detecter qu'il est down. Et si on est la, pourquoi pas valider quelque-chose de plus loin.

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

On Thu, 10 May 2012 14:44:42 +0200, "Julien Escario" escario@azylog.net said:

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 ?

Sur le fait que ca n'existe pas "par default" et qu'il faut le faire/ecrire ?

Apres, ca a ete deja dit, faut laisser la partie routage aux routeurs (que ca soit du firewall, machine Linux/*BSD dedie ou routeur proprement dit), et pas commencer a mettre ca sur chaque machine dans le reseau.

Le 09/05/12 15:18, Gregory Duchatelet a écrit :

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.

Peut importe l'OS tu ne peux avoir qu'une seule default gateway sinon dans la logique des choses (les routeurs le font très bien mais les OS moins) si tu as 2 gateway cela doit envoyer 1 paquets sur 2 à chaque gw.

C'est grace à cette astuce qu'à l'époque des LS qui valaient super cher, on montait pour les clients des doubles LS avec 2 HSRP. Chaque HSRP était master sur une LS et backupé sur l'autre. Sur les switchs client et côté hébergement on faisait du dual default gateway pour équilibrer à 50/50 les liens ca marchait super bien.

Par contre quand tu veux faire pareil entre différents opérateurs tu n'as pas le même réseau en face. Ajouter une notion de métrique ne changerait rien à l'affaire.

Personnellement je met en place pas mal de pfsense pour cet usage là pour les clients qui souhaitent avoir X liaisons internet et attribuer un usage spécifique à chacun. Il suffit de créer des groupe de gateway où l'on indique la priorité des liens (identiques ou ordonnés) et dans les règles du firewall on dit que tel subnet source ou telle ip d'un serveur passe par telle groupe de gateway. Comme vu dans un précédent mail cela ne marche pas avec des liaisons d'un même FAI car on se retrouve dans l'exemple d'équilibrage des LS mis plus haut sauf que du côté du FAI il n'y a pas d'équilibrage et les ip ne sont pas dans le même subnet (/32).

A l'époque des dedibox pro avec deux interfaces et deux ip, j'avais mis en place un iptables pour traquer les paquets afin de correctement les distribuer et les faire resortir par la même interface et donc la même ip pub. Ca marchait bien mais il aucune gestion de panne, il aurait fallu scripter la détection de la perte d'un lien ou une latence élevée pour basculer les règles vers le lien restant.

Bref tu n'es pas le premier à te poser la question, pour info sur certaines archis genre as400 j'ai déjà vu un client planter son serveur (avec des conséquences bien plus lourdes que sur un linux/win) en ajoutant juste 2 routes par défaut.

Autre point sur un petit firewall en amont de tes liens ca me semble pas insurmontable ni financièrement ni techniquement et c'est pourtant un atout dans un réseau d'entreprise (firewall de base c'est mieux que pas de firewall, possibilité de gate vpn, vpn avec prestataires, log légaux d'activités, ...) Si tu as des questions tu sais me joindre :)

Le 11/05/2012 10:37, Gregory Duchatelet a écrit :

Bonjour,

Le 09/05/2012 16:27, Jean-Marc Jacquot a écrit :

...

http://mpath-tools.optilian.org/

Le même principe que les scripts mais en version bundlée et avec pas mal d'options

Quelle horreur, c'est en PHP ! Bon, je crois que je vais devoir faire le miens avec toutes les bonnes idées recensées ici ;)

Greg

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.

Le 11/05/2012 11:33, Guillaume Friloux a écrit :

Du PHP traduit en C, qui serait aussi performant que si c etait ecrit en C directement ?

Non bien sur du C bien écrit ça reste meilleur mais c'est beaucoup plus long à concevoir que du PHP. Et puis les sysadm qui codent bien en C et qui ont du temps c'est rare.

Là clairement l'avantage c'est de gagner du temps en scriptant en php et gagner pas mal de performance en le mettant en C.

Le 11/05/2012 14:32, Benoit Garcia a écrit :

Bonjour,

2012/5/11 Pierre-Henry <wallace@morkitu.org mailto:wallace@morkitu.org>

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

Ha bon?

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.

Et puis les sysadm qui codent bien en C et qui ont du temps c'est
rare.

Les sysadmin qui ont du temps sont rares, ça je suis d'accord :-)

Là clairement l'avantage c'est de gagner du temps en scriptant en
php et
gagner pas mal de performance en le mettant en C.

Et quelle est la pertinance de ce choix? Pourquoi ne pas utiliser un langage plus courant pour des tâches d'admin comme perl ou python?

J'ai vu ces usages lorsque le script en question est soumis à un flux d'informations énorme à traiter en un temps record ou alors sur du long terme en continu en tâche de fond. J'ai vu aussi des plugins à des proxy dans ce style. Clairement je suis conscient qu'en C pur ca marche mieux j'ai déjà fait mais les clients ne payent pas toujours ce temps mais veulent la performance donc un juste milieu est à trouver. Pour info je n'ai pas lancé la mode, j'ai vu cela et je devais intervenir pour faire rapidement des modifs dessus, l'ancien sysadm m'a expliqué la raison du choix, 2 jours pour faire un daemon de traitement d'informations à raison de 2M lignes / min Les tests en PHP pur montraient une saturation, une fois compilé ça passe sans soucis et on a pu valider presque 4M lignes / min avec ce daemon comme quoi. Ils avaient déjà tenté en Perl avant le sysadmin qui l'a fait en php et ça tenait pas non plus.

Clairement ce n'est pas l'idéal mais c'est une solution à connaître.

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

Le 13 mai 2012 12:18, Xavier Beaudouin kiwi@oav.net a écrit :

Hello,

(...)

...

...

2012/5/11 Pierre-Henry wallace@morkitu.org Non bien sur du C bien écrit ça reste meilleur mais c'est beaucoup plus long à concevoir que du PHP. Ha bon?

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.

Autrement sur OpenBSD y a relayd qui peux servir à ce genre de choses ... (entre autres... bien évidement).

Xavier

---

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

Le 13 mai 2012 13:37, Xavier Beaudouin kiwi@oav.net a écrit :

Hello, Le 13 mai 2012 à 12:46, J. Mardas a écrit :

...

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.

Le problème de ucarp (qui existe si mes souvenirs sont bons) c'est qu'il utilise l'interface aliase pour monter l'ip virtuelle. Par contre il garde le proto CARP pour communiquer. Cette façon de fonctionner a un "soucis" celui de faire un gratuitous ARP broadcast pour mettre a jour la MAC de la nouvelle gateway (alors que sur les *BSD la mac est unique sur toutes les machines... pratique pour les OS autistes qui ignorent les gratuitous ARP).

C'est toujours le cas. De plus CARP sous Open s'exécute dans l'espace system, ucarp est dans l'espace utilisateur. L'idée était surtout de rappeler l’existence du portage de CARP sous linux.

...

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

OSPF : Quagga, Bird et OpenOSPF (*BSD) existent pour ce genre de chose.... C'est gratis. Perso sur du BSD je conseille OpenOSPF ou Bird. Linux : bird ou quagga. Même prix. HSRP / VRRP : OpenVRRP existe sous Linux, CARP sous les BSD ou Linux...

100% d'accord

Donc le "c'est plus cher" n'est pas totalement vrai. Le "plus cher" c'est qu'il faut jouer avec des protos de routage, ce qui n'est des fois pas facile a gérer.

C'est exactement ce que je voulais dire, en ajoutant à cela le coût d'un nouvel équipement (qui semble préférable dans ce cas) et vu la complexité d'admin ça "tourne" rapidement à l'appliance en lieu et place de solution custo.

Autrement en terme de route failover, il y a JunOS qui fait bien les choses car il est capable de monter une route statique s'il arrive a joindre le next-hop. Et même avec des séries J on est capable de bien faire les choses ... :)

Bon ça coute un peu... sauf en broke (j'ai un J2300 qui trainne en passant)...

Autrement dans série broke : ServerIron XL (Type SLB 8 / 16 / 24) qui fait aussi ce genre de route failover. Si jamais ca vous tente j'en ai deux aussi :)

C'est ce que j'appelle la solution du riche (HSRP compris :)

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

Le Wed, May 16, 2012 at 10:02:26PM +0200, Jérôme Benoit a écrit:

...

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.

iproute2 fait çà très bien. Et si tu veux pas te taper les configs à la main, shorewall est un frontend sympathique pour faire des configs multi-WAN.

Zeroshell le fait assez bien aussi.

Arnaud.

Le Mon, May 21, 2012 at 10:35:03PM +0200, Jérôme Benoit a écrit:

...

Zeroshell le fait assez bien aussi.

C'est une distro, pas un logiciel seul qui fait frontend inclue dans toutes les distros.

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.

Bonjour,

j'en ai codé un aussi de mon coté. En gros il ajoute une route vers l'IP de test via la gateway à tester, et si besoin redémarre la box via contrôle de son alimentation à l'aide d'un PDU manageable.

https://github.com/gregorg/greg-scripts/blob/master/bin/net_dsl_failover.sh

Greg

Le 13/06/2012 21:52, Fabien Bourdaire a écrit :

On a codé un petit script en perl pour cet usage:

http://updates.ecsc.co.uk/firehat-2.4/repoview/sourcerouter.html

Enjoy

Fabien.

2012/5/22 Arnaud Launay <asl@launay.org mailto:asl@launay.org>

Le Mon, May 21, 2012 at 10:35:03PM +0200, Jérôme Benoit a écrit:
> > Zeroshell le fait assez bien aussi.
> C'est une distro, pas un logiciel seul qui fait frontend inclue
> dans toutes les distros.

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/

---

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