Re: [FRsAG] Route failover ?

2012-06-15 Par sujet Gregory Duchatelet

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 a...@launay.org mailto:a...@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

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


Re: [FRsAG] Route failover ?

2012-06-13 Par sujet Fabien Bourdaire
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 a...@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/


Re: [FRsAG] Route failover ?

2012-05-22 Par sujet Arnaud Launay
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/


Re: [FRsAG] Route failover ?

2012-05-21 Par sujet Jérôme Benoit
On Thu, 17 May 2012 19:34:06 +0200
Arnaud Launay a...@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


signature.asc
Description: PGP signature
___
Liste de diffusion du FRsAG
http://www.frsag.org/


Re: [FRsAG] Route failover ?

2012-05-17 Par sujet Arnaud Launay
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.
___
Liste de diffusion du FRsAG
http://www.frsag.org/


Re: [FRsAG] Route failover ?

2012-05-16 Par sujet Jérôme Benoit
On Thu, 10 May 2012 12:12:51 +0200
Radu-Adrian Feurdean fr...@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


signature.asc
Description: PGP signature
___
Liste de diffusion du FRsAG
http://www.frsag.org/


Re: [FRsAG] Route failover ?

2012-05-13 Par sujet Xavier Beaudouin
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/ 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
___
Liste de diffusion du FRsAG
http://www.frsag.org/



Re: [FRsAG] Route failover ?

2012-05-13 Par sujet J. Mardas
Le 13 mai 2012 13:37, Xavier Beaudouin k...@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/ 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/

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


Re: [FRsAG] Route failover ?

2012-05-11 Par sujet Gregory Duchatelet

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-boun...@frsag.org [mailto:frsag-boun...@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/


Re: [FRsAG] Route failover ?

2012-05-11 Par sujet Pierre-Henry


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.




signature.asc
Description: OpenPGP digital signature
___
Liste de diffusion du FRsAG
http://www.frsag.org/


Re: [FRsAG] Route failover ?

2012-05-11 Par sujet Guillaume Friloux

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 ?
attachment: guillaume_friloux.vcf___
Liste de diffusion du FRsAG
http://www.frsag.org/


Re: [FRsAG] Route failover ?

2012-05-11 Par sujet Pierre-Henry


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.



signature.asc
Description: OpenPGP digital signature
___
Liste de diffusion du FRsAG
http://www.frsag.org/


Re: [FRsAG] Route failover ?

2012-05-11 Par sujet Benoit Garcia
Bonjour,

2012/5/11 Pierre-Henry wall...@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
___
Liste de diffusion du FRsAG
http://www.frsag.org/


Re: [FRsAG] Route failover ?

2012-05-10 Par sujet David Amiel
 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/



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


Re: [FRsAG] Route failover ?

2012-05-10 Par sujet Julien Escario
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
___
Liste de diffusion du FRsAG
http://www.frsag.org/


Re: [FRsAG] Route failover ?

2012-05-10 Par sujet Sylvain Rochet
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


signature.asc
Description: Digital signature
___
Liste de diffusion du FRsAG
http://www.frsag.org/


Re: [FRsAG] Route failover ?

2012-05-10 Par sujet Radu-Adrian Feurdean

On Thu, 10 May 2012 14:44:42 +0200, Julien Escario
esca...@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.
___
Liste de diffusion du FRsAG
http://www.frsag.org/


Re: [FRsAG] Route failover ?

2012-05-10 Par sujet Wallace
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 :)



signature.asc
Description: OpenPGP digital signature
___
Liste de diffusion du FRsAG
http://www.frsag.org/


Re: [FRsAG] Route failover ?

2012-05-09 Par sujet Ludovic Cartier
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-fr...@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.htmlhttp://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/


Re: [FRsAG] Route failover ?

2012-05-09 Par sujet Gary
Salut,

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

http://www.pfsense.org/ 
  
Cdt


   	   
   	Ludovic Cartier  
  mercredi 9 mai 
2012 14:23
  Salut,J'ai eu un peu le
 mme problme 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 rseau 4 ports, et une Debian :-)
J'ai configur les 3 interfaces "interne" dans mon 
/etc/network/interfaces directement, mais avec des metric diffrentes 
(ce qui permets d'avoir une prfrence 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 crer des rules IP particulires : dans 
mon cas, je force toutes les IPs du subnet des tlphones SIP a utiliser
 une route de sortie diffrente de tout le reste du rseau.
Mon setup a un inconvnient qui peut tre un gros problme en 
fonction des FAI : pour que a fonctionne parfaitement et surtout ne pas
 avoir  t'emmerder avec des rgles 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 rseau local).Voil, en esprant 
que a t'aide ;-)
-- Ludovic Cartier

___Liste de 
diffusion du FRsAGhttp://www.frsag.org/
   	   
   	Gregory Duchatelet  
  mercredi 9 mai 
2012 14:13
  Bonjour,

brivement, voici ma problmatique : je dispose de 3 connexions ADSL
 
"pro" pour rpartir la bande-passante entre services / collaborateurs.
Ce n'est pas forcment la meilleure faon de faire, mais ce n'est 
pas le 
sujet.

Je ne vous surprendrai pas en vous affirmant que ces box plantent 
rgulirement.

Quelques serveurs Linux utilisent une de ces 3 connexions, la plus 
fiable, via un autre fournisseur d'accs. Mais elle plante aussi... 
J'aurai aim que lorsque cette connexion plante, que le serveur utilise 
une gateway secondaire, une route "failover".

Dj, il faut que le temps de bascule entre route soit plus rapide 
que 
les 60s par dfaut :

net.ipv4.route.gc_timeout = 10


Si j'ajoute une 2me gateway, rgulirement on passe par celle-ci 
sans 
explication, ce qui est pnible.

Je ne suis pas le seul  chercher ce type de solution, et les 
solutions 
_qui marchent_ relvent 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/


Re: [FRsAG] Route failover ?

2012-05-09 Par sujet Hugues Max

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-fr...@duchatelet.net 
mailto:greg-fr...@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/
___
Liste de diffusion du FRsAG
http://www.frsag.org/


Re: [FRsAG] Route failover ?

2012-05-09 Par sujet Christophe
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


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


Re: [FRsAG] Route failover ?

2012-05-09 Par sujet Hugues Max

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=ifstatedsektion=8 peut 
aider pour la gestion des événements.


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

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


Re: [FRsAG] Route failover ?

2012-05-09 Par sujet Emmanuel Thierry
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/


Re: [FRsAG] Route failover ?

2012-05-09 Par sujet Gregory Duchatelet

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

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


Re: [FRsAG] Route failover ?

2012-05-09 Par sujet Sylvain Rochet
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


signature.asc
Description: Digital signature
___
Liste de diffusion du FRsAG
http://www.frsag.org/


Re: [FRsAG] Route failover ?

2012-05-09 Par sujet Jean-Marc Jacquot
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-boun...@frsag.org [mailto:frsag-boun...@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/

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


Re: [FRsAG] Route failover ?

2012-05-09 Par sujet Sébastien FOUTREL

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-boun...@frsag.org [mailto:frsag-boun...@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



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


Re: [FRsAG] Route failover ?

2012-05-09 Par sujet Julien Escario
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
___
Liste de diffusion du FRsAG
http://www.frsag.org/