Cela représente une étape importante, issue de trois années de préparation, et s’inscrit dans une stratégie plus large visant à conserver un contrôle complet sur l’infrastructure réseau de notre région Paris.
Pourquoi ce changement
Aux débuts de Clever Cloud, nous avons délégué la gestion du réseau à des partenaires. Ce choix était logique : il nous permettait d’accélérer le développement, de nous concentrer sur les services cloud, et d’éviter d’investir immédiatement dans une expertise que nous ne maîtrisions pas encore.
Mais à mesure que notre infrastructure a grandi, les limites de cette dépendance sont devenues évidentes. Nous n’avions aucun contrôle sur des décisions stratégiques : la manière dont le trafic était routé sur Internet, les chemins empruntés par nos paquets, ou la rapidité avec laquelle nous pouvions réagir aux incidents. Chaque modification, chaque incident nécessitait l’intervention d’un tiers.
Nous avons donc décidé de reprendre cette responsabilité. Cela nous a permis d’obtenir plusieurs avantages concrets. Nous optimisons les coûts grâce à la gestion directe de nos relations de transit et de peering. Nous définissons notre propre politique de routage au lieu de subir les contraintes d’un intermédiaire. Nous résolvons les incidents nous-mêmes, sans dépendre de fournisseurs externes. Et nous obtenons un contrôle complet de notre stack réseau — dans la continuité du contrôle que nous avons progressivement acquis sur nos serveurs et nos datacenters au cours des dernières années.
Mais cette transition ne concerne pas uniquement notre indépendance opérationnelle. Elle apporte des bénéfices immédiats et concrets pour nos utilisateurs. Le plus important est la résilience. Auparavant, l’ensemble du trafic passait par un seul fournisseur. Tout incident de leur côté impactait l’ensemble des services. Nous disposons désormais de quatre fournisseurs upstream répartis sur trois datacenters en région parisienne. Lorsqu’un lien tombe — ce qui s’est produit au cours de l’année passée — le trafic bascule automatiquement vers les alternatives disponibles, sans interruption pour les utilisateurs. Nous pouvons même absorber la perte simultanée de plusieurs liens de transit.
Au-delà de la redondance, nous gagnons le contrôle du routage lui-même. Nous décidons désormais comment le trafic atteint sa destination. Cela nous permet d’optimiser les chemins pour réduire la latence et améliorer les performances, et d’ajuster ces décisions en fonction des besoins spécifiques et de la topologie réseau. Nous réagissons en temps réel à la congestion, aux variations du réseau et aux contraintes opérationnelles.
Enfin, la responsabilité opérationnelle change. Les incidents réseau ne nécessitent plus d’attendre qu’un fournisseur externe les prenne en charge. Les défaillances du réseau public relèvent directement de notre responsabilité : nous les détectons, les analysons et les corrigeons. Cela réduit directement le temps entre l’apparition d’un problème et sa résolution, ce qui améliore la disponibilité et la fiabilité pour nos utilisateurs.
Exploiter son propre réseau sur Internet
Pour opérer un réseau indépendant sur Internet, une organisation doit travailler avec un registre Internet régional (RIR). Les RIR sont responsables de l’attribution et de la gestion des adresses IP et des numéros d’AS dans des zones géographiques spécifiques.
Il existe cinq RIR dans le monde :
- RIPE NCC — Europe, Asie centrale et Moyen-Orient
- ARIN — Amérique du Nord (États-Unis, Canada, Caraïbes)
- LACNIC — Amérique latine et Caraïbes
- APNIC — région Asie-Pacifique
- AFRINIC — Afrique
Pour Clever Cloud, dont l’infrastructure est principalement en Europe, nous travaillons avec le RIPE NCC (Réseaux IP Européens).
Espace d’adressage alloué
En tant que membre d’un RIR, une organisation reçoit des allocations d’adresses IPv4 et IPv6. Pour les membres du RIPE NCC, cela correspond généralement à un bloc IPv4 en /24 (selon disponibilité) et un bloc IPv6 en /29. Ces ressources sont associées à l’organisation et peuvent être utilisées pour opérer un réseau à l’échelle globale.
Création de notre système autonome
Les bases de cette transition ont été posées plusieurs années auparavant. En 2019, nous avons créé notre compte RIPE NCC afin de devenir LIR (Local Internet Registry). Cela nous a permis d’obtenir un bloc IPv4 /24 (91.208.207.0/24) et un bloc IPv6 /29 (2a0f:d0c0::/29).
Puis, en 2022, nous avons enregistré notre numéro de système autonome (ASN) auprès du registre régional. Notre numéro d’AS est AS213394.
> whois AS213394
aut-num: AS213394
as-name: CleverCloud
org: ORG-CCS42-RIPE
import: from AS29075 accept ANY
import: from AS3257 accept ANY
import: from AS3356 accept ANY
import: from AS43424 accept ANY
export: to AS29075 announce AS213394:AS-CLVRCLD
export: to AS3257 announce AS213394:AS-CLVRCLD
export: to AS3356 announce AS213394:AS-CLVRCLD
export: to AS43424 announce AS213394:AS-CLVRCLD
admin-c: QA171-RIPE
tech-c: QA171-RIPE
status: ASSIGNED
mnt-by: RIPE-NCC-END-MNT
mnt-by: mnt-fr-clvrcldnet-1
created: 2022-11-28T08:24:23Z
last-modified: 2025-02-25T16:36:15Z
source: RIPEUn ASN (Autonomous System Number) est un identifiant unique attribué à un réseau sur Internet. Il est nécessaire pour annoncer des routes via BGP, le protocole qui permet le routage entre réseaux.
Maintenant que nous disposons d’un ASN, nous pouvons annoncer nos préfixes aux autres réseaux via le protocole BGP.
Le rôle de la base de données RIPE
Le RIPE NCC maintient une base de données publique d’objets de routage (comme l’objet aut-num présenté précédemment). Parmi ces objets figurent les objets de type route, qui indiquent quel système autonome (AS) est autorisé à annoncer un préfixe IP donné.
En pratique, ces entrées sont principalement utilisées par les opérateurs réseau et les fournisseurs de transit pour construire leurs politiques de routage et leurs mécanismes de filtrage (filtrage basé sur l’IRR). Ces filtres permettent d’accepter ou de rejeter les annonces reçues de leurs pairs. Il s’agit d’un des mécanismes utilisés pour tenter de prévenir les détournements BGP (BGP hijacks).
En appliquant ces filtres aux routes reçues de leurs pairs, les opérateurs peuvent limiter la propagation d’un préfixe annoncé par un ASN non autorisé.
Prenons un exemple : imaginons que l’organisation A possède le préfixe 192.0.2.0/24 et l’annonce à un fournisseur de transit X. Le fournisseur X applique un filtre sur les routes reçues de l’organisation A afin de n’accepter que les préfixes IP enregistrés dans la base RIR de cette organisation.
Dans ce cas, si l’organisation A commence à annoncer un préfixe qui ne lui appartient pas (par exemple notre préfixe public 91.208.207.0/24), le fournisseur X est censé rejeter cette annonce. Cela permet d’éviter qu’une route incorrecte soit propagée sur Internet et que le trafic soit redirigé vers une entité non légitime.
Le protocole BGP : comment Internet route le trafic
Pour comprendre comment nous annonçons nos préfixes sur Internet, il est essentiel de comprendre BGP — le Border Gateway Protocol. BGP est le protocole de routage de référence sur Internet. Il permet aux réseaux (systèmes autonomes) d’échanger des informations sur les préfixes IP qu’ils possèdent et sur la manière de les atteindre.
BGP fonctionne dans les deux sens. Lorsque nous annonçons à nos pairs et à nos fournisseurs de transit « nous possédons 91.208.207.0/24 », cette annonce se propage sur Internet de réseau en réseau. Chaque réseau qui relaie cette annonce ajoute son propre numéro d’AS dans le AS_PATH — une liste qui représente la séquence de réseaux qu’un paquet doit traverser pour nous atteindre.
Par exemple, OVHcloud (AS16276) voit le chemin [AS29075, AS213394] : le trafic passe par l’un de nos fournisseurs de transit (AS29075), puis arrive jusqu’à nous (AS213394). Chaque réseau qui relaie l’annonce la met à jour de cette manière, construisant progressivement un chemin complet.
Voici un exemple obtenu via le service Looking Glass d’OVHcloud :
> show route for 91.208.207.0/24 all
91.208.207.0/24 via 172.18.16.0 on eno1 [lil1_rbx1_bagg1_8k 2025-12-25] * (100/0) [AS213394i]
Type: BGP unicast univ
BGP.origin: IGP
BGP.as_path: 29075 213394
BGP.next_hop: 172.18.16.0
BGP.med: 161
BGP.local_pref: 40
BGP.community: (0,0) (29075,18000) (65535,65281)
BGP.23 [t]: 00 00 b8 6e
via 172.18.16.64 on eno1 [lil1_rbx8_bagg1_8k 2025-12-25] (100/0) [AS213394i]Dans le même temps, nous recevons des annonces provenant d’autres réseaux concernant leurs propres préfixes et les chemins permettant de les atteindre. Cela construit la vue inverse : lorsque nous devons envoyer du trafic sortant, nous savons quel chemin emprunter pour atteindre une destination donnée.
Voici un exemple avec un préfixe d’OVHcloud :
> /routing/route/print detail where dst-address=5.39.0.0/17 and active
Ab afi=ip4 contribution=active dst-address=5.39.0.0/17 routing-table=main pref-src=185.133.116.2 gateway=213.242.111.201 immediate-gw=213.242.111.201%sfp28-6 distance=20 scope=40 target-scope=10 belongs-to="bgp-IP-213.242.111.201"
bgp.as-path="3356,16276" bgp.communities=3356:2,3356:2066,3356:22,16276:40001,3356:100,65002:7018,3356:123,3356:901,65002:701,65000:64990,65000:64995,65000:64996,3356:502 .med=0 .atomic-aggregate=no .origin=igpDans cet exemple, le chemin réseau utilisé par OVHcloud pour nous atteindre est différent de celui que nous utilisons pour les atteindre.
Le processus de migration
os préfixes IP étaient entièrement gérés par notre fournisseur historique. Bien que nous en soyons propriétaires, nous lui avions délégué leur annonce sur Internet.
Cela impliquait que son ASN (AS43424) apparaissait comme origine dans les tables de routage, et que l’ensemble du trafic transitait par son infrastructure.
Clever Cloud Services | | all inbound/outbound traffic v Historical Provider (AS43424) | | originates: 91.208.207.0/24 (origin AS43424) v Internet
Nous voulions que notre ASN devienne l’origine des annonces. Pour cela, nous avons planifié une migration en trois étapes, sans interruption pour les utilisateurs.
Migration d’un préfixe entre AS
Pour migrer un préfixe d’un AS vers un autre, nous devions modifier son objet route dans la base de données RIPE. La procédure était relativement simple, mais nécessitait un timing précis.
Nous avons d’abord créé un second objet route dans la base RIPE pour notre préfixe 91.208.207.0/24. Désormais, les deux ASN étaient enregistrés comme autorisés à annoncer ce même préfixe — à la fois l’AS de notre fournisseur historique et notre propre AS (213394).
Ces objets de routage sont interrogeables publiquement via la commande whois ou via l’interface web du RIPE. Par exemple, la commande suivante permet d’obtenir les deux objets enregistrés :
❯ whois -h whois.ripe.net -T route 91.208.207.0/24
% Information related to '91.208.207.0/24AS213394'
route: 91.208.207.0/24
mnt-by: mnt-fr-clvrcldnet-1
descr: CleverCloud subnet
origin: AS213394
created: 2025-01-15T10:29:14Z
last-modified: 2025-01-15T10:29:14Z
source: RIPE
% Information related to '91.208.207.0/24AS43424'
route: 91.208.207.0/24
mnt-by: mnt-fr-clvrcldnet-1
mnt-by: MAGICRETAIL-MNT
descr: CleverCloud subnet
origin: AS43424
created: 2020-02-13T09:06:33Z
last-modified: 2020-02-13T09:06:48Z
source: RIPEUne fois ce second objet route enregistré et propagé sur Internet (c’est-à-dire une fois que les opérateurs réseau ont récupéré une version à jour de la base RIPE pour construire leurs filtres de routage), nos nouveaux fournisseurs de transit pouvaient constater que notre ASN était autorisé à annoncer ce préfixe. À partir de ce moment-là, nous pouvions commencer à annoncer ce préfixe via notre propre infrastructure.
Si nous n’avions pas créé cet objet route, nos annonces auraient pu être rejetées et nous aurions pu être considérés comme des acteurs malveillants réalisant un détournement BGP (BGP hijack).
Annonce via notre fournisseur historique
Une fois le second objet route propagé, nous avons réalisé la première étape dans la nuit du 16 janvier 2025 : nous avons commencé à annoncer nous-mêmes le préfixe via BGP à notre fournisseur historique.
Le trafic continuait d’emprunter le même chemin de transit, mais cette fois avec Clever Cloud (AS213394) comme origine des annonces, au lieu de notre fournisseur historique. Ce dernier continuait à relayer le préfixe, mais le recevait désormais de notre part au lieu de l’annoncer directement.
Clever Cloud Services (AS213394) | | originates: 91.208.207.0/24 (origin AS213394) v Historical Provider (AS43424) | | re-announces: 91.208.207.0/24 (origin AS213394) v Internet
Cette première phase a servi de validation : en cas de problème, nous pouvions revenir rapidement en arrière sans impacter les autres chemins de transit.
Annonce via nos propres transits
Quelques jours plus tard, dans la nuit du 21 janvier 2025, nous avons franchi l’étape finale : nous avons commencé à annoncer le préfixe via nos propres connexions de transit dédiées.
Clever Cloud Services (AS213394) | | originates: 91.208.207.0/24 (origin AS213394) | +---+---+---+ | | | | v v v v T1 T2 T3 HP (Transit providers + historical provider) | | | | +---+---+---+ | v Internet
Nous annonçons désormais nos préfixes directement à quatre fournisseurs upstream (trois fournisseurs de transit, T1/T2/T3, ainsi que notre fournisseur historique HP). Le trafic circule à travers l’ensemble de ces chemins, et nous disposons d’un contrôle complet sur les décisions de routage ainsi que sur la redondance.
Tout au long de ces deux phases, nous n’avons observé aucune interruption ayant un impact pour les utilisateurs. La redondance intrinsèque du protocole BGP, combinée à la nature progressive de la transition, a permis d’assurer un écoulement du trafic sans interruption, quel que soit le chemin privilégié à un instant donné.
Visibilité complète du routage Internet
Dans le cadre de la phase 2, nos trois principaux fournisseurs de transit ont commencé à nous fournir une « full view » de la table de routage Internet. Il s’agit de l’ensemble complet des préfixes IPv4 et IPv6 publiquement annoncés — soit environ 1 million de routes IPv4 et 220 000 routes IPv6.
Disposer d’une full view nous offre une visibilité inédite sur la structure d’Internet et nous permet de prendre des décisions de routage avancées. Au lieu de dépendre de la vision d’un seul fournisseur, nous avons désormais accès à l’ensemble des chemins disponibles pour atteindre n’importe quelle destination.
Avec ces informations, nous sommes en mesure de choisir les chemins optimaux pour notre trafic sortant en fonction de notre topologie réseau et de nos préférences, de mettre en œuvre du traffic engineering pour diriger les flux via des fournisseurs de transit spécifiques, de réagir dynamiquement aux conditions réseau et à la congestion, et d’équilibrer la charge entre nos quatre connexions de transit en nous appuyant sur des données de routage en temps réel.
Ce niveau de contrôle fin sur notre politique de routage est une conséquence directe de l’exploitation de notre propre système autonome et de la gestion de nos propres annonces — exactement le niveau d’indépendance opérationnelle que nous recherchions au début de cette transition.
Un an plus tard
Près d’un an après le début de l’exploitation de nos propres annonces réseau, la transition s’est révélée concluante. Nous n’avons rencontré aucun incident majeur et notre infrastructure a démontré sa résilience. Lorsque des incidents mineurs se sont produits — comme des pertes de paquets sur un fournisseur de transit spécifique ou la perte temporaire d’un lien — le trafic s’est automatiquement rééquilibré sur les connexions restantes.
Nous avons pu détecter et corriger ces problèmes directement, sans dépendre d’un fournisseur tiers. Nos utilisateurs n’ont subi aucune interruption ayant un impact. Cette capacité à assumer la responsabilité de notre réseau et à résoudre rapidement les problèmes est sans doute le principal bénéfice de cette transition.
Et ensuite
Cette transition est loin d’être terminée. Plusieurs évolutions sont prévues :
- augmentation de la capacité réseau pour absorber la croissance du trafic
- mise en place de peering BGP avec d’autres réseaux pour optimiser le trafic local sans recourir au transit
- déploiement de ROA (Route Origin Authorization) pour signer cryptographiquement nos annonces et prévenir les détournements de préfixes
- validation RPKI (Resource Public Key Infrastructure) pour vérifier la légitimité des annonces reçues et renforcer la sécurité du routage
- extension d’IPv6, en entrée (réception de trafic IPv6) comme en sortie (émission de trafic IPv6), déployée progressivement
Conclusion
Début 2025, Clever Cloud a finalisé sa transition vers une exploitation entièrement autonome de son réseau. Nous annonçons désormais nos propres préfixes IP via quatre fournisseurs upstream, ce qui nous donne un contrôle complet sur la manière dont le trafic entre et sort de notre infrastructure.
Pour nos utilisateurs, cela se traduit par une meilleure fiabilité et des temps de résolution plus courts dans notre région Paris. Lorsqu’un incident réseau survient, nous le traitons directement, et notre redondance multi-fournisseurs garantit la continuité du trafic.
Cette étape marque le début d’une nouvelle phase. Nous travaillons déjà sur le peering BGP pour optimiser le trafic local, sur le déploiement de ROA et la validation RPKI pour renforcer la sécurité du routage, ainsi que sur l’extension d’IPv6 pour généraliser le dual-stack. Nous construisons un réseau aussi robuste et autonome que le reste de notre infrastructure.