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 Sun, 20 Sep 2009 21:29:58 +0200, GuiGui a écrit dans le message <4ab682b6$0$22548$ :
Moi j'ai une question : pourquoi faire la supervision depuis le backbone ? Les deux routeurs doivent pouvoir vérifier eux-même que leur gateway est joignable et annoncer par BGP, non ?
Mettons de côté le fait que ce n'est pas du BGP, ce n'est pas important.
Les routeurs d'accès qui connectent les liens ne sont qu'une partie de la chaîne. Les routeurs peuvent avoir la route vers le client dans leur table de routage mais un autre problème peut rendre les liens inutilisables.
En se mettant à la place d'un serveur qu'on pourrait contacter au travers de l'accès, on voit mieux ce qu'il se passe. Notamment tous les problèmes de connexions dégradées.
-- Raphael Bouaziz.
Le Sun, 20 Sep 2009 21:29:58 +0200, GuiGui a écrit
dans le message <4ab682b6$0$22548$426a34cc@news.free.fr> :
Moi j'ai une question : pourquoi faire la supervision depuis le backbone
? Les deux routeurs doivent pouvoir vérifier eux-même que leur gateway
est joignable et annoncer par BGP, non ?
Mettons de côté le fait que ce n'est pas du BGP, ce n'est pas important.
Les routeurs d'accès qui connectent les liens ne sont qu'une partie de
la chaîne. Les routeurs peuvent avoir la route vers le client dans leur
table de routage mais un autre problème peut rendre les liens inutilisables.
En se mettant à la place d'un serveur qu'on pourrait contacter au travers
de l'accès, on voit mieux ce qu'il se passe. Notamment tous les problèmes
de connexions dégradées.
Le Sun, 20 Sep 2009 21:29:58 +0200, GuiGui a écrit dans le message <4ab682b6$0$22548$ :
Moi j'ai une question : pourquoi faire la supervision depuis le backbone ? Les deux routeurs doivent pouvoir vérifier eux-même que leur gateway est joignable et annoncer par BGP, non ?
Mettons de côté le fait que ce n'est pas du BGP, ce n'est pas important.
Les routeurs d'accès qui connectent les liens ne sont qu'une partie de la chaîne. Les routeurs peuvent avoir la route vers le client dans leur table de routage mais un autre problème peut rendre les liens inutilisables.
En se mettant à la place d'un serveur qu'on pourrait contacter au travers de l'accès, on voit mieux ce qu'il se passe. Notamment tous les problèmes de connexions dégradées.
-- Raphael Bouaziz.
GuiGui
Raphael Bouaziz a écrit :
Le Sun, 20 Sep 2009 21:29:58 +0200, GuiGui a écrit dans le message <4ab682b6$0$22548$ :
Moi j'ai une question : pourquoi faire la supervision depuis le backbone ? Les deux routeurs doivent pouvoir vérifier eux-même que leur gateway est joignable et annoncer par BGP, non ?
Mettons de côté le fait que ce n'est pas du BGP, ce n'est pas important.
Les routeurs d'accès qui connectent les liens ne sont qu'une partie de la chaîne. Les routeurs peuvent avoir la route vers le client dans leur table de routage mais un autre problème peut rendre les liens inutilisables.
En se mettant à la place d'un serveur qu'on pourrait contacter au travers de l'accès, on voit mieux ce qu'il se passe. Notamment tous les problèmes de connexions dégradées.
Ok, donc pour le sens backbone -> CPE vous décidez de la route en testant les liens. Mais dans l'autre sens, si c'est juste une dégradation et pas une coupure franche, les CPE se voient toujours connectés, non ? Dans ce cas, comment peut-on garantir que les paquets prennent le bon chemin et pas la liaison dégradée dans le sens CPE-backbone ?
Raphael Bouaziz a écrit :
Le Sun, 20 Sep 2009 21:29:58 +0200, GuiGui a écrit
dans le message <4ab682b6$0$22548$426a34cc@news.free.fr> :
Moi j'ai une question : pourquoi faire la supervision depuis le backbone
? Les deux routeurs doivent pouvoir vérifier eux-même que leur gateway
est joignable et annoncer par BGP, non ?
Mettons de côté le fait que ce n'est pas du BGP, ce n'est pas important.
Les routeurs d'accès qui connectent les liens ne sont qu'une partie de
la chaîne. Les routeurs peuvent avoir la route vers le client dans leur
table de routage mais un autre problème peut rendre les liens inutilisables.
En se mettant à la place d'un serveur qu'on pourrait contacter au travers
de l'accès, on voit mieux ce qu'il se passe. Notamment tous les problèmes
de connexions dégradées.
Ok, donc pour le sens backbone -> CPE vous décidez de la route en
testant les liens. Mais dans l'autre sens, si c'est juste une
dégradation et pas une coupure franche, les CPE se voient toujours
connectés, non ? Dans ce cas, comment peut-on garantir que les paquets
prennent le bon chemin et pas la liaison dégradée dans le sens
CPE-backbone ?
Le Sun, 20 Sep 2009 21:29:58 +0200, GuiGui a écrit dans le message <4ab682b6$0$22548$ :
Moi j'ai une question : pourquoi faire la supervision depuis le backbone ? Les deux routeurs doivent pouvoir vérifier eux-même que leur gateway est joignable et annoncer par BGP, non ?
Mettons de côté le fait que ce n'est pas du BGP, ce n'est pas important.
Les routeurs d'accès qui connectent les liens ne sont qu'une partie de la chaîne. Les routeurs peuvent avoir la route vers le client dans leur table de routage mais un autre problème peut rendre les liens inutilisables.
En se mettant à la place d'un serveur qu'on pourrait contacter au travers de l'accès, on voit mieux ce qu'il se passe. Notamment tous les problèmes de connexions dégradées.
Ok, donc pour le sens backbone -> CPE vous décidez de la route en testant les liens. Mais dans l'autre sens, si c'est juste une dégradation et pas une coupure franche, les CPE se voient toujours connectés, non ? Dans ce cas, comment peut-on garantir que les paquets prennent le bon chemin et pas la liaison dégradée dans le sens CPE-backbone ?
Raphael Bouaziz
Le Sun, 20 Sep 2009 23:23:33 +0200, GuiGui a écrit dans le message <4ab69d55$0$8789$ :
Ok, donc pour le sens backbone -> CPE vous décidez de la route en testant les liens. Mais dans l'autre sens, si c'est juste une
Non ce n'est pas ça, le test des liens permet juste de s'assurer que ceux-ci fonctionnent, indépendamment de la route préférée.
dégradation et pas une coupure franche, les CPE se voient toujours connectés, non ? Dans ce cas, comment peut-on garantir que les paquets prennent le bon chemin et pas la liaison dégradée dans le sens CPE-backbone ?
Les réglages de sensibilité PPP (fréquence des echo LCP par exemple) permettent de faire tomber une session sur une ligne qui ne fonctionne pas bien. Et les CPE sont configurés pour diminuer leur priorité VRRP si leur ligne tombe.
Maintenant s'il y a juste 2 % de pertes de paquets sur le lien primaire, ça ne basculera pas, et c'est là qu'intervient également la supervision pour le détecter, et indiquer au support qu'il faut vérifier ce qu'il se passe sur la ligne pour éventuellement ouvrir un incident.
-- Raphael Bouaziz.
Le Sun, 20 Sep 2009 23:23:33 +0200, GuiGui a écrit
dans le message <4ab69d55$0$8789$426a34cc@news.free.fr> :
Ok, donc pour le sens backbone -> CPE vous décidez de la route en
testant les liens. Mais dans l'autre sens, si c'est juste une
Non ce n'est pas ça, le test des liens permet juste de s'assurer
que ceux-ci fonctionnent, indépendamment de la route préférée.
dégradation et pas une coupure franche, les CPE se voient toujours
connectés, non ? Dans ce cas, comment peut-on garantir que les paquets
prennent le bon chemin et pas la liaison dégradée dans le sens
CPE-backbone ?
Les réglages de sensibilité PPP (fréquence des echo LCP par exemple)
permettent de faire tomber une session sur une ligne qui ne fonctionne
pas bien. Et les CPE sont configurés pour diminuer leur priorité VRRP
si leur ligne tombe.
Maintenant s'il y a juste 2 % de pertes de paquets sur le lien primaire,
ça ne basculera pas, et c'est là qu'intervient également la supervision
pour le détecter, et indiquer au support qu'il faut vérifier ce qu'il se
passe sur la ligne pour éventuellement ouvrir un incident.
Le Sun, 20 Sep 2009 23:23:33 +0200, GuiGui a écrit dans le message <4ab69d55$0$8789$ :
Ok, donc pour le sens backbone -> CPE vous décidez de la route en testant les liens. Mais dans l'autre sens, si c'est juste une
Non ce n'est pas ça, le test des liens permet juste de s'assurer que ceux-ci fonctionnent, indépendamment de la route préférée.
dégradation et pas une coupure franche, les CPE se voient toujours connectés, non ? Dans ce cas, comment peut-on garantir que les paquets prennent le bon chemin et pas la liaison dégradée dans le sens CPE-backbone ?
Les réglages de sensibilité PPP (fréquence des echo LCP par exemple) permettent de faire tomber une session sur une ligne qui ne fonctionne pas bien. Et les CPE sont configurés pour diminuer leur priorité VRRP si leur ligne tombe.
Maintenant s'il y a juste 2 % de pertes de paquets sur le lien primaire, ça ne basculera pas, et c'est là qu'intervient également la supervision pour le détecter, et indiquer au support qu'il faut vérifier ce qu'il se passe sur la ligne pour éventuellement ouvrir un incident.
-- Raphael Bouaziz.
GuiGui
Raphael Bouaziz a écrit :
Le Sun, 20 Sep 2009 23:23:33 +0200, GuiGui a écrit dans le message <4ab69d55$0$8789$ :
Ok, donc pour le sens backbone -> CPE vous décidez de la route en testant les liens. Mais dans l'autre sens, si c'est juste une
Non ce n'est pas ça, le test des liens permet juste de s'assurer que ceux-ci fonctionnent, indépendamment de la route préférée.
dégradation et pas une coupure franche, les CPE se voient toujours connectés, non ? Dans ce cas, comment peut-on garantir que les paquets prennent le bon chemin et pas la liaison dégradée dans le sens CPE-backbone ?
Les réglages de sensibilité PPP (fréquence des echo LCP par exemple) permettent de faire tomber une session sur une ligne qui ne fonctionne pas bien. Et les CPE sont configurés pour diminuer leur priorité VRRP si leur ligne tombe.
Maintenant s'il y a juste 2 % de pertes de paquets sur le lien primaire, ça ne basculera pas, et c'est là qu'intervient également la supervision pour le détecter, et indiquer au support qu'il faut vérifier ce qu'il se passe sur la ligne pour éventuellement ouvrir un incident.
Merci pour les précisions.
Raphael Bouaziz a écrit :
Le Sun, 20 Sep 2009 23:23:33 +0200, GuiGui a écrit
dans le message <4ab69d55$0$8789$426a34cc@news.free.fr> :
Ok, donc pour le sens backbone -> CPE vous décidez de la route en
testant les liens. Mais dans l'autre sens, si c'est juste une
Non ce n'est pas ça, le test des liens permet juste de s'assurer
que ceux-ci fonctionnent, indépendamment de la route préférée.
dégradation et pas une coupure franche, les CPE se voient toujours
connectés, non ? Dans ce cas, comment peut-on garantir que les paquets
prennent le bon chemin et pas la liaison dégradée dans le sens
CPE-backbone ?
Les réglages de sensibilité PPP (fréquence des echo LCP par exemple)
permettent de faire tomber une session sur une ligne qui ne fonctionne
pas bien. Et les CPE sont configurés pour diminuer leur priorité VRRP
si leur ligne tombe.
Maintenant s'il y a juste 2 % de pertes de paquets sur le lien primaire,
ça ne basculera pas, et c'est là qu'intervient également la supervision
pour le détecter, et indiquer au support qu'il faut vérifier ce qu'il se
passe sur la ligne pour éventuellement ouvrir un incident.
Le Sun, 20 Sep 2009 23:23:33 +0200, GuiGui a écrit dans le message <4ab69d55$0$8789$ :
Ok, donc pour le sens backbone -> CPE vous décidez de la route en testant les liens. Mais dans l'autre sens, si c'est juste une
Non ce n'est pas ça, le test des liens permet juste de s'assurer que ceux-ci fonctionnent, indépendamment de la route préférée.
dégradation et pas une coupure franche, les CPE se voient toujours connectés, non ? Dans ce cas, comment peut-on garantir que les paquets prennent le bon chemin et pas la liaison dégradée dans le sens CPE-backbone ?
Les réglages de sensibilité PPP (fréquence des echo LCP par exemple) permettent de faire tomber une session sur une ligne qui ne fonctionne pas bien. Et les CPE sont configurés pour diminuer leur priorité VRRP si leur ligne tombe.
Maintenant s'il y a juste 2 % de pertes de paquets sur le lien primaire, ça ne basculera pas, et c'est là qu'intervient également la supervision pour le détecter, et indiquer au support qu'il faut vérifier ce qu'il se passe sur la ligne pour éventuellement ouvrir un incident.
Merci pour les précisions.
Analogue
On 18 sep, 16:50, Raphael Bouaziz wrote:
Pour ce qui s'appellait l'offre "Trust", les difficultés de constructio n 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 raisonnab le.
Nous étions intéressés par l'offre Nerim Trust, mais la lecture de ce fil nous a un peu refroidi.
Penses-tu vraiment abandonner l'offre Nerim Trust ? Cette possible offre "ADSL à GTR" sera-t-elle bientôt disponible ? Sera-t-il possible de l'appliquer sur un abonnement ADSL Nerim existant ?
Nous avons actuellement un ADSL Free + Fibre numéricable et nous étudions soit Nerim Trust, soit juste remplacer la fibre Numéricable par un ADSL Nerim et switcher à la main en cas de panne d'un des liens ADSL.
Merci pour ton aide ! =)
On 18 sep, 16:50, Raphael Bouaziz <boua...@nerim.net> wrote:
Pour ce qui s'appellait l'offre "Trust", les difficultés de constructio n
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 raisonnab le.
Nous étions intéressés par l'offre Nerim Trust, mais la lecture de ce
fil nous a un peu refroidi.
Penses-tu vraiment abandonner l'offre Nerim Trust ?
Cette possible offre "ADSL à GTR" sera-t-elle bientôt disponible ?
Sera-t-il possible de l'appliquer sur un abonnement ADSL Nerim
existant ?
Nous avons actuellement un ADSL Free + Fibre numéricable et nous
étudions soit Nerim Trust, soit juste remplacer la fibre Numéricable
par un ADSL Nerim et switcher à la main en cas de panne d'un des liens
ADSL.
Pour ce qui s'appellait l'offre "Trust", les difficultés de constructio n 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 raisonnab le.
Nous étions intéressés par l'offre Nerim Trust, mais la lecture de ce fil nous a un peu refroidi.
Penses-tu vraiment abandonner l'offre Nerim Trust ? Cette possible offre "ADSL à GTR" sera-t-elle bientôt disponible ? Sera-t-il possible de l'appliquer sur un abonnement ADSL Nerim existant ?
Nous avons actuellement un ADSL Free + Fibre numéricable et nous étudions soit Nerim Trust, soit juste remplacer la fibre Numéricable par un ADSL Nerim et switcher à la main en cas de panne d'un des liens ADSL.
Merci pour ton aide ! =)
Raphael Bouaziz
Le Wed, 23 Sep 2009 02:35:12 -0700 (PDT), Analogue a écrit dans le message :
On 18 sep, 16:50, Raphael Bouaziz wrote: Penses-tu vraiment abandonner l'offre Nerim Trust ? Cette possible offre "ADSL à GTR" sera-t-elle bientôt disponible ?
Je ne sais pas pour l'instant.
Sera-t-il possible de l'appliquer sur un abonnement ADSL Nerim existant ?
Que ce soit un ADSL Nerim ou une ligne sans ADSL ou actuellement produite chez un autre fournisseur ne changera rien, donc en l'occurence, oui.
-- Raphael Bouaziz.
Le Wed, 23 Sep 2009 02:35:12 -0700 (PDT), Analogue a écrit
dans le message
<2fe73a58-c1c6-41a2-a20b-fc2ec1cd35c5@g1g2000vbr.googlegroups.com> :
On 18 sep, 16:50, Raphael Bouaziz <boua...@nerim.net> wrote:
Penses-tu vraiment abandonner l'offre Nerim Trust ?
Cette possible offre "ADSL à GTR" sera-t-elle bientôt disponible ?
Je ne sais pas pour l'instant.
Sera-t-il possible de l'appliquer sur un abonnement ADSL Nerim
existant ?
Que ce soit un ADSL Nerim ou une ligne sans ADSL ou actuellement
produite chez un autre fournisseur ne changera rien, donc en
l'occurence, oui.
Le Wed, 23 Sep 2009 02:35:12 -0700 (PDT), Analogue a écrit dans le message :
On 18 sep, 16:50, Raphael Bouaziz wrote: Penses-tu vraiment abandonner l'offre Nerim Trust ? Cette possible offre "ADSL à GTR" sera-t-elle bientôt disponible ?
Je ne sais pas pour l'instant.
Sera-t-il possible de l'appliquer sur un abonnement ADSL Nerim existant ?
Que ce soit un ADSL Nerim ou une ligne sans ADSL ou actuellement produite chez un autre fournisseur ne changera rien, donc en l'occurence, oui.
-- Raphael Bouaziz.
Clement Cavadore
Pascal Hambourg wrote
C'est-à-dire ? Le /29 n'était routé que sur un des deux liens ? Ce serait étonnant car l'utilité serait douteuse.
Ca serait même totalement inutile.
Ma boite fait le même genre de services, avec un fallback automatique entre une SDSL et une ADSL, ou deux ADSL, etc...
Techniquement, voici comment on l'a implémenté:
Pour le Lien 1 (actif) : - Côté LNS/NAS: une route vers un /29 (ou plus), avec une métrique de 10 - Côté CPE: Route par défaut standard - HSRP/VRRP: Master (avec un tracking de létat de l'interface WAN)
Pour le Lien 2 (passif): - Côté LNS/NAS: Une route vers le même /29, avec une métrique de 100 - Côté CPE: Route par défaut standard - HSRP/VRRP: Slave
Lorsque le lien 1 tombe: - Côté LNS/NAS, la route disparait. Du coup, l'autre route vers le /29 devient prioritaire dans le backbone --> Trafic entrant rerouté sur le lien 2
- Côté CPE, le HSRP/VRRP bascule (parce que le lien 1 est tombé) --> Trafic sortant passant par l'autre routeur
Evidemment, derriere cette archi, il faut mettre un autre routeur (ethernet vers ethernet), qui fera du NAT & compagnie...
On peut aussi faire (c'est ce qui nous est le plus souvent demandé) une solution "mono-routeur" (sans VRRP/HSRP), avec deux routes par défaut et une métrique plus forte pour le lien passif. La probabilité pour qu'un routeur croute est moins forte que celle d'une ligne coupée, et c'est un risque que les clients acceptent de courir, généralement.
-- Clément Cavadore
Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> wrote
C'est-à-dire ? Le /29 n'était routé que sur un des deux liens ? Ce
serait étonnant car l'utilité serait douteuse.
Ca serait même totalement inutile.
Ma boite fait le même genre de services, avec un fallback automatique
entre une SDSL et une ADSL, ou deux ADSL, etc...
Techniquement, voici comment on l'a implémenté:
Pour le Lien 1 (actif) :
- Côté LNS/NAS: une route vers un /29 (ou plus), avec une métrique de 10
- Côté CPE: Route par défaut standard
- HSRP/VRRP: Master (avec un tracking de létat de l'interface WAN)
Pour le Lien 2 (passif):
- Côté LNS/NAS: Une route vers le même /29, avec une métrique de 100
- Côté CPE: Route par défaut standard
- HSRP/VRRP: Slave
Lorsque le lien 1 tombe:
- Côté LNS/NAS, la route disparait. Du coup, l'autre route vers le /29
devient prioritaire dans le backbone
--> Trafic entrant rerouté sur le lien 2
- Côté CPE, le HSRP/VRRP bascule (parce que le lien 1 est tombé)
--> Trafic sortant passant par l'autre routeur
Evidemment, derriere cette archi, il faut mettre un autre routeur
(ethernet vers ethernet), qui fera du NAT & compagnie...
On peut aussi faire (c'est ce qui nous est le plus souvent demandé) une
solution "mono-routeur" (sans VRRP/HSRP), avec deux routes par défaut
et une métrique plus forte pour le lien passif. La probabilité pour qu'un
routeur croute est moins forte que celle d'une ligne coupée, et c'est un
risque que les clients acceptent de courir, généralement.
C'est-à-dire ? Le /29 n'était routé que sur un des deux liens ? Ce serait étonnant car l'utilité serait douteuse.
Ca serait même totalement inutile.
Ma boite fait le même genre de services, avec un fallback automatique entre une SDSL et une ADSL, ou deux ADSL, etc...
Techniquement, voici comment on l'a implémenté:
Pour le Lien 1 (actif) : - Côté LNS/NAS: une route vers un /29 (ou plus), avec une métrique de 10 - Côté CPE: Route par défaut standard - HSRP/VRRP: Master (avec un tracking de létat de l'interface WAN)
Pour le Lien 2 (passif): - Côté LNS/NAS: Une route vers le même /29, avec une métrique de 100 - Côté CPE: Route par défaut standard - HSRP/VRRP: Slave
Lorsque le lien 1 tombe: - Côté LNS/NAS, la route disparait. Du coup, l'autre route vers le /29 devient prioritaire dans le backbone --> Trafic entrant rerouté sur le lien 2
- Côté CPE, le HSRP/VRRP bascule (parce que le lien 1 est tombé) --> Trafic sortant passant par l'autre routeur
Evidemment, derriere cette archi, il faut mettre un autre routeur (ethernet vers ethernet), qui fera du NAT & compagnie...
On peut aussi faire (c'est ce qui nous est le plus souvent demandé) une solution "mono-routeur" (sans VRRP/HSRP), avec deux routes par défaut et une métrique plus forte pour le lien passif. La probabilité pour qu'un routeur croute est moins forte que celle d'une ligne coupée, et c'est un risque que les clients acceptent de courir, généralement.
