Re: [FRnOG] [TECH] Projet client Anycast et Anycast HealthChecker

2022-11-25 Par sujet David Ponzone 


> Le 25 nov. 2022 à 09:36, Dominique Rousseau  a écrit :
> 
> 
> Là où ça va commencer à coincer, c'est si tu cumules la panne
> applicative sur un site, avec la coupure du lien inter-DC.
> Dans ce cas, oui, des connexions seront orientées vers le site "HS",
> puisque le supernet sera toujours annoncé, mais elles ne pourront plus
> aboutir, puisqu'il n'aura plus de /32 de destination à joindre.
> 

Ok, on est parfaitement d’accord.
Mais la grande règle dans ce métier, c’est que le cumul, ça arrive et 
généralement quand ça nous arrange le moins.

Axiome: si tu as pas connu un cumul d’emmerdes dans le métier, c’est que tu as 
commencé il y a moins d’un an.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Projet client Anycast et Anycast HealthChecker

2022-11-25 Par sujet Dominique Rousseau 
Le Thu, Nov 24, 2022 at 06:09:52PM +0100, David Ponzone 
[david.ponz...@gmail.com] a écrit:
> Ben non, on vient pas de dire qu???on avait besoin du lien inter-DC
> pour que le /32 soit accessible, même si on arrive par le mauvais site
> (celui sur lequel est est HS ou en mauvais état) ?
> 

Vu de l'extérieur, c'est un /24 ( ou plus gros ) qui est annoncé à un ou
plusieurs opérateurs, sur chaque site.
Un client arrive par l'opérateur que son FAI a choisi, le routeur qui
reçoit la demande oriente vers le /32 qu'il trouve le plus pratique, a
priori, celui qu'il a directement localement.
La redondance ( actif/actif de ce que j'ai compris dans la demande
initiale, mais je me trompe peut-etre)) entre les 2 sites se fait par le
lien interne entre les 2 DC, pour le cas où l'un des services ne répond
plus ( et le /32 cesse d'etre annoncé ).

Si l'application hébergée supporte que les 2 sites ne se parlent pas
pendant une panne ( contenu répliqué, pas d'états à synchroniser, bases
de données autonomes, etc. ), la situation vu de l'extérieur reste la
meme, tant que les 2 instances applicatives répondent.

Là où ça va commencer à coincer, c'est si tu cumules la panne
applicative sur un site, avec la coupure du lien inter-DC.
Dans ce cas, oui, des connexions seront orientées vers le site "HS",
puisque le supernet sera toujours annoncé, mais elles ne pourront plus
aboutir, puisqu'il n'aura plus de /32 de destination à joindre.

Et pour ça, comme dit dans d'autres posts, ben faut sécuriser le lien
inter-DC ( tunnel ip par dessus les 2 accès internet, 2e chemin de lien
inter-DC, etc. ).
Et si l'applicatif a besoin que les 2 instances restent en
communication, c'est de tout façon nécessaire :)


-- 
Dominique Rousseau 
Neuronnexion, Prestataire Internet & Intranet
6 rue des Hautes cornes - 8 Amiens
tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Projet client Anycast et Anycast HealthChecker

2022-11-24 Par sujet Bill Woodcock 
Il ne faut pas non plus oublier que si vous permettez à chaque site de prendre 
une décision indépendamment, il est possible qu'ils décident en même temps que 
les performances sont mauvaises et qu'ils mettent les deux instances hors 
service, ce qui serait pire que d'avoir un service peu performant.  Ceci est 
facile à contrôler dans un déploiement anycast d'un nombre fixe de nœuds 
connus, mais difficile à contrôler dans une implémentation générique qui 
consiste en un nombre arbitraire de nœuds à des adresses unicast inconnues.

Notez également que tout ceci est infiniment plus facile lorsque vous utilisez 
la meilleure pratique établie depuis le milieu des années 1990, qui consiste à 
attacher l'adresse du service anycast à l'interface de bouclage plutôt qu'à 
l'interface physique.

-Bill


signature.asc
Description: Message signed with OpenPGP

Re: [FRnOG] [TECH] Projet client Anycast et Anycast HealthChecker

2022-11-24 Par sujet Bill Woodcock 
> Anycast-HealthChecker fait un test de vie sur le service, si le service ne
> répond pas, il informe le service Bird que l'adresse IP du service (donc
> un /32) ne doit plus être routé et Bird va mettre à jour le routage du
> routeur client.

Oui, c'est comme ça que ça se passe normalement. Commencez à la diapositive 13 :

https://www.pch.net/resources/Papers/anycast/Anycast-v07.pdf

…et ici, à partir de la diapositive 30 :

https://www.pch.net/resources/Papers/dns-service-architecture/dns-service-architecture-v11.pdf

> - sur la faisabilité : j'ai un doute sur le reroutage d'un /32 au delà du
> réseau client ?

Correct.  Il est peu probable que quelque chose de plus spécifique qu'un /24 
d'IPv4 soit acheminé via eBGP ou propagé par les réseaux externes.  
Heureusement, nous sommes des adultes ici, et nous utilisons IPv6, qui n'est 
pas rare.

>- ça se fait d'utiliser un script python pour gérer le routage des
> coeurs de réseau ?

Absolument.

>- l'utilisation de l'anycast est-il conçu pour un basculement unitaire
> de services ?

Je l'utilise de cette façon depuis près de trente-cinq ans, et je le pense.

-Bill




signature.asc
Description: Message signed with OpenPGP

Re: [FRnOG] [TECH] Projet client Anycast et Anycast HealthChecker

2022-11-24 Par sujet David Ponzone 


> Le 24 nov. 2022 à 18:52, Raphael Mazelier  a écrit :
> 
> 
> On 24/11/2022 18:09, David Ponzone wrote:
>> Ben non, on vient pas de dire qu’on avait besoin du lien inter-DC pour que 
>> le /32 soit accessible, même si on arrive par le mauvais site (celui sur 
>> lequel est est HS ou en mauvais état) ?
> Quoi qu'il arrive en réseau il faut que ton AS reste non disjoint d'une 
> manière ou d'une autre (enfin à part configuration très particulière). Donc 
> le split brain de DC n'est pas une option (quitte à passer over internet).

Euh c’est pas un peu le principe d’Anycast d’avoir un AS potentiellement 
disjoint qui annonce le même préfixe ?
Après, que le contenu servi par les différents sites soit le même, c’est un 
autre problème, ça peut être un mec qui fait le tour des sites tous les jours 
avec une bande LTO.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Projet client Anycast et Anycast HealthChecker

2022-11-24 Par sujet Raphael Mazelier 



On 24/11/2022 18:09, David Ponzone wrote:

Ben non, on vient pas de dire qu’on avait besoin du lien inter-DC pour que le 
/32 soit accessible, même si on arrive par le mauvais site (celui sur lequel 
est est HS ou en mauvais état) ?
Quoi qu'il arrive en réseau il faut que ton AS reste non disjoint d'une 
manière ou d'une autre (enfin à part configuration très particulière). 
Donc le split brain de DC n'est pas une option (quitte à passer over 
internet).

Ceci dit, on peut aussi se demander si le choix d’Anycast est judicieux.
Anycast pour moi, c’est quand on veut servir rapidement un grand nombre 
d’utilisateurs qui vont accéder autoBGPmagiquement au serveur le plus proche 
d’eux.

Anycast pour de la redondance pure en actif / passif c'est curieux en 
effet. Par contre pour annoncer des services (meme internes) au plus 
proche (et de manière redondé donc) c'est courant (exemple courant le 
dns, ou autre truc stateless).


--
Raphael Mazelier

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Projet client Anycast et Anycast HealthChecker

2022-11-24 Par sujet Paul Rolland (ポール・ロラン) 
Bonjour,

On Thu, 24 Nov 2022 17:02:26 +0100
Dominique Rousseau  wrote:

> Le Thu, Nov 24, 2022 at 03:44:31PM +0100, David Ponzone
> [david.ponz...@gmail.com] a écrit:
> > Je reviens sur la réponse que j???ai faite à Dominique.
> > 
> > En fait, si le site est coupé à 100%, il annoncera plus rien, donc ça
> > va. Mea culpa. Le problème c???est si le lien inter-DC est coupé.
> >   
> 
> Pour ça, ça dépend si les 2 instances de l'application hébergée ont
> besoin de se synchroniser via le lien en question.

Si tu as cette contrainte forte, tu securises un peu ton lien intersite,
quitte a le faire via un tunnel IP que tu fais passer via Internet. Il faut
juste qq IPs en plus hors de celles de l'Anycast ;)

Paul

PS : bon, sinon, tu peux faire avec un second lien bien propre entre les
sites, ca marche aussi :D


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Projet client Anycast et Anycast HealthChecker

2022-11-24 Par sujet David Ponzone 
Ben non, on vient pas de dire qu’on avait besoin du lien inter-DC pour que le 
/32 soit accessible, même si on arrive par le mauvais site (celui sur lequel 
est est HS ou en mauvais état) ?

Ceci dit, on peut aussi se demander si le choix d’Anycast est judicieux.
Anycast pour moi, c’est quand on veut servir rapidement un grand nombre 
d’utilisateurs qui vont accéder autoBGPmagiquement au serveur le plus proche 
d’eux.

> Le 24 nov. 2022 à 17:02, Dominique Rousseau  a écrit :
> 
> Le Thu, Nov 24, 2022 at 03:44:31PM +0100, David Ponzone 
> [david.ponz...@gmail.com] a écrit:
>> Je reviens sur la réponse que j???ai faite à Dominique.
>> 
>> En fait, si le site est coupé à 100%, il annoncera plus rien, donc ça va. 
>> Mea culpa.
>> Le problème c???est si le lien inter-DC est coupé.
>> 
> 
> Pour ça, ça dépend si les 2 instances de l'application hébergée ont
> besoin de se synchroniser via le lien en question.
> 
> Et ça, on ne le sait pas dans l'énoncé :-p
> 
> 
> -- 
> Dominique Rousseau 
> Neuronnexion, Prestataire Internet & Intranet
> 6 rue des Hautes cornes - 8 Amiens
> tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Projet client Anycast et Anycast HealthChecker

2022-11-24 Par sujet Dominique Rousseau 
Le Thu, Nov 24, 2022 at 03:44:31PM +0100, David Ponzone 
[david.ponz...@gmail.com] a écrit:
> Je reviens sur la réponse que j???ai faite à Dominique.
> 
> En fait, si le site est coupé à 100%, il annoncera plus rien, donc ça va. Mea 
> culpa.
> Le problème c???est si le lien inter-DC est coupé.
> 

Pour ça, ça dépend si les 2 instances de l'application hébergée ont
besoin de se synchroniser via le lien en question.

Et ça, on ne le sait pas dans l'énoncé :-p


-- 
Dominique Rousseau 
Neuronnexion, Prestataire Internet & Intranet
6 rue des Hautes cornes - 8 Amiens
tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Projet client Anycast et Anycast HealthChecker

2022-11-24 Par sujet David Ponzone 
Je reviens sur la réponse que j’ai faite à Dominique.

En fait, si le site est coupé à 100%, il annoncera plus rien, donc ça va. Mea 
culpa.
Le problème c’est si le lien inter-DC est coupé.

> Le 24 nov. 2022 à 15:31, r...@no-log.org a écrit :
> 
> Ah mais oui... bonne remarque... Donc si j'ai un flux qui arrive par le
> site 1, il pourrait très bien ressortir par le site 2 si le flux est routé
> en interne vers le site 2 en iBGP?
> 
> 
>> Le Thu, Nov 24, 2022 at 02:54:53PM +0100, r...@no-log.org
>> [r...@no-log.org] a écrit:
>> (...)
>>> La démo : on a un service qui tourne sur le site 1 et sur le site 2. On
>>> stoppe le service sur le site 1, AnyCast-HealthChecker détecte que le
>>> service ne répond plus, il envoie à Bird une suppression d'annonce en
>>> /32
>>> (c'était indiqué comme ça sur un de leur schéma...) et Bird propage au
>>> coeur de routage, en iBGP, sur le site 1 et site 2 et par la magie du
>>> réseau le flux est rerouté vers le site 2 !
>>> 
>>> La démo est chouette mais leur but c'est de maintenant propager la modif
>>> sur  les peers BGP opérateurs qui filtreront tout /32.
>>> 
>>> Il semble que l'équipe qui propose ça n'a pas forcément saisie qu'on ne
>>> bascule pas un service "unitairement" en anycast dès qu'on passe en
>>> eBGP.
>> 
>> Tant que tu as ton lien "Inter DC", ce qui est proposé fonctionnera
>> aussi pour l'extérieur.
>> 
>> En nominal, si une requete arrive par l'opérateur connecté sur "site N",
>> ton /32 est connu localement, ton routeur orientera la connexion vers
>> l'instance locale.
>> Si l'un des "hébergements" est coupé, le routeur connecté a l'exeterieur
>> sur ce site là connaitra la /32 via ton iBGP et orientera les connexions
>> vers l'autre site ( et la réponse sortira par le routeur local du site
>> ).
>> 
>> 
>> --
>> Dominique Rousseau
>> Neuronnexion, Prestataire Internet & Intranet
>> 6 rue des Hautes cornes - 8 Amiens
>> tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop
>> 
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>> 
> 
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Projet client Anycast et Anycast HealthChecker

2022-11-24 Par sujet Raphael Mazelier 



On 24/11/2022 15:31, r...@no-log.org wrote:

Ah mais oui... bonne remarque... Donc si j'ai un flux qui arrive par le
site 1, il pourrait très bien ressortir par le site 2 si le flux est routé
en interne vers le site 2 en iBGP?


Bien sur. BGP par lui meme n'assure aucune symétrie. A path (et autre 
critères de choix) équivalent ton flux va sortir au plus près.


--
Raphael Mazelier

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Projet client Anycast et Anycast HealthChecker

2022-11-24 Par sujet Dominique Rousseau 
Le Thu, Nov 24, 2022 at 03:07:13PM +0100, David Ponzone 
[david.ponz...@gmail.com] a écrit:
(...)
> > Tant que tu as ton lien "Inter DC", ce qui est proposé fonctionnera
> > aussi pour l'extérieur.
> > 
> > En nominal, si une requete arrive par l'opérateur connecté sur "site N",
> > ton /32 est connu localement, ton routeur orientera la connexion vers
> > l'instance locale.
> > Si l'un des "hébergements" est coupé, le routeur connecté a l'exeterieur
> > sur ce site là connaitra la /32 via ton iBGP et orientera les connexions
> > vers l'autre site ( et la réponse sortira par le routeur local du site
> > ).
> 
> 
> Et si c???est tout le site qui est HS ? :)
> C???est à priori une cause possible/probable pour que le service ne
> réponde pas.

Dans ce cas le supernet dont fait partie la /32 n'a pas de raison de
disparaitre du routeur de sortie du site qui marche encore.


-- 
Dominique Rousseau 
Neuronnexion, Prestataire Internet & Intranet
6 rue des Hautes cornes - 8 Amiens
tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Projet client Anycast et Anycast HealthChecker

2022-11-24 Par sujet raum 
Ah mais oui... bonne remarque... Donc si j'ai un flux qui arrive par le
site 1, il pourrait très bien ressortir par le site 2 si le flux est routé
en interne vers le site 2 en iBGP?


> Le Thu, Nov 24, 2022 at 02:54:53PM +0100, r...@no-log.org
> [r...@no-log.org] a écrit:
> (...)
>> La démo : on a un service qui tourne sur le site 1 et sur le site 2. On
>> stoppe le service sur le site 1, AnyCast-HealthChecker détecte que le
>> service ne répond plus, il envoie à Bird une suppression d'annonce en
>> /32
>> (c'était indiqué comme ça sur un de leur schéma...) et Bird propage au
>> coeur de routage, en iBGP, sur le site 1 et site 2 et par la magie du
>> réseau le flux est rerouté vers le site 2 !
>>
>> La démo est chouette mais leur but c'est de maintenant propager la modif
>> sur  les peers BGP opérateurs qui filtreront tout /32.
>>
>> Il semble que l'équipe qui propose ça n'a pas forcément saisie qu'on ne
>> bascule pas un service "unitairement" en anycast dès qu'on passe en
>> eBGP.
>
> Tant que tu as ton lien "Inter DC", ce qui est proposé fonctionnera
> aussi pour l'extérieur.
>
> En nominal, si une requete arrive par l'opérateur connecté sur "site N",
> ton /32 est connu localement, ton routeur orientera la connexion vers
> l'instance locale.
> Si l'un des "hébergements" est coupé, le routeur connecté a l'exeterieur
> sur ce site là connaitra la /32 via ton iBGP et orientera les connexions
> vers l'autre site ( et la réponse sortira par le routeur local du site
> ).
>
>
> --
> Dominique Rousseau
> Neuronnexion, Prestataire Internet & Intranet
> 6 rue des Hautes cornes - 8 Amiens
> tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Projet client Anycast et Anycast HealthChecker

2022-11-24 Par sujet Paul Rolland (ポール・ロラン) 
Hello,

On Thu, 24 Nov 2022 14:54:53 +0100
r...@no-log.org wrote:

> Ce que tu indiques sur la fiabilité du script est très pertinent, surtout
> sur les gardes fous à mettre en place, mais AMHA seulement dans le cas
> d'un reroutage d'un /24, pas d'un /32...

Non non, dans _tous_ les cas Best practice toussa toussa, si on
s'autorise des trucs pas propres "parce que ", ca finira par leaker sur
la prod ;)

De toute facon, je pense qu'un des questions a se poser, c'est comment sont
lies services et adresses IP... La, on parle d'_un_ service et d'_une_
adresse. Mais je suppose que sur un pop, tu as un ensemble de services qui
parlent entre eux, parlent a l'exterieur, etc... Du coup, ne faudrait-il
pas envisager, en cas de panne d'un service, de basculer tout le pop (et
donc toutes les adresses) et on revient a l'idee de basculer le /24 plutot
que du /32 (ce qui ne marchera de toute facon pas).
 
> Sinon je vais jeter un oeil sur ExaBGP ;)

C'est top, et si tu as des questions, n'hesites pas a demander, Thomas et
Vincent (qui doivent plus ou moins trainer par ici) pourront repondre a
toutes les questions.
Pour moi, ca juste marche, et ca permet de faire des tas de choses.

Paul


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Projet client Anycast et Anycast HealthChecker

2022-11-24 Par sujet David Ponzone 
> Le 24 nov. 2022 à 15:01, Dominique Rousseau  a écrit :
> 
> Le Thu, Nov 24, 2022 at 02:54:53PM +0100, r...@no-log.org [r...@no-log.org] a 
> écrit:
> (...)
>> La démo : on a un service qui tourne sur le site 1 et sur le site 2. On
>> stoppe le service sur le site 1, AnyCast-HealthChecker détecte que le
>> service ne répond plus, il envoie à Bird une suppression d'annonce en /32
>> (c'était indiqué comme ça sur un de leur schéma...) et Bird propage au
>> coeur de routage, en iBGP, sur le site 1 et site 2 et par la magie du
>> réseau le flux est rerouté vers le site 2 !
>> 
>> La démo est chouette mais leur but c'est de maintenant propager la modif
>> sur  les peers BGP opérateurs qui filtreront tout /32.
>> 
>> Il semble que l'équipe qui propose ça n'a pas forcément saisie qu'on ne
>> bascule pas un service "unitairement" en anycast dès qu'on passe en eBGP.
> 
> Tant que tu as ton lien "Inter DC", ce qui est proposé fonctionnera
> aussi pour l'extérieur.
> 
> En nominal, si une requete arrive par l'opérateur connecté sur "site N",
> ton /32 est connu localement, ton routeur orientera la connexion vers
> l'instance locale.
> Si l'un des "hébergements" est coupé, le routeur connecté a l'exeterieur
> sur ce site là connaitra la /32 via ton iBGP et orientera les connexions
> vers l'autre site ( et la réponse sortira par le routeur local du site
> ).


Et si c’est tout le site qui est HS ? :)
C’est à priori une cause possible/probable pour que le service ne réponde pas.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Projet client Anycast et Anycast HealthChecker

2022-11-24 Par sujet David Ponzone 
Pour un /32, la question ne se pose pas puisque l’annonce ne sera PAS propagée 
à tout Internet.
Pas de problème de dampening dans ce cas :)

Après, je connais pas les détails financiers du projet, mais un /24 ça s’achète 
environ 12k€, un /23 entre 20k€-25k€, c’est pas la fin du monde.

> Le 24 nov. 2022 à 14:54, r...@no-log.org a écrit :
> 
> Eh bien non, de ce que l'équipe de geek a présenté, ils pensent arrêter
> d'annoncer un /32, pas un /24. comme je ne suis pas expert mais que
> j'avais un gros doute, je me suis permis de venir poser la question ici :)
> 
> En interne, il y a toute la quincaillerie qui permet de faire fonctionner
> ça mais sur une interconnexion privée etre deux DC en iBGP.
> 
> La démo : on a un service qui tourne sur le site 1 et sur le site 2. On
> stoppe le service sur le site 1, AnyCast-HealthChecker détecte que le
> service ne répond plus, il envoie à Bird une suppression d'annonce en /32
> (c'était indiqué comme ça sur un de leur schéma...) et Bird propage au
> coeur de routage, en iBGP, sur le site 1 et site 2 et par la magie du
> réseau le flux est rerouté vers le site 2 !
> 
> La démo est chouette mais leur but c'est de maintenant propager la modif
> sur  les peers BGP opérateurs qui filtreront tout /32.
> 
> Il semble que l'équipe qui propose ça n'a pas forcément saisie qu'on ne
> bascule pas un service "unitairement" en anycast dès qu'on passe en eBGP.
> 
> (j'espère être clair mais si je me trompe dans la forme ou dans le fond,
> vous me corrigerez ;) )
> 
> Ce que tu indiques sur la fiabilité du script est très pertinent, surtout
> sur les gardes fous à mettre en place, mais AMHA seulement dans le cas
> d'un reroutage d'un /24, pas d'un /32...
> 
>> -le script doit être archi-blindax quant aux citères qu?il utilise pour
>> décider que le service n?est pas bon
>> -le script ne doit PAS avoir le droit de rétablir l?annonce BGP s?il l?a
>> retirée 1 min avant (dampening, tout ça??). Je dirais même qu?il ne doit
>> plus avoir le droit de ré-annoncer avant 15 ou 30 min
>> -mais comme les devs sont des humains et qu?ils vont foirer, c?est sûr, je
>> pense que le service doit tourner dans un /24 dont l?annonce est anycast,
>> mais qu?il devrait y avoir un préfixe plus court (/22 ou /23 donc) qui est
>> annoncé en permanence par un site seulement peut-être, dans l?éventualité
>> certaine que le /24 soit dampené massivement un jour
>> 
> 
> Bon je pense que je vais aller les voir pour être sûr qu'ils ont tous les
> éléments... ou alors j'ai raté un truc.
> 
> Sinon je vais jeter un oeil sur ExaBGP ;)
> 
> Encore merci
> 
>> 
>>> Le 24 nov. 2022 à 11:53, r...@no-log.org a écrit :
>>> 
>>> Hello David,
>>> 
>>> Merci pour ta réponse. Sur le principe du filtrage par prefix, je m'en
>>> doutais et du coup cela ne fonctionnera pas comme ils l'envisagent :-/
>>> 
>>> Par rapport au script python interconnecté à Bird pour faire les mises à
>>> jour de route sur des coeurs de réseau BGP qui sont, eux même,
>>> interconnectés à des opérateurs, je ne sais pas quoi penser de la
>>> fiabilité?
>> 
>> 
>> On parle bien de la même chose ?
>> 
>> Un script python, par la méthode de son choix, vérifie qu?un service sur
>> un POP du client répond mal.
>> Si le service répond mal, le script dit à Bird d?arrêter d?annoncer
>> X.X.X.X/24 au coeur de réseau de ce POP donc le /24 et n?est plus
>> redistribué pas aux transits/peerings.
>> Les clients qui étaient servis par ce POP se retrouvent donc acheminés
>> vers le prochain POP le plus « proche » (proche = AS-PATH le plus court).
>> 
>> Je ne vois pas de souci de fiabilité, SI (un grand SI):
>> -le script doit être archi-blindax quant aux critères qu?il utilise pour
>> décider que le service n?est pas bon
>> -le script ne doit PAS avoir le droit de rétablir l?annonce BGP s?il l?a
>> retirée 1 min avant (dampening, tout ça??). Je dirais même qu?il ne doit
>> plus avoir le droit de ré-annoncer avant 15 ou 30 min
>> -mais comme les devs sont des humains et qu?ils vont foirer, c?est sûr, je
>> pense que le service doit tourner dans un /24 dont l?annonce est anycast,
>> mais qu?il devrait y avoir un préfixe plus court (/22 ou /23 donc) qui est
>> annoncé en permanence par un site seulement peut-être, dans l?éventualité
>> certaine que le /24 soit dampené massivement un jour
>> 
>> 
>> 
>> 
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>> 
> 
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Projet client Anycast et Anycast HealthChecker

2022-11-24 Par sujet Pierre-Yves Kerembellec 
> Eh bien non, de ce que l'équipe de geek a présenté, ils pensent arrêter
> d'annoncer un /32, pas un /24. comme je ne suis pas expert mais que
> j'avais un gros doute, je me suis permis de venir poser la question ici :)
> 
> En interne, il y a toute la quincaillerie qui permet de faire fonctionner
> ça mais sur une interconnexion privée etre deux DC en iBGP.
> 
> La démo : on a un service qui tourne sur le site 1 et sur le site 2. On
> stoppe le service sur le site 1, AnyCast-HealthChecker détecte que le
> service ne répond plus, il envoie à Bird une suppression d'annonce en /32
> (c'était indiqué comme ça sur un de leur schéma...) et Bird propage au
> coeur de routage, en iBGP, sur le site 1 et site 2 et par la magie du
> réseau le flux est rerouté vers le site 2 !
> 
> La démo est chouette mais leur but c'est de maintenant propager la modif
> sur  les peers BGP opérateurs qui filtreront tout /32.
> 
> Il semble que l'équipe qui propose ça n'a pas forcément saisie qu'on ne
> bascule pas un service "unitairement" en anycast dès qu'on passe en eBGP.
> 
> (j'espère être clair mais si je me trompe dans la forme ou dans le fond,
> vous me corrigerez ;) )
> 
> Ce que tu indiques sur la fiabilité du script est très pertinent, surtout
> sur les gardes fous à mettre en place, mais AMHA seulement dans le cas
> d'un reroutage d'un /24, pas d'un /32...
> 
>> -le script doit être archi-blindax quant aux citères qu?il utilise pour
>> décider que le service n?est pas bon
>> -le script ne doit PAS avoir le droit de rétablir l?annonce BGP s?il l?a
>> retirée 1 min avant (dampening, tout ça??). Je dirais même qu?il ne doit
>> plus avoir le droit de ré-annoncer avant 15 ou 30 min
>> -mais comme les devs sont des humains et qu?ils vont foirer, c?est sûr, je
>> pense que le service doit tourner dans un /24 dont l?annonce est anycast,
>> mais qu?il devrait y avoir un préfixe plus court (/22 ou /23 donc) qui est
>> annoncé en permanence par un site seulement peut-être, dans l?éventualité
>> certaine que le /24 soit dampené massivement un jour
>> 
> 
> Bon je pense que je vais aller les voir pour être sûr qu'ils ont tous les
> éléments... ou alors j'ai raté un truc.
> 
> Sinon je vais jeter un oeil sur ExaBGP ;)

Si tu veux le même type de fonctionnalités avec la toolbox ExaBGP (sans BIRD & 
co donc),
tu peux jeter un œil à :

https://github.com/pyke369/exabgp-helpers/tree/master/exasrv 


pyke


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Projet client Anycast et Anycast HealthChecker

2022-11-24 Par sujet Dominique Rousseau 
Le Thu, Nov 24, 2022 at 02:54:53PM +0100, r...@no-log.org [r...@no-log.org] a 
écrit:
(...)
> La démo : on a un service qui tourne sur le site 1 et sur le site 2. On
> stoppe le service sur le site 1, AnyCast-HealthChecker détecte que le
> service ne répond plus, il envoie à Bird une suppression d'annonce en /32
> (c'était indiqué comme ça sur un de leur schéma...) et Bird propage au
> coeur de routage, en iBGP, sur le site 1 et site 2 et par la magie du
> réseau le flux est rerouté vers le site 2 !
> 
> La démo est chouette mais leur but c'est de maintenant propager la modif
> sur  les peers BGP opérateurs qui filtreront tout /32.
> 
> Il semble que l'équipe qui propose ça n'a pas forcément saisie qu'on ne
> bascule pas un service "unitairement" en anycast dès qu'on passe en eBGP.

Tant que tu as ton lien "Inter DC", ce qui est proposé fonctionnera
aussi pour l'extérieur.

En nominal, si une requete arrive par l'opérateur connecté sur "site N",
ton /32 est connu localement, ton routeur orientera la connexion vers
l'instance locale.
Si l'un des "hébergements" est coupé, le routeur connecté a l'exeterieur
sur ce site là connaitra la /32 via ton iBGP et orientera les connexions
vers l'autre site ( et la réponse sortira par le routeur local du site
).


-- 
Dominique Rousseau 
Neuronnexion, Prestataire Internet & Intranet
6 rue des Hautes cornes - 8 Amiens
tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Projet client Anycast et Anycast HealthChecker

2022-11-24 Par sujet raum 
Eh bien non, de ce que l'équipe de geek a présenté, ils pensent arrêter
d'annoncer un /32, pas un /24. comme je ne suis pas expert mais que
j'avais un gros doute, je me suis permis de venir poser la question ici :)

En interne, il y a toute la quincaillerie qui permet de faire fonctionner
ça mais sur une interconnexion privée etre deux DC en iBGP.

La démo : on a un service qui tourne sur le site 1 et sur le site 2. On
stoppe le service sur le site 1, AnyCast-HealthChecker détecte que le
service ne répond plus, il envoie à Bird une suppression d'annonce en /32
(c'était indiqué comme ça sur un de leur schéma...) et Bird propage au
coeur de routage, en iBGP, sur le site 1 et site 2 et par la magie du
réseau le flux est rerouté vers le site 2 !

La démo est chouette mais leur but c'est de maintenant propager la modif
sur  les peers BGP opérateurs qui filtreront tout /32.

Il semble que l'équipe qui propose ça n'a pas forcément saisie qu'on ne
bascule pas un service "unitairement" en anycast dès qu'on passe en eBGP.

(j'espère être clair mais si je me trompe dans la forme ou dans le fond,
vous me corrigerez ;) )

Ce que tu indiques sur la fiabilité du script est très pertinent, surtout
sur les gardes fous à mettre en place, mais AMHA seulement dans le cas
d'un reroutage d'un /24, pas d'un /32...

> -le script doit être archi-blindax quant aux citères qu?il utilise pour
> décider que le service n?est pas bon
> -le script ne doit PAS avoir le droit de rétablir l?annonce BGP s?il l?a
> retirée 1 min avant (dampening, tout ça??). Je dirais même qu?il ne doit
> plus avoir le droit de ré-annoncer avant 15 ou 30 min
> -mais comme les devs sont des humains et qu?ils vont foirer, c?est sûr, je
> pense que le service doit tourner dans un /24 dont l?annonce est anycast,
> mais qu?il devrait y avoir un préfixe plus court (/22 ou /23 donc) qui est
> annoncé en permanence par un site seulement peut-être, dans l?éventualité
> certaine que le /24 soit dampené massivement un jour
>

Bon je pense que je vais aller les voir pour être sûr qu'ils ont tous les
éléments... ou alors j'ai raté un truc.

Sinon je vais jeter un oeil sur ExaBGP ;)

Encore merci

>
>> Le 24 nov. 2022 à 11:53, r...@no-log.org a écrit :
>>
>> Hello David,
>>
>> Merci pour ta réponse. Sur le principe du filtrage par prefix, je m'en
>> doutais et du coup cela ne fonctionnera pas comme ils l'envisagent :-/
>>
>> Par rapport au script python interconnecté à Bird pour faire les mises à
>> jour de route sur des coeurs de réseau BGP qui sont, eux même,
>> interconnectés à des opérateurs, je ne sais pas quoi penser de la
>> fiabilité?
>
>
> On parle bien de la même chose ?
>
> Un script python, par la méthode de son choix, vérifie qu?un service sur
> un POP du client répond mal.
> Si le service répond mal, le script dit à Bird d?arrêter d?annoncer
> X.X.X.X/24 au coeur de réseau de ce POP donc le /24 et n?est plus
> redistribué pas aux transits/peerings.
> Les clients qui étaient servis par ce POP se retrouvent donc acheminés
> vers le prochain POP le plus « proche » (proche = AS-PATH le plus court).
>
> Je ne vois pas de souci de fiabilité, SI (un grand SI):
> -le script doit être archi-blindax quant aux critères qu?il utilise pour
> décider que le service n?est pas bon
> -le script ne doit PAS avoir le droit de rétablir l?annonce BGP s?il l?a
> retirée 1 min avant (dampening, tout ça??). Je dirais même qu?il ne doit
> plus avoir le droit de ré-annoncer avant 15 ou 30 min
> -mais comme les devs sont des humains et qu?ils vont foirer, c?est sûr, je
> pense que le service doit tourner dans un /24 dont l?annonce est anycast,
> mais qu?il devrait y avoir un préfixe plus court (/22 ou /23 donc) qui est
> annoncé en permanence par un site seulement peut-être, dans l?éventualité
> certaine que le /24 soit dampené massivement un jour
>
>
>
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Projet client Anycast et Anycast HealthChecker

2022-11-24 Par sujet David Ponzone 


> Le 24 nov. 2022 à 11:53, r...@no-log.org a écrit :
> 
> Hello David,
> 
> Merci pour ta réponse. Sur le principe du filtrage par prefix, je m'en
> doutais et du coup cela ne fonctionnera pas comme ils l'envisagent :-/
> 
> Par rapport au script python interconnecté à Bird pour faire les mises à
> jour de route sur des coeurs de réseau BGP qui sont, eux même,
> interconnectés à des opérateurs, je ne sais pas quoi penser de la
> fiabilité…


On parle bien de la même chose ?

Un script python, par la méthode de son choix, vérifie qu’un service sur un POP 
du client répond mal.
Si le service répond mal, le script dit à Bird d’arrêter d’annoncer X.X.X.X/24 
au coeur de réseau de ce POP donc le /24 et n’est plus redistribué pas aux 
transits/peerings.
Les clients qui étaient servis par ce POP se retrouvent donc acheminés vers le 
prochain POP le plus « proche » (proche = AS-PATH le plus court).

Je ne vois pas de souci de fiabilité, SI (un grand SI):
-le script doit être archi-blindax quant aux critères qu’il utilise pour 
décider que le service n’est pas bon
-le script ne doit PAS avoir le droit de rétablir l’annonce BGP s’il l’a 
retirée 1 min avant (dampening, tout ça……). Je dirais même qu’il ne doit plus 
avoir le droit de ré-annoncer avant 15 ou 30 min
-mais comme les devs sont des humains et qu’ils vont foirer, c’est sûr, je 
pense que le service doit tourner dans un /24 dont l’annonce est anycast, mais 
qu’il devrait y avoir un préfixe plus court (/22 ou /23 donc) qui est annoncé 
en permanence par un site seulement peut-être, dans l’éventualité certaine que 
le /24 soit dampené massivement un jour





---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Projet client Anycast et Anycast HealthChecker

2022-11-24 Par sujet Dominique Rousseau 
Le Thu, Nov 24, 2022 at 11:05:09AM +0100, r...@no-log.org [r...@no-log.org] a 
écrit:
(...)
> 
> Anycast-HealthChecker fait un test de vie sur le service, si le service ne
> répond pas, il informe le service Bird que l'adresse IP du service (donc
> un /32) ne doit plus être routé et Bird va mettre à jour le routage du
> routeur client. La démo entre DCs Client est sympa et les flux inter-DCs
> basculent bien et en moins de 20s, mais on est en iBGP...
> 
> A la cible le routeur client doit propager les modifications de routage au
> peer opérateur et là j'ai des questions
> - sur la faisabilité : j'ai un doute sur le reroutage d'un /32 au delà du
> réseau client ?

Au delà du réseau du client, ça doit pouvoir aller jusqu'aux
l'opérateurs auxquels il est connecté.
Mais eux ne le propageront pas plus loin.
Donc ça pourrait probablement se faire si il a le meme opérateur
upstream sur 2 sites, mais pas entre 2 opérateurs différents.

> - sur le fond, j'ai mon idée mais :
> - ça se fait d'utiliser un script python pour gérer le routage des
> coeurs de réseau ?

Oui :)
Je connais pas du tout celui que tu cites, mais ExaBGP, qui est en
service BGP en Python sait faire la meme chose que ce que tu décris.
( il fait le BGP lui meme, pas de tiers comme Bird pour ta solution )

Préseantion d'ExaBGP au FRNOG 26 : https://www.dailymotion.com/video/x4jlobg

> - l'utilisation de l'anycast est-il conçu pour un basculement unitaire
> de services ?

En "intra" du réseau de ton client, oui.
Mais si tu espères que ça soit propagé à l'extérieur, point de salut en
dessous d'une annonce /24 comme indiqué par David.


-- 
Dominique Rousseau 
Neuronnexion, Prestataire Internet & Intranet
6 rue des Hautes cornes - 8 Amiens
tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Projet client Anycast et Anycast HealthChecker

2022-11-24 Par sujet raum 
Hello David,

Merci pour ta réponse. Sur le principe du filtrage par prefix, je m'en
doutais et du coup cela ne fonctionnera pas comme ils l'envisagent :-/

Par rapport au script python interconnecté à Bird pour faire les mises à
jour de route sur des coeurs de réseau BGP qui sont, eux même,
interconnectés à des opérateurs, je ne sais pas quoi penser de la
fiabilité...

Cela me donne des éléments de réflexions... Encore merci

>
>> Le 24 nov. 2022 à 11:05, r...@no-log.org a écrit :
>>
>> Bonjour à toutes et tous,
>>
>> A la cible le routeur client doit propager les modifications de routage
>> au
>> peer opérateur et là j'ai des questions
>> - sur la faisabilité : j'ai un doute sur le reroutage d'un /32 au delà
>> du
>> réseau client ?
>
> Non, /24 au moins.
> Un préfixe plus long sera filtré par presque tout le monde.
>
>> - sur le fond, j'ai mon idée mais :
>>- ça se fait d'utiliser un script python pour gérer le routage des
>> coeurs de réseau ?
>
> Oh oui ça doit se faire.
> Ils ont appelé ça du SDN (après tu peux remplacer Python par C++?.).
>
>>- l'utilisation de l'anycast est-il conçu pour un basculement
>> unitaire
>> de services ?
>
> Dans la mesure où tu peux sacrifier un /24 par service?
>
>
>



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Projet client Anycast et Anycast HealthChecker

2022-11-24 Par sujet David Ponzone 


> Le 24 nov. 2022 à 11:05, r...@no-log.org a écrit :
> 
> Bonjour à toutes et tous,
> 
> A la cible le routeur client doit propager les modifications de routage au
> peer opérateur et là j'ai des questions
> - sur la faisabilité : j'ai un doute sur le reroutage d'un /32 au delà du
> réseau client ?

Non, /24 au moins.
Un préfixe plus long sera filtré par presque tout le monde.

> - sur le fond, j'ai mon idée mais :
>- ça se fait d'utiliser un script python pour gérer le routage des
> coeurs de réseau ?

Oh oui ça doit se faire.
Ils ont appelé ça du SDN (après tu peux remplacer Python par C++….).

>- l'utilisation de l'anycast est-il conçu pour un basculement unitaire
> de services ?

Dans la mesure où tu peux sacrifier un /24 par service…



---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [TECH] Projet client Anycast et Anycast HealthChecker

2022-11-24 Par sujet raum 
Bonjour à toutes et tous,

J'ai besoin d'un avis sur un projet mené par une équipe (une bande de geek
:)) chez un client ils veulent mettre en oeuvre l'outil suivant :
https://github.com/unixsurfer/anycast_healthchecker. Je commence par
m'excuser mais je ne suis pas expert en routage BGP et je n'ai peut être
pas le bon vocabulaire...

L'idée est d'augmenter la résilience de l'accès à un service accessible
depuis l'internet en utilisant un routage anycast. Pour plus de précisions
ça ressemblerait à ça (j'espère que le schéma va passer...) :

+--+
|  |
|  +---+   |+---+
|  |service|<-- |  Utilisateur  |
|  +---^---+   |+---+
|  |   |
|   +--+--+ +--+ ++|   
+-+
|   |HealthChecker+>| Bird +>|BGP Peer+--eBGP-->| BGP Peer
(opérateur)|
|   +-+ +--+iBGP ++|   
+-+
|  |
|  |
|DC Client |
+--+

Anycast-HealthChecker fait un test de vie sur le service, si le service ne
répond pas, il informe le service Bird que l'adresse IP du service (donc
un /32) ne doit plus être routé et Bird va mettre à jour le routage du
routeur client. La démo entre DCs Client est sympa et les flux inter-DCs
basculent bien et en moins de 20s, mais on est en iBGP...

A la cible le routeur client doit propager les modifications de routage au
peer opérateur et là j'ai des questions
- sur la faisabilité : j'ai un doute sur le reroutage d'un /32 au delà du
réseau client ?
- sur le fond, j'ai mon idée mais :
- ça se fait d'utiliser un script python pour gérer le routage des
coeurs de réseau ?
- l'utilisation de l'anycast est-il conçu pour un basculement unitaire
de services ?

Avez-vous un avis ? des remarques ?

En vous remerciant :)

Bonne journée !




---
Liste de diffusion du FRnOG
http://www.frnog.org/