Nous sommes une PME qui travaillons majoritairement en ligne.
Nous avons les besoins suivants, en gros:
- Gros download (pour lire les vid=E9os youtube, streamer du spotify,
et toute autre glandouille en ligne) ADSL2+ quoi
- Upload et ping raisonnable (ADSL2+) pour travailler en ssh/git sur
des serveurs distants
- Stabilit=E9 relative. Une coupure peut intervenir, seulement elle ne
doit pas persister plus de quelques minutes.
- IP Fixe pour limiter les acc=E8s =E0 nos serveurs distants de fa=E7on
"simple"
- Effets minimum lors du basculement d'une ligne =E0 l'autre (liens SSH
non coup=E9s et m=EAme adresse IP)
Actuellement nous avons une Freebox ADSL2+ d=E9group=E9e qui fait
l'affaire et une fibre num=E9ricable en backup (impossible =E0 utiliser en
principal car pas d'ip fixe et instabilit=E9 chronique compar=E9 =E0 la
Freebox)
Notre budget si situe dans les 100=80HT/mois (donc pas de SDSL)
Nous souhaitons migrer vers une solution ADSL avec basculement en cas
de panne et nous avons relev=E9 2 offres:
- Nerim Trust: <http://www.nerim.fr/trust-bi-adsl>
- Celeste ADSL Duo: <http://www.celeste.fr/adsl_duo.php>
Les prix sont similaires, Nerim a l'avantage de la r=E9putation, Celeste
a l'avantage de pouvoir utiliser les 2 lignes simultan=E9ment (double
d=E9bit en upload et en download)
Connaissez-vous d'autres offres ?
Que pensez-vous de Celeste ? (Je n'arrive pas =E0 trouver de t=E9moignages
sur le net)
Nos besoins sont-ils couverts par l'offre Nerim Trust que certains
d'entre vous utilisent ? Et par l'offre Celeste ?
Le Fri, 18 Sep 2009 09:38:00 +0200, GuiGui a écrit dans le message <4ab338d6$0$415$ :
Le /29 est pour le LAN derrière les deux routeurs. S'il faut au moins 6 adresses (réseau, broadcast, routeur principal, routeur de secours, routeur virtuel, équipement du client), cela nécessite d'allouer au minimum un /29.
Oui, je sais que c'est comme ça qu'on *devrait* faire, mais JKB semble dire que le /29 était coté WAN, pas coté LAN, ce qui m'étonne fortement. En fait dans ce cas je ne vois aucun intérêt par rapport à 2 FAI distincts.
Il y a des /32 (pas /30) côté WAN comme sur toutes les lignes ADSL en mode PPP.
Oui, mais ce /32 est-il en ip publique ou privée ? Il me semble que la deuxième option est plus économe en terme de classes disponibles, surtout qu'on nous bassine depuis des années avec l'épuisement des ressources IP. Comme normalement les liens PPP se terminent chez le FAI, les IP utilisées importent peu normalement.
Il y a éventuellement un /29 (ou plus) public routé derrière les deux CPE.
C'est plutôt comme ça que je voyais les choses.
Dans le cas où il y a de l'adressage public, il n'y a donc plus de NAT et toutes les bascules de liaison deviennent transparentes pour les éléments réseaux qui discutent directement avec leurs adresses publiques.
Ok. Il s'agit donc d'actif/passif. Avez-vous songé à proposer une offre de type "multilink ppp" qui permettrait d'avoir en plus de l'aggrégation ?
Dans la configuration en NAT, le routeur actif substitue naturellement aux adresses privées du LAN son adresse publique, et la perte du lien associé entraîne donc une sortie par l'autre lien, avec une autre adresse, et donc la perte des connexions en cours.
Mmmm. Je me demande si avec des cisco 8xx on arriverai pas à créer une conf qui fonctionne même en NAT.
Le seul avantage par rapport à la solution maison "faite avec les mains" dans ce cas, c'est que l'abonnement de l'offre avec les deux lignes revient moins cher que deux abonnements séparés.
Effectivement à moins de 80€... Mais pas de GTR, donc si les 2 lignes tombent, c'est mort pour combien de temps ?
Pour ce qui s'appellait l'offre "Trust", les difficultés de construction des lignes secondaires vont toutefois conduire à l'abandon de celle-ci, au profit d'une offre "ADSL à GTR" car depuis peu, il est possible de demander la GTR sur des accès à débit crête à prix raisonnable.
Par contre il me semble qu'il s'agit d'une GTR 10 h (et pas 4 h).
Peut-être même une GTR 48h mais je ne sais pas si elle est commercialisée (il me semble qu'elle m'avait été évoquée pour un abonnement orange pro).
Raphael Bouaziz a écrit :
Le Fri, 18 Sep 2009 09:38:00 +0200, GuiGui a écrit
dans le message <4ab338d6$0$415$426a74cc@news.free.fr> :
Le /29 est pour le LAN derrière les deux routeurs. S'il faut au moins 6
adresses (réseau, broadcast, routeur principal, routeur de secours,
routeur virtuel, équipement du client), cela nécessite d'allouer au
minimum un /29.
Oui, je sais que c'est comme ça qu'on *devrait* faire, mais JKB semble
dire que le /29 était coté WAN, pas coté LAN, ce qui m'étonne fortement.
En fait dans ce cas je ne vois aucun intérêt par rapport à 2 FAI distincts.
Il y a des /32 (pas /30) côté WAN comme sur toutes les lignes ADSL
en mode PPP.
Oui, mais ce /32 est-il en ip publique ou privée ? Il me semble que la
deuxième option est plus économe en terme de classes disponibles,
surtout qu'on nous bassine depuis des années avec l'épuisement des
ressources IP. Comme normalement les liens PPP se terminent chez le FAI,
les IP utilisées importent peu normalement.
Il y a éventuellement un /29 (ou plus) public routé derrière les deux CPE.
C'est plutôt comme ça que je voyais les choses.
Dans le cas où il y a de l'adressage public, il n'y a donc plus de NAT et
toutes les bascules de liaison deviennent transparentes pour les éléments
réseaux qui discutent directement avec leurs adresses publiques.
Ok.
Il s'agit donc d'actif/passif. Avez-vous songé à proposer une offre de
type "multilink ppp" qui permettrait d'avoir en plus de l'aggrégation ?
Dans la configuration en NAT, le routeur actif substitue naturellement
aux adresses privées du LAN son adresse publique, et la perte du lien
associé entraîne donc une sortie par l'autre lien, avec une autre
adresse, et donc la perte des connexions en cours.
Mmmm. Je me demande si avec des cisco 8xx on arriverai pas à créer une
conf qui fonctionne même en NAT.
Le seul avantage par rapport à la solution maison "faite avec les mains"
dans ce cas, c'est que l'abonnement de l'offre avec les deux lignes
revient moins cher que deux abonnements séparés.
Effectivement à moins de 80€... Mais pas de GTR, donc si les 2 lignes
tombent, c'est mort pour combien de temps ?
Pour ce qui s'appellait l'offre "Trust", les difficultés de construction
des lignes secondaires vont toutefois conduire à l'abandon de celle-ci,
au profit d'une offre "ADSL à GTR" car depuis peu, il est possible
de demander la GTR sur des accès à débit crête à prix raisonnable.
Par contre il me semble qu'il s'agit d'une GTR 10 h (et pas 4 h).
Peut-être même une GTR 48h mais je ne sais pas si elle est
commercialisée (il me semble qu'elle m'avait été évoquée pour un
abonnement orange pro).
Le Fri, 18 Sep 2009 09:38:00 +0200, GuiGui a écrit dans le message <4ab338d6$0$415$ :
Le /29 est pour le LAN derrière les deux routeurs. S'il faut au moins 6 adresses (réseau, broadcast, routeur principal, routeur de secours, routeur virtuel, équipement du client), cela nécessite d'allouer au minimum un /29.
Oui, je sais que c'est comme ça qu'on *devrait* faire, mais JKB semble dire que le /29 était coté WAN, pas coté LAN, ce qui m'étonne fortement. En fait dans ce cas je ne vois aucun intérêt par rapport à 2 FAI distincts.
Il y a des /32 (pas /30) côté WAN comme sur toutes les lignes ADSL en mode PPP.
Oui, mais ce /32 est-il en ip publique ou privée ? Il me semble que la deuxième option est plus économe en terme de classes disponibles, surtout qu'on nous bassine depuis des années avec l'épuisement des ressources IP. Comme normalement les liens PPP se terminent chez le FAI, les IP utilisées importent peu normalement.
Il y a éventuellement un /29 (ou plus) public routé derrière les deux CPE.
C'est plutôt comme ça que je voyais les choses.
Dans le cas où il y a de l'adressage public, il n'y a donc plus de NAT et toutes les bascules de liaison deviennent transparentes pour les éléments réseaux qui discutent directement avec leurs adresses publiques.
Ok. Il s'agit donc d'actif/passif. Avez-vous songé à proposer une offre de type "multilink ppp" qui permettrait d'avoir en plus de l'aggrégation ?
Dans la configuration en NAT, le routeur actif substitue naturellement aux adresses privées du LAN son adresse publique, et la perte du lien associé entraîne donc une sortie par l'autre lien, avec une autre adresse, et donc la perte des connexions en cours.
Mmmm. Je me demande si avec des cisco 8xx on arriverai pas à créer une conf qui fonctionne même en NAT.
Le seul avantage par rapport à la solution maison "faite avec les mains" dans ce cas, c'est que l'abonnement de l'offre avec les deux lignes revient moins cher que deux abonnements séparés.
Effectivement à moins de 80€... Mais pas de GTR, donc si les 2 lignes tombent, c'est mort pour combien de temps ?
Pour ce qui s'appellait l'offre "Trust", les difficultés de construction des lignes secondaires vont toutefois conduire à l'abandon de celle-ci, au profit d'une offre "ADSL à GTR" car depuis peu, il est possible de demander la GTR sur des accès à débit crête à prix raisonnable.
Par contre il me semble qu'il s'agit d'une GTR 10 h (et pas 4 h).
Peut-être même une GTR 48h mais je ne sais pas si elle est commercialisée (il me semble qu'elle m'avait été évoquée pour un abonnement orange pro).
Raphael Bouaziz
Le Fri, 18 Sep 2009 17:13:44 +0200, GuiGui a écrit dans le message <4ab3a3a4$0$8006$ :
Il y a des /32 (pas /30) côté WAN comme sur toutes les lignes ADSL en mode PPP.
Oui, mais ce /32 est-il en ip publique ou privée ? Il me semble que la deuxième option est plus économe en terme de classes disponibles,
En adressage public. Et ce même si ces adresses ne sont pas utilisées pour le NAT, et qu'il y a un bloc d'adresses IP derrière.
Un noeud de routage vers un réseau en adressage public doit toujours disposer d'adresses publiques, ne serait-ce que pour retourner à l'expéditeur des informations sur l'accessibilité du réseau via le protocole ICMP.
Il s'agit donc d'actif/passif. Avez-vous songé à proposer une offre de type "multilink ppp" qui permettrait d'avoir en plus de l'aggrégation ?
Non je préfère les réseaux qui fonctionnent, mais bon je reconnais que c'est un avis personnel.
Le PPP multilink ça fonctionne bien quand le réseau sous-jacent dispose d'un minimum de garantie et de synchronisation. Par exemple sur un réseau à base TDM type RNIS.
Sur un réseau DSL totalement asynchrone, le mieux serait peut-être de faire de l'équilibrage au niveau IP, mais ce n'est pas la joie ; en général à côté de "aggrégation IP" il y a la phrase "problèmes bizarres de réseau" rangée pas loin.
Ces problèmes peuvent être de type opérationnels (par exemple un lien va avoir tendance à être beaucoup plus utilisé que l'autre, ou alors dans un seul sens) ou mêmes fonctionnels (le TCP a quand même besoin d'un minimum de synchronisation pour fonctionner correctement).
Mmmm. Je me demande si avec des cisco 8xx on arriverai pas à créer une conf qui fonctionne même en NAT.
Peut-être, je sais qu'il y a des modèles de firewalls capables de synchroniser des tables d'état et de NAT.
Effectivement à moins de 80€... Mais pas de GTR, donc si les 2 lignes tombent, c'est mort pour combien de temps ?
C'est le problème du réseau cuivre, personne n'est à l'abri d'un câble coupé par malveillance, ce qui est plus courant qu'on ne l'imagine.
-- Raphael Bouaziz.
Le Fri, 18 Sep 2009 17:13:44 +0200, GuiGui a écrit
dans le message <4ab3a3a4$0$8006$426a34cc@news.free.fr> :
Il y a des /32 (pas /30) côté WAN comme sur toutes les lignes ADSL
en mode PPP.
Oui, mais ce /32 est-il en ip publique ou privée ? Il me semble que la
deuxième option est plus économe en terme de classes disponibles,
En adressage public. Et ce même si ces adresses ne sont pas utilisées
pour le NAT, et qu'il y a un bloc d'adresses IP derrière.
Un noeud de routage vers un réseau en adressage public doit toujours
disposer d'adresses publiques, ne serait-ce que pour retourner à
l'expéditeur des informations sur l'accessibilité du réseau via
le protocole ICMP.
Il s'agit donc d'actif/passif. Avez-vous songé à proposer une offre de
type "multilink ppp" qui permettrait d'avoir en plus de l'aggrégation ?
Non je préfère les réseaux qui fonctionnent, mais bon je reconnais que
c'est un avis personnel.
Le PPP multilink ça fonctionne bien quand le réseau sous-jacent dispose
d'un minimum de garantie et de synchronisation. Par exemple sur un
réseau à base TDM type RNIS.
Sur un réseau DSL totalement asynchrone, le mieux serait peut-être de
faire de l'équilibrage au niveau IP, mais ce n'est pas la joie ; en
général à côté de "aggrégation IP" il y a la phrase "problèmes
bizarres de réseau" rangée pas loin.
Ces problèmes peuvent être de type opérationnels (par exemple un lien
va avoir tendance à être beaucoup plus utilisé que l'autre, ou alors
dans un seul sens) ou mêmes fonctionnels (le TCP a quand même besoin
d'un minimum de synchronisation pour fonctionner correctement).
Mmmm. Je me demande si avec des cisco 8xx on arriverai pas à créer une
conf qui fonctionne même en NAT.
Peut-être, je sais qu'il y a des modèles de firewalls capables de
synchroniser des tables d'état et de NAT.
Effectivement à moins de 80€... Mais pas de GTR, donc si les 2 lignes
tombent, c'est mort pour combien de temps ?
C'est le problème du réseau cuivre, personne n'est à l'abri d'un câble
coupé par malveillance, ce qui est plus courant qu'on ne l'imagine.
Le Fri, 18 Sep 2009 17:13:44 +0200, GuiGui a écrit dans le message <4ab3a3a4$0$8006$ :
Il y a des /32 (pas /30) côté WAN comme sur toutes les lignes ADSL en mode PPP.
Oui, mais ce /32 est-il en ip publique ou privée ? Il me semble que la deuxième option est plus économe en terme de classes disponibles,
En adressage public. Et ce même si ces adresses ne sont pas utilisées pour le NAT, et qu'il y a un bloc d'adresses IP derrière.
Un noeud de routage vers un réseau en adressage public doit toujours disposer d'adresses publiques, ne serait-ce que pour retourner à l'expéditeur des informations sur l'accessibilité du réseau via le protocole ICMP.
Il s'agit donc d'actif/passif. Avez-vous songé à proposer une offre de type "multilink ppp" qui permettrait d'avoir en plus de l'aggrégation ?
Non je préfère les réseaux qui fonctionnent, mais bon je reconnais que c'est un avis personnel.
Le PPP multilink ça fonctionne bien quand le réseau sous-jacent dispose d'un minimum de garantie et de synchronisation. Par exemple sur un réseau à base TDM type RNIS.
Sur un réseau DSL totalement asynchrone, le mieux serait peut-être de faire de l'équilibrage au niveau IP, mais ce n'est pas la joie ; en général à côté de "aggrégation IP" il y a la phrase "problèmes bizarres de réseau" rangée pas loin.
Ces problèmes peuvent être de type opérationnels (par exemple un lien va avoir tendance à être beaucoup plus utilisé que l'autre, ou alors dans un seul sens) ou mêmes fonctionnels (le TCP a quand même besoin d'un minimum de synchronisation pour fonctionner correctement).
Mmmm. Je me demande si avec des cisco 8xx on arriverai pas à créer une conf qui fonctionne même en NAT.
Peut-être, je sais qu'il y a des modèles de firewalls capables de synchroniser des tables d'état et de NAT.
Effectivement à moins de 80€... Mais pas de GTR, donc si les 2 lignes tombent, c'est mort pour combien de temps ?
C'est le problème du réseau cuivre, personne n'est à l'abri d'un câble coupé par malveillance, ce qui est plus courant qu'on ne l'imagine.
-- Raphael Bouaziz.
Pascal Hambourg
Raphael Bouaziz a écrit :
Un noeud de routage vers un réseau en adressage public doit toujours disposer d'adresses publiques, ne serait-ce que pour retourner à l'expéditeur des informations sur l'accessibilité du réseau via le protocole ICMP.
Hélas il n'est pas exceptionnel de rencontrer une adresse privée dans une réponse ICMP au détour d'un traceroute sur un réseau public.
Mmmm. Je me demande si avec des cisco 8xx on arriverai pas à créer une conf qui fonctionne même en NAT.
Peut-être, je sais qu'il y a des modèles de firewalls capables de synchroniser des tables d'état et de NAT.
Je ne vois pas comment la synchronisation des NAT peut compenser le changement de l'adresse IP publique. Si le FAI ne route pas l'adresse IP principale sur la connexion de secours, les connexions existantes sont mortes.
Raphael Bouaziz a écrit :
Un noeud de routage vers un réseau en adressage public doit toujours
disposer d'adresses publiques, ne serait-ce que pour retourner à
l'expéditeur des informations sur l'accessibilité du réseau via
le protocole ICMP.
Hélas il n'est pas exceptionnel de rencontrer une adresse privée dans
une réponse ICMP au détour d'un traceroute sur un réseau public.
Mmmm. Je me demande si avec des cisco 8xx on arriverai pas à créer une
conf qui fonctionne même en NAT.
Peut-être, je sais qu'il y a des modèles de firewalls capables de
synchroniser des tables d'état et de NAT.
Je ne vois pas comment la synchronisation des NAT peut compenser le
changement de l'adresse IP publique. Si le FAI ne route pas l'adresse IP
principale sur la connexion de secours, les connexions existantes sont
mortes.
Un noeud de routage vers un réseau en adressage public doit toujours disposer d'adresses publiques, ne serait-ce que pour retourner à l'expéditeur des informations sur l'accessibilité du réseau via le protocole ICMP.
Hélas il n'est pas exceptionnel de rencontrer une adresse privée dans une réponse ICMP au détour d'un traceroute sur un réseau public.
Mmmm. Je me demande si avec des cisco 8xx on arriverai pas à créer une conf qui fonctionne même en NAT.
Peut-être, je sais qu'il y a des modèles de firewalls capables de synchroniser des tables d'état et de NAT.
Je ne vois pas comment la synchronisation des NAT peut compenser le changement de l'adresse IP publique. Si le FAI ne route pas l'adresse IP principale sur la connexion de secours, les connexions existantes sont mortes.
GuiGui
Pascal Hambourg a écrit :
Raphael Bouaziz a écrit :
Un noeud de routage vers un réseau en adressage public doit toujours disposer d'adresses publiques, ne serait-ce que pour retourner à l'expéditeur des informations sur l'accessibilité du réseau via le protocole ICMP.
Hélas il n'est pas exceptionnel de rencontrer une adresse privée dans une réponse ICMP au détour d'un traceroute sur un réseau public.
Mmmm. Je me demande si avec des cisco 8xx on arriverai pas à créer une conf qui fonctionne même en NAT.
Peut-être, je sais qu'il y a des modèles de firewalls capables de synchroniser des tables d'état et de NAT.
Je ne vois pas comment la synchronisation des NAT peut compenser le changement de l'adresse IP publique. Si le FAI ne route pas l'adresse IP principale sur la connexion de secours, les connexions existantes sont mortes.
Un exemple de liens redondants qui fonctionne avec des IP privées entre le CPE et l'opérateur (plusieurs centaines de liaison doubles déployées) : http://www.crihan.fr/res/syrhano/news/2009-06-05-JSR-COLLECTE-XDSL.pdf
Pascal Hambourg a écrit :
Raphael Bouaziz a écrit :
Un noeud de routage vers un réseau en adressage public doit toujours
disposer d'adresses publiques, ne serait-ce que pour retourner à
l'expéditeur des informations sur l'accessibilité du réseau via
le protocole ICMP.
Hélas il n'est pas exceptionnel de rencontrer une adresse privée dans
une réponse ICMP au détour d'un traceroute sur un réseau public.
Mmmm. Je me demande si avec des cisco 8xx on arriverai pas à créer une
conf qui fonctionne même en NAT.
Peut-être, je sais qu'il y a des modèles de firewalls capables de
synchroniser des tables d'état et de NAT.
Je ne vois pas comment la synchronisation des NAT peut compenser le
changement de l'adresse IP publique. Si le FAI ne route pas l'adresse IP
principale sur la connexion de secours, les connexions existantes sont
mortes.
Un exemple de liens redondants qui fonctionne avec des IP privées entre
le CPE et l'opérateur (plusieurs centaines de liaison doubles déployées)
: http://www.crihan.fr/res/syrhano/news/2009-06-05-JSR-COLLECTE-XDSL.pdf
Un noeud de routage vers un réseau en adressage public doit toujours disposer d'adresses publiques, ne serait-ce que pour retourner à l'expéditeur des informations sur l'accessibilité du réseau via le protocole ICMP.
Hélas il n'est pas exceptionnel de rencontrer une adresse privée dans une réponse ICMP au détour d'un traceroute sur un réseau public.
Mmmm. Je me demande si avec des cisco 8xx on arriverai pas à créer une conf qui fonctionne même en NAT.
Peut-être, je sais qu'il y a des modèles de firewalls capables de synchroniser des tables d'état et de NAT.
Je ne vois pas comment la synchronisation des NAT peut compenser le changement de l'adresse IP publique. Si le FAI ne route pas l'adresse IP principale sur la connexion de secours, les connexions existantes sont mortes.
Un exemple de liens redondants qui fonctionne avec des IP privées entre le CPE et l'opérateur (plusieurs centaines de liaison doubles déployées) : http://www.crihan.fr/res/syrhano/news/2009-06-05-JSR-COLLECTE-XDSL.pdf
Raphael Bouaziz
Le Fri, 18 Sep 2009 17:55:38 +0200, Pascal Hambourg a écrit dans le message <h90ahq$smv$ :
Hélas il n'est pas exceptionnel de rencontrer une adresse privée dans une réponse ICMP au détour d'un traceroute sur un réseau public.
Malheureusement oui.
Je ne vois pas comment la synchronisation des NAT peut compenser le changement de l'adresse IP publique. Si le FAI ne route pas l'adresse IP principale sur la connexion de secours, les connexions existantes sont mortes.
Les firewalls qui font cela sont également capables de se "partager" une adresse IP qui ne sert qu'au NAT.
Cela ne serait pas implémentable dans le cadre de deux lignes ADSL dont on discute ici.
-- Raphael Bouaziz.
Le Fri, 18 Sep 2009 17:55:38 +0200, Pascal Hambourg a écrit
dans le message <h90ahq$smv$1@saria.nerim.net> :
Hélas il n'est pas exceptionnel de rencontrer une adresse privée dans
une réponse ICMP au détour d'un traceroute sur un réseau public.
Malheureusement oui.
Je ne vois pas comment la synchronisation des NAT peut compenser le
changement de l'adresse IP publique. Si le FAI ne route pas l'adresse IP
principale sur la connexion de secours, les connexions existantes sont
mortes.
Les firewalls qui font cela sont également capables de se "partager"
une adresse IP qui ne sert qu'au NAT.
Cela ne serait pas implémentable dans le cadre de deux lignes ADSL
dont on discute ici.
Le Fri, 18 Sep 2009 17:55:38 +0200, Pascal Hambourg a écrit dans le message <h90ahq$smv$ :
Hélas il n'est pas exceptionnel de rencontrer une adresse privée dans une réponse ICMP au détour d'un traceroute sur un réseau public.
Malheureusement oui.
Je ne vois pas comment la synchronisation des NAT peut compenser le changement de l'adresse IP publique. Si le FAI ne route pas l'adresse IP principale sur la connexion de secours, les connexions existantes sont mortes.
Les firewalls qui font cela sont également capables de se "partager" une adresse IP qui ne sert qu'au NAT.
Cela ne serait pas implémentable dans le cadre de deux lignes ADSL dont on discute ici.
-- Raphael Bouaziz.
Pascal Hambourg
Raphael Bouaziz a écrit :
Le Fri, 18 Sep 2009 17:55:38 +0200, Pascal Hambourg a écrit dans le message <h90ahq$smv$ :
Je ne vois pas comment la synchronisation des NAT peut compenser le changement de l'adresse IP publique. Si le FAI ne route pas l'adresse IP principale sur la connexion de secours, les connexions existantes sont mortes.
Les firewalls qui font cela sont également capables de se "partager" une adresse IP qui ne sert qu'au NAT.
J'entends bien, mais mon objection ne portait pas sur ce point.
Cela ne serait pas implémentable dans le cadre de deux lignes ADSL dont on discute ici.
D'accord, il faudraient que les deux connexions utilisent la même adresse. Pourquoi, au fait ? Le /29 est bien routé sur les deux connexions, pourquoi pas la même adresse PPP ?
Raphael Bouaziz a écrit :
Le Fri, 18 Sep 2009 17:55:38 +0200, Pascal Hambourg a écrit
dans le message <h90ahq$smv$1@saria.nerim.net> :
Je ne vois pas comment la synchronisation des NAT peut compenser le
changement de l'adresse IP publique. Si le FAI ne route pas l'adresse IP
principale sur la connexion de secours, les connexions existantes sont
mortes.
Les firewalls qui font cela sont également capables de se "partager"
une adresse IP qui ne sert qu'au NAT.
J'entends bien, mais mon objection ne portait pas sur ce point.
Cela ne serait pas implémentable dans le cadre de deux lignes ADSL
dont on discute ici.
D'accord, il faudraient que les deux connexions utilisent la même
adresse. Pourquoi, au fait ? Le /29 est bien routé sur les deux
connexions, pourquoi pas la même adresse PPP ?
Le Fri, 18 Sep 2009 17:55:38 +0200, Pascal Hambourg a écrit dans le message <h90ahq$smv$ :
Je ne vois pas comment la synchronisation des NAT peut compenser le changement de l'adresse IP publique. Si le FAI ne route pas l'adresse IP principale sur la connexion de secours, les connexions existantes sont mortes.
Les firewalls qui font cela sont également capables de se "partager" une adresse IP qui ne sert qu'au NAT.
J'entends bien, mais mon objection ne portait pas sur ce point.
Cela ne serait pas implémentable dans le cadre de deux lignes ADSL dont on discute ici.
D'accord, il faudraient que les deux connexions utilisent la même adresse. Pourquoi, au fait ? Le /29 est bien routé sur les deux connexions, pourquoi pas la même adresse PPP ?
Channels
> C'est le problème du réseau cuivre, personne n'est à l'abri d'un câble coupé par malveillance, ce qui est plus courant qu'on ne l'imagine.
ou d'une jarretiere coupé en RE ou SR, un technicien qui se trompe de plot sur les reglettes, d'un cable d'EP coupé par l'elagage du voisin, une distri en traversé de route arraché par un camion, un manchons qui prend l'eau, un BPR ecrasé par un tractopelle, un parafoudre qui amorce, bref, on est vraiment a l'abri de rien coté telecom ... :)))
-- Les fautes d'orthographes sus-citées sont déposées auprès de leurs propriétaires respectifs. Aucune responsabilité n'est engagée sur la lisibilité du message ou les éventuels dommages qu'ils peuvent engendrer
> C'est le problème du réseau cuivre, personne n'est à l'abri d'un câble
coupé par malveillance, ce qui est plus courant qu'on ne l'imagine.
ou d'une jarretiere coupé en RE ou SR, un technicien qui se trompe de
plot sur les reglettes, d'un cable d'EP coupé par l'elagage du voisin,
une distri en traversé de route arraché par un camion, un manchons qui
prend l'eau, un BPR ecrasé par un tractopelle, un parafoudre qui
amorce, bref, on est vraiment a l'abri de rien coté telecom ... :)))
--
Les fautes d'orthographes sus-citées sont déposées auprès de leurs
propriétaires respectifs.
Aucune responsabilité n'est engagée sur la lisibilité du message ou les
éventuels dommages qu'ils peuvent engendrer
> C'est le problème du réseau cuivre, personne n'est à l'abri d'un câble coupé par malveillance, ce qui est plus courant qu'on ne l'imagine.
ou d'une jarretiere coupé en RE ou SR, un technicien qui se trompe de plot sur les reglettes, d'un cable d'EP coupé par l'elagage du voisin, une distri en traversé de route arraché par un camion, un manchons qui prend l'eau, un BPR ecrasé par un tractopelle, un parafoudre qui amorce, bref, on est vraiment a l'abri de rien coté telecom ... :)))
-- Les fautes d'orthographes sus-citées sont déposées auprès de leurs propriétaires respectifs. Aucune responsabilité n'est engagée sur la lisibilité du message ou les éventuels dommages qu'ils peuvent engendrer
GuiGui
Pascal Hambourg a écrit :
D'accord, il faudraient que les deux connexions utilisent la même adresse. Pourquoi, au fait ? Le /29 est bien routé sur les deux connexions, pourquoi pas la même adresse PPP ?
Peut-être parce que si on veut router le /29 il faut pouvoir déterminer une gateway (dans le sens backbone-cpe, parce que dans l'autre sens c'est évident puisque chaque cpe voit un seul pair) ?
Pascal Hambourg a écrit :
D'accord, il faudraient que les deux connexions utilisent la même
adresse. Pourquoi, au fait ? Le /29 est bien routé sur les deux
connexions, pourquoi pas la même adresse PPP ?
Peut-être parce que si on veut router le /29 il faut pouvoir déterminer
une gateway (dans le sens backbone-cpe, parce que dans l'autre sens
c'est évident puisque chaque cpe voit un seul pair) ?
D'accord, il faudraient que les deux connexions utilisent la même adresse. Pourquoi, au fait ? Le /29 est bien routé sur les deux connexions, pourquoi pas la même adresse PPP ?
Peut-être parce que si on veut router le /29 il faut pouvoir déterminer une gateway (dans le sens backbone-cpe, parce que dans l'autre sens c'est évident puisque chaque cpe voit un seul pair) ?
Raphael Bouaziz
Le Fri, 18 Sep 2009 20:34:58 +0200, Pascal Hambourg a écrit dans le message <h90jsi$vif$ :
D'accord, il faudraient que les deux connexions utilisent la même adresse. Pourquoi, au fait ? Le /29 est bien routé sur les deux connexions, pourquoi pas la même adresse PPP ?
On pourrait imaginer ne pas mettre d'adresse PPP du tout (unnumbered) et router un /32 unique servant au NAT (qui ne serait pas une adresse PPP dans ce cas).
Mais la même adresse PPP sur deux liens différents, ça s'apparenterait à de l'anycast. Et là il faut savoir ce qu'on fait. Ce n'est pas approprié à de la redondance de connexion.
-- Raphael Bouaziz.
Le Fri, 18 Sep 2009 20:34:58 +0200, Pascal Hambourg a écrit
dans le message <h90jsi$vif$1@saria.nerim.net> :
D'accord, il faudraient que les deux connexions utilisent la même
adresse. Pourquoi, au fait ? Le /29 est bien routé sur les deux
connexions, pourquoi pas la même adresse PPP ?
On pourrait imaginer ne pas mettre d'adresse PPP du tout (unnumbered)
et router un /32 unique servant au NAT (qui ne serait pas une adresse
PPP dans ce cas).
Mais la même adresse PPP sur deux liens différents, ça s'apparenterait
à de l'anycast. Et là il faut savoir ce qu'on fait. Ce n'est pas
approprié à de la redondance de connexion.
Le Fri, 18 Sep 2009 20:34:58 +0200, Pascal Hambourg a écrit dans le message <h90jsi$vif$ :
D'accord, il faudraient que les deux connexions utilisent la même adresse. Pourquoi, au fait ? Le /29 est bien routé sur les deux connexions, pourquoi pas la même adresse PPP ?
On pourrait imaginer ne pas mettre d'adresse PPP du tout (unnumbered) et router un /32 unique servant au NAT (qui ne serait pas une adresse PPP dans ce cas).
Mais la même adresse PPP sur deux liens différents, ça s'apparenterait à de l'anycast. Et là il faut savoir ce qu'on fait. Ce n'est pas approprié à de la redondance de connexion.
-- Raphael Bouaziz.
Raphael Bouaziz
Le Fri, 18 Sep 2009 20:34:58 +0200, Pascal Hambourg a écrit dans le message <h90jsi$vif$ :
D'accord, il faudraient que les deux connexions utilisent la même adresse. Pourquoi, au fait ? Le /29 est bien routé sur les deux connexions, pourquoi pas la même adresse PPP ?
On pourrait imaginer ne pas mettre d'adresse PPP du tout (unnumbered) et router un /32 unique servant au NAT (qui ne serait pas une adresse PPP dans ce cas).
Mais la même adresse PPP sur deux liens différents, ça s'apparenterait à de l'anycast. Et là il faut savoir ce qu'on fait. Ce n'est pas approprié pour de la redondance de connexion.
-- Raphael Bouaziz.
Le Fri, 18 Sep 2009 20:34:58 +0200, Pascal Hambourg a écrit
dans le message <h90jsi$vif$1@saria.nerim.net> :
D'accord, il faudraient que les deux connexions utilisent la même
adresse. Pourquoi, au fait ? Le /29 est bien routé sur les deux
connexions, pourquoi pas la même adresse PPP ?
On pourrait imaginer ne pas mettre d'adresse PPP du tout (unnumbered)
et router un /32 unique servant au NAT (qui ne serait pas une adresse
PPP dans ce cas).
Mais la même adresse PPP sur deux liens différents, ça s'apparenterait
à de l'anycast. Et là il faut savoir ce qu'on fait. Ce n'est pas
approprié pour de la redondance de connexion.
Le Fri, 18 Sep 2009 20:34:58 +0200, Pascal Hambourg a écrit dans le message <h90jsi$vif$ :
D'accord, il faudraient que les deux connexions utilisent la même adresse. Pourquoi, au fait ? Le /29 est bien routé sur les deux connexions, pourquoi pas la même adresse PPP ?
On pourrait imaginer ne pas mettre d'adresse PPP du tout (unnumbered) et router un /32 unique servant au NAT (qui ne serait pas une adresse PPP dans ce cas).
Mais la même adresse PPP sur deux liens différents, ça s'apparenterait à de l'anycast. Et là il faut savoir ce qu'on fait. Ce n'est pas approprié pour de la redondance de connexion.
