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
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 <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<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
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 à 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
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/
-- Christophe Le Clerc
Salut j'ai fait la même chose avec 2 fournisseurs d'accès ADSL Orange et Bouygtel sous OpenBsd , un pc avec 3 interfaces un petit script shell a base de ping de la passerelle du FAI toutes les minutes, et 3 versions du fichier pf.conf et un update des routes Une version quand tout marche avec du partage de charge simple ( web d'un coté, mail etc.. de l'autre ) Une version quand Orange en panne Une version quand Bouygtel en panne 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 Hugues Le 09/05/2012 14:23, Ludovic Cartier a écrit :
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 <greg-frsag@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/
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/
Si tant est que les dites box puissent accepter du routage statique pour accéder à d'autres réseaux que celui par défaut. Et la, c'est pas gagné :( ... Très souvent , le NAT s'impose. Hugues Max a écrit :
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, 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 :
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/
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. Le 09/05/2012 15:05, Emmanuel Thierry a écrit :
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 :
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/
Liste de diffusion du FRsAG http://www.frsag.org/
-- Greg
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. -- Jérémie MARGUERIE Étudiant à l'EPITA, ing2 SRS, root@yaka.epita.fr
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 ? -- Greg
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
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 ? -- Greg _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
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 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
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 ?
-- Greg
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.
On 11/05/2012 11:13, Pierre-Henry wrote:
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.
Du PHP traduit en C, qui serait aussi performant que si c etait ecrit en C directement ?
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.
Bonjour, 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? 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? -- Cdlt, Benoit
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.
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
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/
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).
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... 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. 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 :) Xavier
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 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/
On Thu, 10 May 2012 13:49:13 +0200, "David Amiel" <david@lesamiel.fr> said:
2/ Si une des passerelles disparait, la route par défaut associée disparaît aussi
Nope. Si la passerelle disparait, comme ton eth vers la passerelle reste up, la route reste aussi en place. Ca marche uniquement si tu est directement connecte vers cete passerelle avec un cable croise, et qeu une fois la passerelle down, ta machine voit un "link down".
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.
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
Salut Julien, On Thu, May 10, 2012 at 02:44:42PM +0200, Julien Escario wrote:
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 ?
C'est techniquement juste, mais les grozopérateurs désactivent l'émission des ICMP host unreachable. Sylvain
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.
Bonsoir, Le 10 mai 2012 14:44, Julien Escario <escario@azylog.net> a écrit :
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.
C'est un peu ce que fait mpath-tools proposé hier non ? http://mpath-tools.optilian.org/ Greg
J'ai faux sur un truc ?
Julien _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-- Greg
Le 09/05/2012 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.
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). Bonne journée, Julien
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 ! -- Greg
Le 10/05/2012 08:46, Gregory Duchatelet a écrit :
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 ...
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). Il faudrait que les deux sites aient la même adresse IP et là, on parle de load balancing un peu plus 'cossu' que du DNS round robin. Sans compter les problèmes de session PHP. On mélange un peu les sites : site web, site physique. Un seul site web, sur deux serveurs répartis géographiquement ? Là, pas de miracle, il faut du lourd avec unicast et éventuellement cache frontal (ca aide bien à la répartition). Sinon de la virtualisation au niveau hardware avec failover automatique et filer synchros. C'est tout de suite plus complexe (et cher).
Votre solution avec 2 routeurs, un peu plus balèzes que des RouterBOARD, reste tout à fait valable !
Mikrotik va lancer un routeur plutôt costaud : http://cloudcorerouter.com/ Ce n'est pas fait. Les bugs à la sortie devraient être limités puisque toujours basé sur le même soft qui a fait ces preuves. En attendant, on peut router pas mal de pps avec du xeon quad/hexa core. Mais tu obtiendrais certainement pas mal de réponses beaucoup plus pointues que les miennes sur frnog. Julien
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 -- Greg
On Wed, 09 May 2012 15:18:02 +0200, "Gregory Duchatelet" <greg-frsag@duchatelet.net> said:
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.
Ce n'est pas problematique d'avoir un gateway de secours, ce qui est problematique c'est detecter que le gateway en question ne peut plus remplir son role. La route saute toute seule uniquement si l'interface vers le gateway tombe. Malhereusement ce n'est souvent pas le cas. L'interface vers le GW (BOX) reste up, et c'est l'interface externe du box qui tombe. Dans certains situations (routeur-switch-"box"/gw) l'interface sur le routeurs reste up meme quand le gw/box est enleve du reseau. 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. Pour info, a l'epoque ou j'etais dans un environnement plus "petit", j'avais fait de la "redondance de lien Internet" de deux facon: - au tout debut, machine Linux avec scripts qui faisait le check de deux liens (le NAT aussi). Pas terrible. - apres, quand on a commence a utiliser les boitiers Fortinet (meme les petits modeles), la fonction "gwdetect" marchait pas mal non plus. Moins de travail, mais moins de flexibilite aussi. - aujourd'hui, je suis mon propre ISP. Le techno a change assez violamment, la redondance se gere de facon differente et je peux faire des choses pas envisageables avant. Tu peux prendre plus ou moins le meme niveau de service chez un operateur, mais faut avoir les moyens *et le BESOIN* (l'utilisation Internet de ~500 personnes ne se voit plus sur les graphs quand un back-up demarre).
On Thu, 10 May 2012 12:12:51 +0200 "Radu-Adrian Feurdean" <frsag@radu-adrian.feurdean.net> wrote:
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. -- Jérôme Benoit aka fraggle La Météo du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D
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.
On Thu, 17 May 2012 19:34:06 +0200 Arnaud Launay <asl@launay.org> wrote:
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.
C'est une distro, pas un logiciel seul qui fait frontend inclue dans toutes les distros. a +. -- Jérôme Benoit aka fraggle La Météo du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D
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.
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>
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/
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/
-- Greg
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 :)
participants (25)
-
Arnaud Launay -
Benoit Garcia -
Christophe -
Christophe Le Clerc -
David Amiel -
Denis F. -
Emmanuel Thierry -
Fabien Bourdaire -
Gary -
Greg -
Gregory Duchatelet
-
Guillaume Friloux -
Hugues Max -
J. Mardas -
Jean-Marc Jacquot -
Julien Escario -
Jérémie Marguerie -
Jérôme Benoit -
Ludovic Cartier -
Pierre-Henry -
Radu-Adrian Feurdean -
Sylvain Rochet -
Sébastien FOUTREL -
Wallace
-
Xavier Beaudouin