Bonjour,
J'ai deux connexions Internet sur mon lieu de travail et un serveur Linux qui me sert de routeur. Les modems sont reliés directement à ce routeur.
Tous mes clients ont le routeur Linux comme passerelle.
J'ai fais un mécanisme qui ping toutes les X secondes des IP au hasard sur le net pour détecter les coupures sur un lien ou l'autre et je change les routes au besoin.
Par défaut, les deux connexions sont utilisées (c'est réparti selon les clients).
Si un lien tombe, les clients sont tous basculés vers la connexion toujours debout.
Problème :
- la détection se fait toutes les X secondes
- je suis obligé d'utiliser un mécanisme tel que "ip route add default scope global nexthop via IP_MODEM1 dev "INTERFACE_ETHERNET1" weight 1 nexthop via IP_MODEM2 dev "INTERFACE_ETHERNET2" weight 1"
Il n'est pas possible sur Linux de détecter automatiquement la coupure ??
Mes modems sont en 192.168.100.1 et 192.168.200.1 côté LAN.
L'idée serait que le routeur détecte qu'internet ne fonctionne pas par 192.168.100.1 et bascule plus rapidement sur 192.168.200.1.
Je vous remercie d'avance.
# Bridge et scripts ifup ifdown
Posté par Chris K. . Évalué à 1. Dernière modification le 16 septembre 2014 à 13:09.
Si il est possible de passer les deux modems en mode bridge pour récupérer directement la gestion des liens ppp sur le routeur il serait alors possible d'utiliser les scripts ifup et ifdown pour gérer le routage sur les liens.
Tu peux conserver ton script de ping pour connecter et déconnecter les liens si il y a un problème sur le réseau de ton opérateur mais que le lien ppp est toujours présent.
Dans la plupart des cas le temps de détection de la panne devrait être meilleur et au pire identique à ce que tu as actuellement.
[^] # Re: Bridge et scripts ifup ifdown
Posté par Chris K. . Évalué à 1.
Sinon tu peux également récupérer les pages de statut de connexion des modems avec curl. Cela doit permettre d'avoir des intervalles plus court qu'avec de multiples ping.
[^] # Re: Bridge et scripts ifup ifdown
Posté par kortex . Évalué à 1.
Merci Christophe mais du coup pour la première piste, je ne peux pas passer les modems en bridge pour deux raisons :
- 1/ j'ai deux routeurs (un actif / un de secours). Il faudrait donc que celui de secours soit toujours coupé etc.
- 2/ j'ai une ip dynamique sur une des deux connexions (par choix)
Je pensais plutôt qu'il y avait un truc niveau routage (avec ip route add). J'ai essayé avec "metric" mais ça ne fonctionne pas. Avec "nexthop" non plus :(
Je pensais que les protocoles de routage étaient "intelligents" ? C'est pas un troll mais une vraie question (je suis pas super super bon en réseau).
[^] # Re: Bridge et scripts ifup ifdown
Posté par Chris K. . Évalué à 1. Dernière modification le 17 septembre 2014 à 16:23.
Pour le coup des routeurs ça peut être un peu lourd à gérer effectivement mais il reste possible de mettre les modems en bridge sur un petit switch et d'initier les connexions ppp uniquement sur le routeur en cours de fonctionnement et de créer un script permettant gérer la bascule avec le spare.
A ce moment là tu gère le masquerading directement sur le routeur et l'IP dynamique ne pose pas de problème en utilisant la bonne règle (MASQUERADE).
La détection de lien mort quand la machine gère directement un lien ppp reste, amha, la manière la plus simple de gérer le problème.
Après ce n'est pas a proprement parler ma spécialité non plus : je me limite a du routage statique n'ayant jamais eu le besoin d'avoir quelque chose de plus puissant. Mais nexthop pour moi c'est du icmp redirect type 5 (passerelle sur le même réseau que le demandeur) et metric correspond à la sélection du chemin le plus court dans mes souvenirs. Je ne vois pas trop ce qui peut être fait avec cela pour détecter que la passerelle ne te donne plus accès aux réseaux qui sont derrière elle.
J'ai fait quelques recherches pour ce qui est de la dgd (dead gateway detection) sous linux et cela ne semble pas être une partie de plaisir.
Pour ce qui est du routage dynamique et des protocoles intelligents il s'agit d'avoir un daemon qui va gérer la table de routage en permettant aux routeurs de communiquer entre eux ce qui va poser des problèmes avec des box / modems grand public.
[^] # Re: Bridge et scripts ifup ifdown
Posté par kortex . Évalué à 1.
Ta solution est pas mal (passage en bridge + ppp) mais ne peut pas fonctionner chez nous car j'ai un routeur allumé et un routeur éteint en permanence.
Si quelqu'un démarre le routeur éteint, il se substitue à l'ancien routeur allumé (reconfiguration des switchs etc).
Ceci permet de basculer d'un routeur à l'autre sans reconfigurer les postes clients / sans attendre un bail DHCP / etc.
Conclusion : je crois que je vais devoir en rester à mes scripts maisons :-/
# réseaux maillés
Posté par err404 (site web personnel) . Évalué à 0.
il existe des protocoles de routages qui pourraient te satisfaire avec plus ou moins d'adaptation.
par exemple babel, batman, olsr, ospf
voici les liens:
https://en.wikipedia.org/wiki/Babel_%28protocol%29
https://en.wikipedia.org/wiki/B.A.T.M.A.N.
https://en.wikipedia.org/wiki/Optimized_Link_State_Routing_Protocol
https://en.wikipedia.org/wiki/Open_Shortest_Path_First
# regarder ce que font les projets opensource dans le domaine
Posté par NeoX . Évalué à 3.
par exemple pfsense gere tres bien ce genre de cas,
il peut meme creer des routes pondérées pour certains besoins.
ex avec tes 2 FAIs (FAI1 et FAI2)
tu peux vouloir privilegier FAI1 pour aller sur youtube, et tomber sur FAI2 quand FAI1 est en panne,
mais vouloir passer par FAI2 pour aller ailleurs et tomber sur FAI1 quand FAI2 est en panne.
c'est ce que j'avais choisi avec 1 FO SFR, 1 cable Numericable, 1 livebox ADSL, 1 freebox ADSL.
c'etait terrible, on avait pondéré pour utiliser l'upload de la FO ou du cable pour envoyer de gros volumes vers nos serveurs OVH,
le reste du trafic passait en roundrobin sur les 4 connexions en fonction de l'encombrement (ping et packet loss)
[^] # Re: regarder ce que font les projets opensource dans le domaine
Posté par kortex . Évalué à 1.
pfSense aurait pu être une solution mais on souhaiterait rester sur la distribution actuelle (Gentoo).
Par contre j'ai pas de machine sous la main pour tester pfSense et voir comment il fonctionne en détails.
D'après ce que j'ai lu :
- la répartition des connexions WAN est gérée via le NAT (j'ai préféré jouer avec iproute)
- la détection se fait par un ping (serveur cible configurable)
Donc ça ressemble à ma solution "maison". Sauf qu'au lieu de pinger un seul site je prends 1 site parmi une liste. Si le ping est KO, je prends un autre site pour essayer de "deviner" si c'est la connexion qui est down ou le site en face.
Je trouvais ça un peu trop bricolage à mon goût mais il faut croire qu'il n'y a pas moyen de faire autrement :-/
# Smokeping
Posté par Adminrezo (site web personnel) . Évalué à 1.
Pour tester les connexions réseau, il y a une application pour ça :
Smokeping
Avec ces docs :
- http://doc.ubuntu-fr.org/smokeping
- http://blog.nicolargo.com/2010/04/surveiller-sa-latence-reseau-avec-smokeping.html (ça date)
[^] # Re: Smokeping
Posté par kortex . Évalué à 1.
Merci beaucoup je connaissais pas Smokeping mais je n'ai pas l'impression que ça réponde à mon besoin :(
Je cherchais plutôt un mécanisme au niveau de la couche réseau / noyau / je ne sais quoi qui aurait été assez intelligent pour dire "tiens quand je passe par cette route je n'ai pas de réponse en face alors je vais essayer par telle autre route".
Je dois être trop exigeant car toutes les solutions que je trouve sont proches de la mienne : ping d'un site et si ko alors on switch.
[^] # Re: Smokeping
Posté par err404 (site web personnel) . Évalué à 2. Dernière modification le 17 septembre 2014 à 16:44.
mon précédant commentaire à été moinssé, mais j'insiste
J'utilise Babeld (qui ne s'occupe que du routage), il est capable de choisir une route plutôt qu'une autre en fonction de sa disponibilité, de sa qualité (comme les autres protocoles que j'ai déjà cité)
Bien entendu cela implique d'avoir babel de chaque coté des routes à tester, mais c'est ce que j'utilise chez moi, et ça fonctionne plutôt bien (c'est à dire que quand une route n'est plus disponible parce que le routeur est indisponible, babel choisira l'autre route, et lorsque le premier routeur est de nouveau disponible, babel y reviendra automatiquement dès lors que le coût diffère assez)
j'ai indiqué un coût de base de 128 pour la route que je considère prioritaire, et un coût de base de 1280 pour la route à n'utiliser qu'en second lieu.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.