J'ai un intranet consitué de trois sous-réseaux reliés par une passerelle
sous linux 192.168.40.1 avec forcément trois cartes réseaux.
Mes clients sont des windows dont la passerelle est configurée à
192.168.40.1
Quelles solutions intelligentes existent pour me permettre de fabriquer une
sorte de passerelle de secours, en cas de crash de ma passerelle principale
?
Cela implique-t-il du routage dynamique ? (Des docs ? RTFM ?)
Est-il possible de mettre en place une solution sans toucher la config de
chaque poste client ?
D'indiquer sur les postes client une "passerelle" secondaire. Celle ci sera donc ta seconde carte Ethernet de ton routeur.
Attention, c'est une tolérance de panne et le client basculera sur la seconde adresse uniquement si la première ne répond pas. Si la "passerelle" principale répond en indiquant quelle ne connaît pas le chemin de destination alors ton client ne basculera pas sur la seconde adresse.
Comment ça marche ? Comment le poste client se rend-il compte que la passerelle principale est HS ?
D'indiquer sur les postes client une "passerelle" secondaire. Celle ci sera
donc ta seconde carte Ethernet de ton routeur.
Attention, c'est une tolérance de panne et le client basculera sur la
seconde adresse uniquement si la première ne répond pas. Si la "passerelle"
principale répond en indiquant quelle ne connaît pas le chemin de
destination alors ton client ne basculera pas sur la seconde adresse.
Comment ça marche ? Comment le poste client se rend-il compte que la
passerelle principale est HS ?
D'indiquer sur les postes client une "passerelle" secondaire. Celle ci sera donc ta seconde carte Ethernet de ton routeur.
Attention, c'est une tolérance de panne et le client basculera sur la seconde adresse uniquement si la première ne répond pas. Si la "passerelle" principale répond en indiquant quelle ne connaît pas le chemin de destination alors ton client ne basculera pas sur la seconde adresse.
Comment ça marche ? Comment le poste client se rend-il compte que la passerelle principale est HS ?
Nicolas Ecarnot
"Fontaine.Sebastien" wrote in news:3f38eb0b$0$240$:
J'ai un intranet consitué de trois sous-réseaux reliés par une passerelle
Tu veux dire routeur ?
Oui, je veux dire routeur. J'utilise ici le terme de passerelle car c'est ce terme qu'on trouve dans l'interface de windows, mais on parle bien d'un routeur.
D'indiquer sur les postes client une "passerelle" secondaire. Celle ci sera donc ta seconde carte Ethernet de ton routeur.
Ok, je viens de voir qu'on peut spécifier plusieurs routeurs/passerelles dans la configuration tcp/ip de windows. Par contre, ce que je préfererais faire, c'est monter une routeur secondaire de type logiciel (un petit serveur linux par exemple), de sorte à palier les éventuels crash de mon routeur (logiciel) principal.
Attention, c'est une tolérance de panne et le client basculera sur la seconde adresse uniquement si la première ne répond pas. Si la "passerelle" principale répond en indiquant quelle ne connaît pas le chemin de destination alors ton client ne basculera pas sur la seconde adresse.
Ca me va. C'est exactement le schéma qui me convient.
Oui, tu peux mettre en oeuvre une solution du type vrrp qui te permet d'avoir la même ip sur tes deux cartes et une vérification permanente que la première carte répond bien sinon la seconde répondra alors aux clients sans qu'ils aient besoin d'une seconde passerelle.
Bof, je ne cherche pas à répondre à ce genre de panne (panne de carte eth). Ce que je cherche en terme de doc, c'est de savoir ce qu'il faut mettre en oeuvre, de façon logicielle, pour avoir en permanence ces deux routeurs logiciels qui fonctionnent, mais qui ne se gênent pas. Est-ce très simple ? Ou faut-il utiliser un protocole spécial ? de sorte à ce que les paquets ne transitent pas dans le routeur secondaire tant que tout va bien sur le principal ?
Et si tu veux tolérer ta carte réseau, il y a plus de chance que ce soit ton serveur qui tombe. Dans ce cas, au lieu de mettre multi carte Ethernet dans ton serveur, met plutôt deux serveurs avec vrrp.
Des docs ?
Voilà une réponse en fonction de ta courte question. Si je suis à côté de la plaque, n'hésite pas à détailler ta question afin que l'on puisse te donner satisfaction.
Toujours est-il qu'il semble être nécessaire de modifier la config réseau de tous les postes clients. J'ai l'impression qu'en dehors du DHCP (que je n'utilise pas), il n'y a pas moyen de spécifier aux clients plusieurs passerelles (et encore, c'est à vous de me le confirmer).
-- Nicolas Ecarnot
"Fontaine.Sebastien" <Fontaine.Sebastien@Laposte.Net> wrote in
news:3f38eb0b$0$240$4d4eb98e@read.news.fr.uu.net:
J'ai un intranet consitué de trois sous-réseaux reliés par une
passerelle
Tu veux dire routeur ?
Oui, je veux dire routeur.
J'utilise ici le terme de passerelle car c'est ce terme qu'on trouve dans
l'interface de windows, mais on parle bien d'un routeur.
D'indiquer sur les postes client une "passerelle" secondaire. Celle ci
sera donc ta seconde carte Ethernet de ton routeur.
Ok, je viens de voir qu'on peut spécifier plusieurs routeurs/passerelles
dans la configuration tcp/ip de windows.
Par contre, ce que je préfererais faire, c'est monter une routeur
secondaire de type logiciel (un petit serveur linux par exemple), de sorte
à palier les éventuels crash de mon routeur (logiciel) principal.
Attention, c'est une tolérance de panne et le client basculera sur la
seconde adresse uniquement si la première ne répond pas. Si la
"passerelle" principale répond en indiquant quelle ne connaît pas le
chemin de destination alors ton client ne basculera pas sur la seconde
adresse.
Ca me va. C'est exactement le schéma qui me convient.
Oui, tu peux mettre en oeuvre une solution du type vrrp qui te permet
d'avoir la même ip sur tes deux cartes et une vérification permanente
que la première carte répond bien sinon la seconde répondra alors aux
clients sans qu'ils aient besoin d'une seconde passerelle.
Bof, je ne cherche pas à répondre à ce genre de panne (panne de carte eth).
Ce que je cherche en terme de doc, c'est de savoir ce qu'il faut mettre en
oeuvre, de façon logicielle, pour avoir en permanence ces deux routeurs
logiciels qui fonctionnent, mais qui ne se gênent pas.
Est-ce très simple ?
Ou faut-il utiliser un protocole spécial ? de sorte à ce que les paquets ne
transitent pas dans le routeur secondaire tant que tout va bien sur le
principal ?
Et si tu veux tolérer ta carte réseau, il y a plus de chance que ce
soit ton serveur qui tombe. Dans ce cas, au lieu de mettre multi carte
Ethernet dans ton serveur, met plutôt deux serveurs avec vrrp.
Des docs ?
Voilà une réponse en fonction de ta courte question. Si je suis à côté
de la plaque, n'hésite pas à détailler ta question afin que l'on
puisse te donner satisfaction.
Toujours est-il qu'il semble être nécessaire de modifier la config réseau
de tous les postes clients.
J'ai l'impression qu'en dehors du DHCP (que je n'utilise pas), il n'y a pas
moyen de spécifier aux clients plusieurs passerelles (et encore, c'est à
vous de me le confirmer).
"Fontaine.Sebastien" wrote in news:3f38eb0b$0$240$:
J'ai un intranet consitué de trois sous-réseaux reliés par une passerelle
Tu veux dire routeur ?
Oui, je veux dire routeur. J'utilise ici le terme de passerelle car c'est ce terme qu'on trouve dans l'interface de windows, mais on parle bien d'un routeur.
D'indiquer sur les postes client une "passerelle" secondaire. Celle ci sera donc ta seconde carte Ethernet de ton routeur.
Ok, je viens de voir qu'on peut spécifier plusieurs routeurs/passerelles dans la configuration tcp/ip de windows. Par contre, ce que je préfererais faire, c'est monter une routeur secondaire de type logiciel (un petit serveur linux par exemple), de sorte à palier les éventuels crash de mon routeur (logiciel) principal.
Attention, c'est une tolérance de panne et le client basculera sur la seconde adresse uniquement si la première ne répond pas. Si la "passerelle" principale répond en indiquant quelle ne connaît pas le chemin de destination alors ton client ne basculera pas sur la seconde adresse.
Ca me va. C'est exactement le schéma qui me convient.
Oui, tu peux mettre en oeuvre une solution du type vrrp qui te permet d'avoir la même ip sur tes deux cartes et une vérification permanente que la première carte répond bien sinon la seconde répondra alors aux clients sans qu'ils aient besoin d'une seconde passerelle.
Bof, je ne cherche pas à répondre à ce genre de panne (panne de carte eth). Ce que je cherche en terme de doc, c'est de savoir ce qu'il faut mettre en oeuvre, de façon logicielle, pour avoir en permanence ces deux routeurs logiciels qui fonctionnent, mais qui ne se gênent pas. Est-ce très simple ? Ou faut-il utiliser un protocole spécial ? de sorte à ce que les paquets ne transitent pas dans le routeur secondaire tant que tout va bien sur le principal ?
Et si tu veux tolérer ta carte réseau, il y a plus de chance que ce soit ton serveur qui tombe. Dans ce cas, au lieu de mettre multi carte Ethernet dans ton serveur, met plutôt deux serveurs avec vrrp.
Des docs ?
Voilà une réponse en fonction de ta courte question. Si je suis à côté de la plaque, n'hésite pas à détailler ta question afin que l'on puisse te donner satisfaction.
Toujours est-il qu'il semble être nécessaire de modifier la config réseau de tous les postes clients. J'ai l'impression qu'en dehors du DHCP (que je n'utilise pas), il n'y a pas moyen de spécifier aux clients plusieurs passerelles (et encore, c'est à vous de me le confirmer).
-- Nicolas Ecarnot
Fontaine.Sebastien
Sebastien Fontaine
"Nicolas Ecarnot" a écrit dans le message de news:
"Fontaine.Sebastien" wrote in news:3f38eb0b$0$240$:
Et si tu veux tolérer ta carte réseau, il y a plus de chance que ce soit ton serveur qui tombe. Dans ce cas, au lieu de mettre multi carte Ethernet dans ton serveur, met plutôt deux serveurs avec vrrp.
Voilà une réponse en fonction de ta courte question. Si je suis à côté de la plaque, n'hésite pas à détailler ta question afin que l'on puisse te donner satisfaction.
Toujours est-il qu'il semble être nécessaire de modifier la config réseau de tous les postes clients. J'ai l'impression qu'en dehors du DHCP (que je n'utilise pas), il n'y a pas
moyen de spécifier aux clients plusieurs passerelles (et encore, c'est à vous de me le confirmer).
Si tu peux sans DHCP spécifier toutes les options que tu veux à ton client Win32
-- Nicolas Ecarnot
Sebastien Fontaine
Fontaine.Sebastien@Laposte.Net
"Nicolas Ecarnot" <nicolas.ecarnot@alussinan.org> a écrit dans le message de
news: Xns93D655E353479nicolasusenetecarnot@213.228.0.138...
"Fontaine.Sebastien" <Fontaine.Sebastien@Laposte.Net> wrote in
news:3f38eb0b$0$240$4d4eb98e@read.news.fr.uu.net:
Et si tu veux tolérer ta carte réseau, il y a plus de chance que ce
soit ton serveur qui tombe. Dans ce cas, au lieu de mettre multi carte
Ethernet dans ton serveur, met plutôt deux serveurs avec vrrp.
Voilà une réponse en fonction de ta courte question. Si je suis à côté
de la plaque, n'hésite pas à détailler ta question afin que l'on
puisse te donner satisfaction.
Toujours est-il qu'il semble être nécessaire de modifier la config réseau
de tous les postes clients.
J'ai l'impression qu'en dehors du DHCP (que je n'utilise pas), il n'y a
pas
moyen de spécifier aux clients plusieurs passerelles (et encore, c'est à
vous de me le confirmer).
Si tu peux sans DHCP spécifier toutes les options que tu veux à ton client
Win32
"Nicolas Ecarnot" a écrit dans le message de news:
"Fontaine.Sebastien" wrote in news:3f38eb0b$0$240$:
Et si tu veux tolérer ta carte réseau, il y a plus de chance que ce soit ton serveur qui tombe. Dans ce cas, au lieu de mettre multi carte Ethernet dans ton serveur, met plutôt deux serveurs avec vrrp.
Voilà une réponse en fonction de ta courte question. Si je suis à côté de la plaque, n'hésite pas à détailler ta question afin que l'on puisse te donner satisfaction.
Toujours est-il qu'il semble être nécessaire de modifier la config réseau de tous les postes clients. J'ai l'impression qu'en dehors du DHCP (que je n'utilise pas), il n'y a pas
moyen de spécifier aux clients plusieurs passerelles (et encore, c'est à vous de me le confirmer).
Si tu peux sans DHCP spécifier toutes les options que tu veux à ton client Win32
Et voici en complément comment l'activer dans la registerie
EnableDeadGWDetect Clé : TcpipParameters Type de valeur : REG_DWORD : booléen Plage valide : 0, 1 (faux, vrai) Par défaut : 1 (vrai) Description : quand ce paramètre est à 1, TCP est autorisé à effectuer la détection de passerelles inactives. Quand cette fonction est activée, TCP demande au protocole IP de basculer sur une passerelle de secondaire si certaines connexions connaissent des difficultés.
J'en convient, ça ne vaut pas une solution basé sur du VRRP ou de l'HSRP. C'est plus une solution dédié au TPE.
Sebastien Fontaine
Fontaine.Sebastien@Laposte.Net
"Annie D." <annie.demur@free.fr> a écrit dans le message de news:
3F396E13.383A8E8A@free.fr...
Et voici en complément comment l'activer dans la registerie
EnableDeadGWDetect
Clé : TcpipParameters
Type de valeur : REG_DWORD : booléen
Plage valide : 0, 1 (faux, vrai)
Par défaut : 1 (vrai)
Description : quand ce paramètre est à 1, TCP est autorisé à effectuer la
détection de passerelles inactives. Quand cette fonction est activée, TCP
demande au protocole IP de basculer sur une passerelle de secondaire si
certaines connexions connaissent des difficultés.
J'en convient, ça ne vaut pas une solution basé sur du VRRP ou de l'HSRP.
C'est plus une solution dédié au TPE.
Et voici en complément comment l'activer dans la registerie
EnableDeadGWDetect Clé : TcpipParameters Type de valeur : REG_DWORD : booléen Plage valide : 0, 1 (faux, vrai) Par défaut : 1 (vrai) Description : quand ce paramètre est à 1, TCP est autorisé à effectuer la détection de passerelles inactives. Quand cette fonction est activée, TCP demande au protocole IP de basculer sur une passerelle de secondaire si certaines connexions connaissent des difficultés.
J'en convient, ça ne vaut pas une solution basé sur du VRRP ou de l'HSRP. C'est plus une solution dédié au TPE.
pepete
Julien Salgado wrote:
Bonjour,
Il faut un deuxième routeur... ensuite le plus simple est d'utiliser un protocol su genre VRRP ou HSRP... Mais on sort de la couche ethernet, et on commence à faire de l'IP. Il existe plusieurs implémentations pour linux en particulier keepalived et vrrpd vois sur : http://www.linuxvirtualserver.org/~acassen/
Si on met comme IP de vrrp l'ancienne IP de la gateway, la modification sera presque transparente pour les postes clients (il n'y a que la MAC de la gateway qui change). Ensuite si on veut faire ça sans auncune interruption de service il faut un peu réfléchir.
Question naïve : Imaginons le routeur principal sous linux (comme dans ce post) avec son adresse IP (192.168.0.1) et un routeur secondaire (ou redondant) sous linux aussi avec son adresse IP (192.168.0.2). Il est facile avec linux d'automatiser des actions avec des scripts. Pourquoi ne pas faire tourner un script sur le routeur 2 (qui ne sert à rien en temps normal) qui ping le routeur 1 et en cas de non réponse prend l'ip du routeur 1 (/etc/sysconfig/network-script/ifcfg-ethx) et relance son interface réseau (service network restart) ? Pour limiter le nombre excessif de "pings", on peut imaginer "pinguer" toutes les 5 ou 10 minutes. Il me semble que ce même script pourrait service à tous les services ayant besoin de redondance (dhcp, dns, mail, ...). Dites-moi si mon idée vous paraît complètement farfelue.
Cordialement.
Julien Salgado wrote:
Bonjour,
Il faut un deuxième routeur... ensuite le plus simple est d'utiliser un
protocol su genre VRRP ou HSRP... Mais on sort de la couche ethernet, et
on commence à faire de l'IP. Il existe plusieurs implémentations pour
linux en particulier keepalived et vrrpd vois sur :
http://www.linuxvirtualserver.org/~acassen/
Si on met comme IP de vrrp l'ancienne IP de la gateway, la modification
sera presque transparente pour les postes clients (il n'y a que la MAC
de la gateway qui change). Ensuite si on veut faire ça sans auncune
interruption de service il faut un peu réfléchir.
Question naïve :
Imaginons le routeur principal sous linux (comme dans ce post) avec son
adresse IP (192.168.0.1) et un routeur secondaire (ou redondant) sous
linux aussi avec son adresse IP (192.168.0.2). Il est facile avec linux
d'automatiser des actions avec des scripts. Pourquoi ne pas faire
tourner un script sur le routeur 2 (qui ne sert à rien en temps normal)
qui ping le routeur 1 et en cas de non réponse prend l'ip du routeur 1
(/etc/sysconfig/network-script/ifcfg-ethx) et relance son interface
réseau (service network restart) ?
Pour limiter le nombre excessif de "pings", on peut imaginer "pinguer"
toutes les 5 ou 10 minutes. Il me semble que ce même script pourrait
service à tous les services ayant besoin de redondance (dhcp, dns, mail,
...).
Dites-moi si mon idée vous paraît complètement farfelue.
Il faut un deuxième routeur... ensuite le plus simple est d'utiliser un protocol su genre VRRP ou HSRP... Mais on sort de la couche ethernet, et on commence à faire de l'IP. Il existe plusieurs implémentations pour linux en particulier keepalived et vrrpd vois sur : http://www.linuxvirtualserver.org/~acassen/
Si on met comme IP de vrrp l'ancienne IP de la gateway, la modification sera presque transparente pour les postes clients (il n'y a que la MAC de la gateway qui change). Ensuite si on veut faire ça sans auncune interruption de service il faut un peu réfléchir.
Question naïve : Imaginons le routeur principal sous linux (comme dans ce post) avec son adresse IP (192.168.0.1) et un routeur secondaire (ou redondant) sous linux aussi avec son adresse IP (192.168.0.2). Il est facile avec linux d'automatiser des actions avec des scripts. Pourquoi ne pas faire tourner un script sur le routeur 2 (qui ne sert à rien en temps normal) qui ping le routeur 1 et en cas de non réponse prend l'ip du routeur 1 (/etc/sysconfig/network-script/ifcfg-ethx) et relance son interface réseau (service network restart) ? Pour limiter le nombre excessif de "pings", on peut imaginer "pinguer" toutes les 5 ou 10 minutes. Il me semble que ce même script pourrait service à tous les services ayant besoin de redondance (dhcp, dns, mail, ...). Dites-moi si mon idée vous paraît complètement farfelue.
Cordialement.
T0t0
"pepete" wrote in message news:3f3a442b$0$16542$
Question naïve : Imaginons le routeur principal sous linux (comme dans ce post) avec son adresse IP (192.168.0.1) et un routeur secondaire (ou redondant) sous linux aussi avec son adresse IP (192.168.0.2). Il est facile avec linux d'automatiser des actions avec des scripts. Pourquoi ne pas faire tourner un script sur le routeur 2 (qui ne sert à rien en temps normal) qui ping le routeur 1 et en cas de non réponse prend l'ip du routeur 1 (/etc/sysconfig/network-script/ifcfg-ethx) et relance son interface réseau (service network restart) ?
Oui, c'est tou à fait possible. Le VRRP fait à peu de choses près la même chose, ou du moins, amène le même résultat. Certains boitiers du marché fonctionnent comme tu le décris.
Pour limiter le nombre excessif de "pings", on peut imaginer "pinguer" toutes les 5 ou 10 minutes. Il me semble que ce même script pourrait service à tous les services ayant besoin de redondance (dhcp, dns, mail, ...)
Un ping par ci par la n'est pas bien méchant pour la bande passante, contrairement à la perte de la connexion. Je pense que tu peu mettre le paquet :-)
Dites-moi si mon idée vous paraît complètement farfelue.
Non non, c'est une bonne idée, déjà mise en oeuvre par ailleurs.
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
"pepete" <jeux@pepete.pff> wrote in message
news:3f3a442b$0$16542$626a54ce@news.free.fr
Question naïve :
Imaginons le routeur principal sous linux (comme dans ce post) avec son
adresse IP (192.168.0.1) et un routeur secondaire (ou redondant) sous
linux aussi avec son adresse IP (192.168.0.2). Il est facile avec linux
d'automatiser des actions avec des scripts. Pourquoi ne pas faire
tourner un script sur le routeur 2 (qui ne sert à rien en temps normal)
qui ping le routeur 1 et en cas de non réponse prend l'ip du routeur 1
(/etc/sysconfig/network-script/ifcfg-ethx) et relance son interface
réseau (service network restart) ?
Oui, c'est tou à fait possible. Le VRRP fait à peu de choses près la
même chose, ou du moins, amène le même résultat.
Certains boitiers du marché fonctionnent comme tu le décris.
Pour limiter le nombre excessif de "pings", on peut imaginer "pinguer"
toutes les 5 ou 10 minutes. Il me semble que ce même script pourrait
service à tous les services ayant besoin de redondance (dhcp, dns, mail,
...)
Un ping par ci par la n'est pas bien méchant pour la bande passante,
contrairement à la perte de la connexion. Je pense que tu peu mettre
le paquet :-)
Dites-moi si mon idée vous paraît complètement farfelue.
Non non, c'est une bonne idée, déjà mise en oeuvre par ailleurs.
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
Question naïve : Imaginons le routeur principal sous linux (comme dans ce post) avec son adresse IP (192.168.0.1) et un routeur secondaire (ou redondant) sous linux aussi avec son adresse IP (192.168.0.2). Il est facile avec linux d'automatiser des actions avec des scripts. Pourquoi ne pas faire tourner un script sur le routeur 2 (qui ne sert à rien en temps normal) qui ping le routeur 1 et en cas de non réponse prend l'ip du routeur 1 (/etc/sysconfig/network-script/ifcfg-ethx) et relance son interface réseau (service network restart) ?
Oui, c'est tou à fait possible. Le VRRP fait à peu de choses près la même chose, ou du moins, amène le même résultat. Certains boitiers du marché fonctionnent comme tu le décris.
Pour limiter le nombre excessif de "pings", on peut imaginer "pinguer" toutes les 5 ou 10 minutes. Il me semble que ce même script pourrait service à tous les services ayant besoin de redondance (dhcp, dns, mail, ...)
Un ping par ci par la n'est pas bien méchant pour la bande passante, contrairement à la perte de la connexion. Je pense que tu peu mettre le paquet :-)
Dites-moi si mon idée vous paraît complètement farfelue.
Non non, c'est une bonne idée, déjà mise en oeuvre par ailleurs.
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
Loïc BARREAU
Fontaine.Sebastien wrote:
Sebastien Fontaine
C'est très bien. Tu es juste en train de refaire la sollution VRRP dont tu trouve déjà des tous fait sur Internet.
Mais sinon le principe que tu explique est le bon. Juste une précision : Comme tu le dis le premier à 192.168.0.1 et le cond à la 0.2. Le principe est d'utiliser une troisième IP (appelé IP Virtuelle) 0.254. Tes stations seront clientes de la 0.254. Et tes scripts doivent se coordonnées pour qu'il y ait toujours un des deux routeurs qui écoute cette IP virtuelle.
Parfait, je n'ai pas encore regardé de près les URL que tu as donné précédemment, mais je vais m'y intéresser après mes vacances puisque la solution est là.
A bientôt.
Fontaine.Sebastien wrote:
Sebastien Fontaine
Fontaine.Sebastien@Laposte.Net
C'est très bien. Tu es juste en train de refaire la sollution VRRP dont tu
trouve déjà des tous fait sur Internet.
Mais sinon le principe que tu explique est le bon. Juste une précision :
Comme tu le dis le premier à 192.168.0.1 et le cond à la 0.2. Le principe
est d'utiliser une troisième IP (appelé IP Virtuelle) 0.254. Tes stations
seront clientes de la 0.254. Et tes scripts doivent se coordonnées pour
qu'il y ait toujours un des deux routeurs qui écoute cette IP virtuelle.
Parfait, je n'ai pas encore regardé de près les URL que tu as donné
précédemment, mais je vais m'y intéresser après mes vacances puisque la
solution est là.
C'est très bien. Tu es juste en train de refaire la sollution VRRP dont tu trouve déjà des tous fait sur Internet.
Mais sinon le principe que tu explique est le bon. Juste une précision : Comme tu le dis le premier à 192.168.0.1 et le cond à la 0.2. Le principe est d'utiliser une troisième IP (appelé IP Virtuelle) 0.254. Tes stations seront clientes de la 0.254. Et tes scripts doivent se coordonnées pour qu'il y ait toujours un des deux routeurs qui écoute cette IP virtuelle.
Parfait, je n'ai pas encore regardé de près les URL que tu as donné précédemment, mais je vais m'y intéresser après mes vacances puisque la solution est là.
A bientôt.
pepete
Fontaine.Sebastien wrote:
Sebastien Fontaine
C'est très bien. Tu es juste en train de refaire la sollution VRRP dont tu
trouve déjà des tous fait sur Internet.
Mais sinon le principe que tu explique est le bon. Juste une précision : Comme tu le dis le premier à 192.168.0.1 et le cond à la 0.2. Le principe est d'utiliser une troisième IP (appelé IP Virtuelle) 0.254. Tes stations seront clientes de la 0.254. Et tes scripts doivent se coordonnées pour qu'il y ait toujours un des deux routeurs qui écoute cette IP virtuelle.
Parfait. Je n'ai pas encore regardé de près les url que tu as posté précédemment, je le ferais après mes vacances puisque c'est bien ce que je voudrais mettre en place.
Merci.
Fontaine.Sebastien wrote:
Sebastien Fontaine
Fontaine.Sebastien@Laposte.Net
C'est très bien. Tu es juste en train de refaire la sollution VRRP dont tu
trouve déjà des tous fait sur Internet.
Mais sinon le principe que tu explique est le bon. Juste une précision :
Comme tu le dis le premier à 192.168.0.1 et le cond à la 0.2. Le principe
est d'utiliser une troisième IP (appelé IP Virtuelle) 0.254. Tes stations
seront clientes de la 0.254. Et tes scripts doivent se coordonnées pour
qu'il y ait toujours un des deux routeurs qui écoute cette IP virtuelle.
Parfait. Je n'ai pas encore regardé de près les url que tu as posté
précédemment, je le ferais après mes vacances puisque c'est bien ce que
je voudrais mettre en place.
C'est très bien. Tu es juste en train de refaire la sollution VRRP dont tu
trouve déjà des tous fait sur Internet.
Mais sinon le principe que tu explique est le bon. Juste une précision : Comme tu le dis le premier à 192.168.0.1 et le cond à la 0.2. Le principe est d'utiliser une troisième IP (appelé IP Virtuelle) 0.254. Tes stations seront clientes de la 0.254. Et tes scripts doivent se coordonnées pour qu'il y ait toujours un des deux routeurs qui écoute cette IP virtuelle.
Parfait. Je n'ai pas encore regardé de près les url que tu as posté précédemment, je le ferais après mes vacances puisque c'est bien ce que je voudrais mettre en place.
Merci.
Annie D.
Pourquoi ne pas faire tourner un script sur le routeur 2 (qui ne sert à rien en temps normal) qui ping le routeur 1 et en cas de non réponse prend l'ip du routeur 1
Insuffisant AMA. Le routeur principal peut très bien ne plus rien router (perte de son lien extérieur, plantage logiciel) et continuer de répondre au ping sur son interface LAN. Il faudrait soit qu'il ne communique plus du tout, soit qu'il soit capable de déterminer et de signaler au routeur secondaire qu'il n'est plus capable de router.
Pourquoi ne pas faire
tourner un script sur le routeur 2 (qui ne sert à rien en temps normal)
qui ping le routeur 1 et en cas de non réponse prend l'ip du routeur 1
Insuffisant AMA. Le routeur principal peut très bien ne plus rien router
(perte de son lien extérieur, plantage logiciel) et continuer de
répondre au ping sur son interface LAN. Il faudrait soit qu'il ne
communique plus du tout, soit qu'il soit capable de déterminer et de
signaler au routeur secondaire qu'il n'est plus capable de router.
Pourquoi ne pas faire tourner un script sur le routeur 2 (qui ne sert à rien en temps normal) qui ping le routeur 1 et en cas de non réponse prend l'ip du routeur 1
Insuffisant AMA. Le routeur principal peut très bien ne plus rien router (perte de son lien extérieur, plantage logiciel) et continuer de répondre au ping sur son interface LAN. Il faudrait soit qu'il ne communique plus du tout, soit qu'il soit capable de déterminer et de signaler au routeur secondaire qu'il n'est plus capable de router.
