Synthèse

  • RouteViews est un projet de mesure hébergé par l’University of Oregon et exploité par le Network Startup Resource Center; il reçoit des routes BGP de réseaux volontaires, enregistre des instantanés de la table de routage (RIB) et des messages de mise à jour, puis distribue les données résultantes via des archives MRT, des flux en direct, une API et un Looking Glass web.
  • Le projet est né en 1995 d’une expérience de vue externe impliquant un premier flux MAE-WEST fourni par Randy Bush et RAINET. David Meyer fut l’un des principaux architectes initiaux à l’University of Oregon, tandis que l’archivage quotidien systématique a commencé en novembre 1997 via NLANR/MOAT.
  • Les collecteurs de RouteViews observent le plan de contrôle du routage, mais ne transportent pas le trafic ordinaire des utilisateurs finaux, n’originent pas un portefeuille normal de préfixes de service et n’ont pas autorité pour retirer, réparer ou faire respecter la route d’un autre réseau. Leur valeur est probante: ils rendent visibles certains annonces, retraits et chemins depuis des points d’observation fournis.
  • L’examen de janvier 2026 sur 2025 fait état de 883 sessions de routes complètes provenant de 277 systèmes autonomes distincts, de huit nouveaux collecteurs, de 67 To de stockage RIB et de mises à jour, de l’extension de l’API et du Looking Glass, d’une infrastructure Kafka rafraîchie et du déploiement du processeur BMP Bimper. Ces chiffres décrivent des unités différentes et ne doivent pas être traités comme un seul nombre de collecteurs.
  • RouteViews est indispensable en partie parce que ses archives ne peuvent pas être reconstituées après coup. Elles sont aussi incomplètes par conception: les pairs BGP exportent des routes sélectionnées par politique, généralement les meilleurs chemins, et l’ensemble volontaire de points d’observation comporte des biais géographiques, topologiques et de type de réseau, de la redondance, des artefacts de session et du bruit opérationnel.
  • La question à long terme du projet est de savoir si une couche d’observabilité librement accessible, hébergée institutionnellement et en partie donnée, peut faire évoluer son stockage, ses logiciels, ses effectifs, sa réplication et sa gouvernance alors que la table de routage, l’usage commercial et la demande d’accès quasi temps réel continuent de croître.

Internet ne peut pas se voir depuis un seul endroit

Internet est souvent décrit comme un réseau mondial unique, mais il est exploité comme des milliers de réseaux contrôlés indépendamment. Chaque système autonome gère ses propres routeurs, sa topologie interne, ses accords d’interconnexion, ses politiques d’exportation et ses objectifs opérationnels. Le protocole Border Gateway Protocol permet à ces systèmes d’échanger des informations d’accessibilité, mais il ne crée pas une salle de contrôle universelle. Un opérateur peut voir les routes reçues par ses propres routeurs et celles sélectionnées selon sa propre politique.

Il ne peut pas voir automatiquement comment chaque réseau distant propage les préfixes qu’il annonce, quelles routes alternatives ont été masquées par la sélection du meilleur chemin ou ce qu’un autre opérateur a choisi de ne pas exporter.

Cette absence de vue complète n’est pas une défaillance temporaire en attente d’un tableau de bord suffisamment puissant. Elle découle de l’architecture. BGP distribue des informations partielles au-delà des frontières administratives. Les réseaux révèlent ce que leurs politiques permettent, et l’état du plan de contrôle qui en résulte diffère selon les lieux. Une route peut être visible dans une région, supprimée dans une autre, préférée via un fournisseur et remplacée par une annonce plus spécifique ailleurs.

Même lorsque deux routeurs reçoivent le même préfixe, ils peuvent choisir des chemins différents parce que leurs relations commerciales et leurs préférences locales diffèrent.

RouteViews existe dans cette lacune structurelle. Il ne cherche pas à devenir l’autorité qui décide quelle route est correcte pour le monde. Il pose une question opérationnelle plus étroite: quelles informations de routage un réseau contributeur a-t-il exportées vers un collecteur donné à un moment donné? En rassemblant de nombreuses réponses de ce type, en les préservant et en les rendant réutilisables, RouteViews crée une couche d’observation publique pour un système qui n’a ni propriétaire unique ni mémoire native exhaustive.

La distinction entre observation et contrôle est le fondement du projet. Un collecteur RouteViews participe à des sessions BGP, mais il ne se comporte pas comme un fournisseur de transit ordinaire. Il reçoit des routes de ses pairs et les enregistre. Le profil PeeringDB d’AS6447 indique zéro préfixe IPv4 et IPv6 originaires, un trafic faible, principalement entrant, cohérent avec ce rôle passif. RouteViews n’envoie normalement pas de routes ordinaires en retour aux réseaux qui fournissent des données.

Il ne peut donc pas rediriger Internet en publiant un chemin préféré, réparer une fuite en modifiant la politique d’un autre système autonome ou retirer une route détournée au nom de son détenteur légitime.

Cette limite est ce qui rend le projet analytiquement honnête. Les preuves peuvent montrer qu’une origine inattendue est apparue, qu’un chemin a changé, qu’une annonce plus spécifique s’est propagée ou qu’une route a disparu de plusieurs points d’observation. Les preuves ne prouvent pas elles-mêmes le chemin physique emprunté par les paquets, le contrat commercial entre deux réseaux ni l’intention derrière le changement. RouteViews rend le comportement du routage plus observable.

Les opérateurs, les chercheurs et les systèmes de sécurité doivent encore interpréter ce comportement et le combiner avec les journaux locaux, les données RPKI, les mesures du plan de données et la communication directe.

Il s’agit d’une forme d’infrastructure dont la production est de la connaissance plutôt que du transport. Les collecteurs sont attachés au système de routage vivant, l’archive enregistre ses changements et les services d’accès distribuent ces enregistrements. Le projet compte parce que des décisions opérationnelles critiques dépendent de preuves concernant des systèmes qu’aucun entité ne peut inspecter seul. Sa contribution n’est pas un commandement souverain sur le routage. C’est une méthode durable pour voir des parties sélectionnées de la réalité du routage depuis l’extérieur du réseau qui tente de se comprendre lui-même.

D’une vue MAE-WEST à un service public

RouteViews a débuté en 1995, lorsque les looking glass publics sur le Web n’étaient pas encore une routine des opérations réseau. Le problème initial était pratique. Un réseau pouvait annoncer un préfixe et vérifier que ses propres routeurs étaient configurés correctement tout en restant incertain de la façon dont les fournisseurs ailleurs percevaient l’annonce. Le dépannage depuis l’intérieur du réseau d’origine ne pouvait pas répondre à la question externe. L’opérateur avait besoin d’une vue au-delà de sa propre frontière administrative.

Le matériel historique du projet situe un premier flux externe à MAE-WEST, l’un des environnements d’interconnexion importants de l’époque. Randy Bush, via RAINET, a fourni cette vue. Le récit ultérieur à la première personne de David Meyer décrit la réception d’une session eBGP multihop à l’University of Oregon et l’ajout de pairs, de chercheurs et de systèmes à mesure que l’usage s’étendait. Les preuves permettent de qualifier Meyer de principal architecte et opérateur initial. Elles ne permettent pas de réduire l’origine à une histoire de fondateur unique.

Le flux de Bush, l’Advanced Network Technology Center de l’University of Oregon et les opérateurs qui ont volontairement fourni des vues supplémentaires ont tous participé à la création du système.

Le nom d’hôte d’origine du service, route-views.oregon-ix.net, reflétait son objectif initial étroit. Les utilisateurs pouvaient se connecter à un routeur et inspecter les informations BGP apprises de l’extérieur sans obtenir de privilèges de configuration ni devenir clients de transit. La valeur résidait dans une séparation des rôles: le réseau contributeur fournissait une vue, l’University of Oregon hébergeait l’accès et l’opérateur interrogateur gagnait en perspective. Aucune institution centrale n’avait à certifier la route pour que la vue soit utile.

L’usage a engendré un cycle de renforcement. Les opérateurs trouvaient la perspective externe précieuse. Cela encourageait davantage de réseaux à contribuer des flux. Des flux supplémentaires rendaient l’outil plus utile car ils exposaient les différences entre fournisseurs et lieux. Les chercheurs ont ensuite reconnu que des observations répétées pouvaient répondre à des questions au-delà du dépannage immédiat. Une table en direct pouvait montrer comment un réseau voyait le monde à un instant donné; une séquence de tables pouvait révéler la croissance, les changements de politique, l’instabilité et la réponse aux pannes au fil du temps.

Le projet est donc passé du service à l’utilité publique sans frontière de fondation nette. Il n’a pas été lancé comme une plateforme de mesure mondiale complète avec une feuille de route produit définie, un personnel dédié et une architecture distribuée. Il a accumulé ces propriétés parce que ses utilisateurs ne cessaient d’exposer les limites de la forme précédente. Cette histoire compte parce qu’elle explique le caractère institutionnel encore visible aujourd’hui. RouteViews est à la fois un service de production, un jeu de données académique, une collaboration entre opérateurs et une dépendance d’infrastructure publique.

Cette identité hybride explique aussi pourquoi le projet ne doit pas être décrit comme une société constituée séparément. Les enregistrements actuels le placent au sein de l’University of Oregon et opérationnellement dans le Network Startup Resource Center. Ses interfaces publiques ont des noms, un ASN, un DOI, des dépôts de logiciels et des politiques de peering, mais aucune personnalité juridique distincte vérifiée, aucun actionnaire, aucun état des revenus ni conseil indépendant.

L’autorité du projet vient de l’exploitation des collecteurs, de la maintenance des données et de la participation continue gagnée — et non de la propriété corporative des routes qu’il observe.

L’histoire fondatrice est donc plus instructive lorsqu’elle est traitée comme un mécanisme d’infrastructure plutôt que comme une biographie héroïque. Un opérateur de réseau a fourni une vue utile. Une équipe universitaire a exposé cette vue en toute sécurité. D’autres réseaux se sont joints volontairement. Les utilisateurs ont généré la demande. L’archivage a transformé un état transitoire en preuve réutilisable. Chaque étape est devenue réelle parce que des personnes ont configuré des routeurs, exploité des systèmes et utilisé le résultat. Aucune déclaration n’a rendu RouteViews important à l’avance.

L’importance est née d’une dépendance opérationnelle répétée.

Comment un looking glass en direct est devenu une archive historique

Une vue en direct peut résoudre un problème de dépannage actuel, mais elle ne peut pas dire à quoi ressemblait le système de routage hier, à moins que quelqu’un ne l’ait enregistré. NLANR/MOAT a commencé l’archivage quotidien systématique de la sortie de RouteViews en novembre 1997. Cet acte a changé la nature du projet. Le service n’était plus seulement un endroit où un opérateur pouvait inspecter l’état actuel. Il est devenu une mémoire du plan de contrôle changeant d’Internet.

La première archive consistait en des vidages quotidiens de sorties de commandes. Ces fichiers étaient précieux parce qu’ils préservaient des informations qui auraient autrement disparu, mais leur cadence et leur format limitaient ce qui pouvait être reconstitué. Une route pouvait être annoncée, modifiée et retirée entre deux instantanés quotidiens sans apparaître dans aucun d’eux. Le texte extrait de la ligne de commande d’un routeur convenait en outre moins bien à une analyse programmatique standardisée qu’un enregistrement binaire conçu pour représenter l’état du protocole.

En mars 2001, RouteViews a porté la collecte des tables à une cadence de deux heures. L’intervalle reste associé aux archives actuelles de la table de routage (RIB) du projet. Un instantané RIB répond à une question d’état: quelles routes ce collecteur détenait-il au moment de l’instantané? Il n’explique pas à lui seul chaque changement survenu avant ou après l’instantané. Pour cela, les analystes ont besoin du flux de mises à jour — les annonces, retraits et changements d’attributs observés entre les états.

Le passage à l’enregistrement MRT local a donc été plus important qu’une simple augmentation de la fréquence des fichiers. MRT fournit une structure lisible par machine pour les messages de routage, les informations sur les pairs, les changements d’état et le contenu RIB. Un collecteur peut enregistrer les mises à jour à mesure qu’elles arrivent et exporter périodiquement l’état de la table sans dépendre de milliers d’utilisateurs distants exécutant des commandes show. Les fichiers résultants peuvent être analysés par des outils tels que BGPStream, BGPKIT, bgpdump et des logiciels de recherche personnalisés.

Cette architecture a permis un flux de travail analytique commun. Un chercheur charge un instantané RIB pour établir l’état initial, puis applique les mises à jour ultérieures pour reconstruire comment cet état a changé. La méthode permet d’étudier les changements d’origine, les changements de chemin, les retraits, la désagrégation et la propagation des événements. Elle expose aussi l’importance de l’intégrité des données. Un fichier de mise à jour manquant, une session interrompue, une erreur d’analyse ou une panne de collecteur peuvent créer un écart entre l’état reconstruit et ce que le pair a réellement exporté.

La longue archive est l’un des atouts les plus solides de RouteViews, car les preuves historiques du plan de contrôle ne sont pas renouvelables. Un nouveau collecteur peut commencer à observer demain, mais il ne peut pas recréer une annonce de chemin qui n’a jamais été enregistrée en 1998, 2008 ou 2018. L’archive permet aux chercheurs d’examiner la croissance des tables, l’adoption d’IPv6, l’apparition et la disparition de systèmes autonomes, l’évolution de la structure des chemins et les effets de routage d’incidents majeurs sur des décennies.

« Continu depuis 1997 » doit néanmoins être interprété comme la continuité du programme, et non comme la garantie que chaque collecteur, pair et fichier a été présent sans interruption. Les systèmes distribués connaissent des maintenances, des réinitialisations, des pannes réseau et des intervalles manquants. La première archive diffère en outre matériellement de la collecte actuelle par le format, la fréquence et la couverture géographique. Une utilisation responsable des données identifie les collecteurs et les périodes pertinents au lieu de traiter toute l’archive comme un instrument uniforme unique.

La valeur de l’archive vient donc à la fois de la profondeur et des limites documentées. C’est un enregistrement d’observations, pas une vérité historique parfaite. Elle préserve ce que les routeurs entités ont exporté vers les collecteurs disponibles dans les conditions opérationnelles de l’époque. Cela suffit pour soutenir des travaux scientifiques et opérationnels majeurs, à condition que l’utilisateur ne confonde pas un long enregistrement avec un enregistrement omniscient.

La centralisation a échoué avant que la distribution ne devienne une stratégie

Le modèle RouteViews d’origine concentrait de nombreux flux et utilisateurs sur un routeur central. À la mi-2000, un Cisco 7200VXR gérait plus de 50 sessions BGP multihop et environ 5 000 connexions interactives par jour. Le système était devenu suffisamment utile pour dépasser l’architecture qui l’avait créé. Le processeur, la mémoire, la stabilité des sessions et l’accès en ligne de commande étaient tous en concurrence sur une seule surface opérationnelle.

La première réponse comprenait de nouveaux logiciels. RouteViews a lancé route-views2 en octobre 2001 en utilisant Zebra BGPD sous Linux. Le passage à des systèmes standard et au routage open source était stratégiquement important, car un collecteur n’a pas besoin du matériel de transfert complet d’un routeur central transportant du trafic. Il a besoin d’une implémentation BGP fiable, de suffisamment de mémoire pour contenir les tables de routage et de mécanismes pour enregistrer l’état. Le routage logiciel offrait un coût plus bas et un plus grand potentiel d’automatisation.

Le premier Zebra n’a pas immédiatement résolu le problème. Les documents historiques signalent des difficultés à gérer environ 60 pairs. La leçon est importante pour l’analyse d’infrastructure moderne: remplacer du matériel propriétaire par un logiciel ouvert n’est pas automatiquement une montée en capacité. Le routage en production dépend de la maturité de l’implémentation, du comportement mémoire, de la justesse du protocole, de l’observabilité et de la récupération après panne. RouteViews a conservé et amélioré le matériel pendant que la voie logicielle se développait.

La réponse la plus durable a été la séparation architecturale. L’enregistrement MRT a réduit la dépendance au grattage interactif de la CLI. Plusieurs collecteurs ont réduit la dépendance à un seul système. Des couches dédiées d’archive et de traitement ont séparé l’accès utilisateur de la collecte de protocoles. Chaque séparation a attribué une responsabilité à un composant conçu pour cette charge de travail au lieu de permettre à un routeur unique de servir les pairs, d’archiver les données et de satisfaire simultanément des milliers de requêtes humaines et automatisées.

Le modèle multihop central avait aussi une faiblesse conceptuelle. La session BGP d’un pair vers un collecteur dans l’Oregon pouvait dépendre du même Internet public dont le projet essayait d’observer la panne. Si un événement perturbait la joignabilité entre le pair et le collecteur, la session pouvait disparaître, laissant une ambiguïté sur la question de savoir si la route avait changé, si le pair était en panne ou si le chemin vers le système de mesure s’était rompu. La distance géographique limitait aussi la visibilité des interconnexions locales qui pourraient ne jamais se propager via un fournisseur distant.

La distribution est donc apparue à la fois comme une exigence de mise à l’échelle et de mesure. Le projet avait besoin de collecteurs plus proches des réseaux fournissant des données, en particulier aux points d’échange Internet où de nombreux systèmes autonomes pouvaient établir des sessions BGP locales. Un collecteur régional pouvait observer les serveurs de route d’échange et les pairs bilatéraux sans exiger que chaque contribution traverse un long chemin multihop jusqu’à l’Oregon.

Cette transition est un exemple précoce d’un schéma d’infrastructure récurrent. Un outil central devient populaire parce qu’il simplifie l’accès. La croissance expose alors une concentration de charge, de défaillance et d’interprétation. La solution n’est pas de nier la valeur du centre, mais de diviser la collecte, le stockage et l’accès afin que le centre coordonne un système distribué au lieu de prétendre incarner le système lui-même.

Pourquoi le projet s’est déplacé vers les infrastructures des points d’échange Internet

RouteViews a commencé à accepter des flux IPv6 en mai 2003 et a déployé son premier collecteur documenté de point d’échange Internet à DIX-IE à Tokyo en juillet de la même année avec le soutien du WIDE Project. Des collecteurs ont suivi à ISC/PAIX en octobre 2003, à LINX à Londres en mars 2004 et à Equinix Ashburn en mai 2004. Ces déploiements ont créé le modèle qui définit désormais une grande partie de la plateforme: un collecteur RouteViews attaché directement à une infrastructure d’échange et recevant des sessions eBGP locales des réseaux présents sur place.

Un collecteur IXP présente plusieurs avantages. La contiguïté BGP peut être établie sur l’infrastructure locale partagée plutôt que par une session multihop à travers l’Internet public. Le collecteur peut recruter plusieurs réseaux déjà concentrés sur un même site. Il peut recevoir un flux du serveur de route de l’échange, qui peut représenter les routes de nombreux entités. Il peut aussi observer des interconnexions locales ou régionales invisibles via un fournisseur de transit mondial.

L’avantage est informationnel et non magique. Un collecteur dans un échange ne voit toujours que ce que ses pairs exportent. Un réseau peut envoyer une table complète, des routes clients sélectionnées, des routes locales ou une vue plus limitée. Un flux de serveur de route représente la politique et l’appartenance de ce serveur, pas chaque relation bilatérale de l’échange. La présence physique à un IXP ne fait pas de RouteViews l’exploitant de l’échange ni le propriétaire des réseaux connectés.

Le modèle distribué dépend aussi des hôtes. RouteViews demande généralement à un échange ou à un réseau de fournir une machine virtuelle ou un serveur, un port d’échange, une connectivité de transit ou de gestion, de l’alimentation, du refroidissement et une assistance locale. L’équipe centrale fournit la configuration, l’automatisation, l’intégration et le soutien opérationnel. Cet arrangement rend le déploiement mondial économiquement possible sans que RouteViews construise une installation appartenant à l’entreprise dans chaque région.

Le modèle en nature crée une dépendance spécifique. Un collecteur peut disparaître si un hôte change de priorités, retire le port, cesse de fournir du transit ou met fin à la machine virtuelle. Le matériel, l’hyperviseur et les environnements réseau locaux peuvent varier. L’automatisation centrale doit donc produire un comportement cohérent sur une infrastructure qui n’est ni entièrement détenue ni physiquement contrôlée par l’University of Oregon.

L’expansion récente montre pourquoi le placement dans les échanges reste stratégiquement important. En 2025, RouteViews a ajouté des collecteurs au Costa Rica, aux Philippines, à Hong Kong, en Indonésie, en Roumanie, au Nigeria, en Suède et au Danemark. Les emplacements comprenaient CRIX, les sites GetaFIX de Manille, Cebu et Davao, HKIX, IIX à Jakarta, InterLAN à Bucarest, IXPN à Lagos et les sites Netnod de Stockholm et Copenhague. NSRC a signalé un nouveau collecteur à DE-CIX Francfort en février 2026.

Ces ajouts ne sont pas de simples points sur une carte mondiale. Ils répondent à un changement de la topologie d’Internet. Les grandes plateformes de contenu, les CDN et les réseaux régionaux échangent de plus en plus de trafic localement. Un collecteur qui ne voit que des routes de transit hiérarchiques peut manquer des relations et des politiques qui restent proches de la périphérie. La politique de peering sélective 2025 de RouteViews priorise explicitement les régions et les réseaux qui ajoutent une visibilité distinctive plutôt que de traiter chaque session supplémentaire comme équivalente en valeur.

Le projet continue d’exploiter des collecteurs multihop, car tous les pairs utiles ne partagent pas un IXP avec AS6447. Les deux modèles servent des objectifs différents. Les sessions IXP locales améliorent la visibilité régionale et d’échange. Les sessions multihop étendent la participation aux grands dorsales, aux réseaux de recherche ou aux opérateurs spécialisés ailleurs. Une stratégie complète a besoin des deux, tout en reconnaissant la dépendance au chemin et les limites d’interprétation de chacun.

Ce qu’un collecteur RouteViews enregistre réellement

Un pair RouteViews établit une session BGP et exporte des routes selon sa propre politique et les exigences de peering du projet. Le collecteur reçoit ces routes dans une base d’informations de routage BGP (RIB). Il enregistre l’état de la table et les changements, mais n’a aucun rôle de transfert normal pour ces routes. Les paquets des utilisateurs ordinaires ne sont pas envoyés par le collecteur simplement parce que celui-ci a appris un chemin.

Le mot « route » peut masquer plusieurs types d’informations. Pour un préfixe, un enregistrement BGP peut inclure le système autonome d’origine, le chemin AS, les informations de prochain saut, les communautés et d’autres attributs. Une mise à jour enregistre une annonce, un retrait ou un changement. Le collecteur associe le message à un pair et à un moment. Les analystes peuvent ensuite comparer ce que différents pairs ont exporté et comment la visibilité a changé.

L’enregistrement ne révèle pas tous les faits sur l’infrastructure sous-jacente. Un chemin AS n’est pas une carte physique de la fibre. Il ne montre pas chaque routeur à l’intérieur de chaque système autonome ni n’identifie chaque installation traversée. Il ne divulgue pas la capacité des liaisons, le volume de trafic ni les conditions des contrats commerciaux. Le chemin représente des informations du plan de contrôle utilisées pour choisir l’accessibilité, et les attributs BGP peuvent être transformés par la politique.

La distinction entre routes complètes et tous les chemins est particulièrement importante. RouteViews préfère les pairs qui envoient une vue de routage complète, c’est-à-dire des routes couvrant la plupart des préfixes accessibles mondialement. L’export BGP standard envoie généralement le meilleur chemin sélectionné pour chaque préfixe, pas toutes les alternatives connues en interne. RouteViews n’accepte pas Add-Path selon sa politique actuelle. Un flux de routes complètes améliore donc la couverture des préfixes et de la topologie sans exposer l’ensemble complet des décisions internes du pair.

Une session de serveur de route introduit une autre couche. Dans un échange, le serveur de route reçoit des routes de nombreux entités et les redistribue selon sa politique. Une seule session RouteViews vers ce serveur peut révéler des routes locales de nombreux réseaux. Pourtant, le pair de la session est le serveur de route, tandis que les chemins représentés proviennent d’ailleurs. Les analystes ne doivent pas interpréter la présence d’un ASN dans les données comme la preuve d’une relation commerciale directe avec RouteViews ni même d’un accord de peering bilatéral à l’échange.

C’est pourquoi les outils internes modernes de RouteViews distinguent les observations bilatérales et les observations de serveur de route. Selon la politique sélective, le projet peut refuser une session bilatérale qui n’ajoute aucune information significative au-delà d’un flux de serveur de route existant. L’objectif n’est pas le plus grand nombre d’adjacences possible. C’est un ensemble utile de perspectives avec suffisamment de diversité, de stabilité et de valeur régionale pour justifier leur coût opérationnel.

La passivité du collecteur définit aussi la frontière de sécurité. RouteViews peut montrer qu’une route d’origine inattendue était visible depuis un pair. Il peut exposer une annonce plus spécifique ou la propagation d’une route invalide lorsqu’on la combine avec les données RPKI. Il ne peut pas décider que la route doit être retirée d’un autre réseau. L’application reste locale aux opérateurs qui appliquent des filtres, la validation d’origine de route, les limites de préfixes et les procédures d’incident.

Le jeu de données résultant est puissant parce qu’il est proche de la réalité d’exécution tout en restant soigneusement borné. Il enregistre des messages de protocole de réseaux de production. Ce n’est pas un registre de vérité contractuelle, une trace de paquets du trafic utilisateur ni un oracle de routage central. Toute analyse valide commence par respecter cette frontière.

Collecteurs, sessions, systèmes autonomes et points d’observation ne sont pas interchangeables

L’échelle actuelle de RouteViews est souvent exprimée par plusieurs chiffres qui répondent à des questions différentes. L’examen opérationnel de janvier 2026 a fait état de 883 sessions recevant des routes complètes de 277 systèmes autonomes distincts. Une présentation de février 2026 décrivait un réseau de plus de 40 collecteurs, bien que certaines diapositives portent une date de mise à jour de mai 2025. PeeringDB listait 26 connexions d’échange publiques pour AS6447 au 29 juillet 2026. Ces chiffres peuvent tous être vrais parce qu’ils décrivent différentes couches de la plateforme.

Un collecteur est un routeur ou une instance de logiciel de routage recevant des sessions BGP. Une session est une adjacence entre une adresse de pair et un collecteur. Un même système autonome peut fournir plusieurs sessions à plusieurs emplacements, sur IPv4 et IPv6, ou via des relations de serveur de route et bilatérales. Un point d’observation est la perspective d’observation générée par une session ou un routeur contributeur. Une connexion d’échange est la présence d’AS6447 sur une infrastructure particulière. Aucune de ces unités ne correspond une à une aux autres.

La distinction compte pour l’indépendance analytique. Deux sessions du même ASN à des échanges différents peuvent révéler des politiques et des chemins réellement différents. Elles peuvent aussi être très redondantes. Une session de serveur de route peut exposer des centaines d’origines de entités tout en ne représentant qu’un seul contexte de politique d’échange. Un collecteur avec de nombreux pairs peut produire une image locale large, tandis qu’un collecteur avec un pair inhabituel peut apporter plus d’informations uniques pour une question de recherche spécifique.

La croissance de 20 % des sessions de routes complètes signalée par RouteViews en 2025 ne doit donc pas se traduire en une amélioration de 20 % de la visibilité mondiale. Plus de 50 pairs existants ont changé leur politique d’exportation pour envoyer des routes complètes, et 28 nouveaux pairs à routes complètes ont été ajoutés. Cela augmente la quantité de données de table utilisables, mais la valeur incrémentale dépend de l’emplacement des pairs, de ce qu’ils exportent et des chemins déjà visibles ailleurs.

La recherche sur le problème des « points les plus précieux » rend cette dépendance à la tâche explicite. Un point d’observation qui améliore la détection des détournements peut ne pas être celui qui contribue le plus à l’inférence des relations entre AS. La suppression ou l’échantillonnage aléatoire de pairs peut réduire la précision de manière inégale. La politique sélective du projet est donc un passage du comptage des flux à l’évaluation de ce que chaque flux ajoute.

Aucun inventaire exact de collecteurs actifs aligné sur une date n’a été trouvé dans le dossier public. Le chiffre de plus de 40, les huit ajouts et les 26 connexions d’échange PeeringDB ne doivent pas être combinés en un total fabriqué. Ce n’est pas un problème de rapport mineur. Un inventaire public avec statut opérationnel, emplacement, type de session et continuité d’archive permettrait aux utilisateurs de comprendre quelles perspectives étaient disponibles pour une analyse donnée.

Les chiffres d’échelle restent significatifs lorsqu’ils sont utilisés correctement. Ils montrent que RouteViews n’est plus un routeur universitaire unique. C’est un système distribué avec des centaines de sessions de routes complètes, des centaines d’ASN contributeurs, des dizaines de collecteurs et des présences d’échange dans toutes les régions. La discipline analytique consiste à préserver l’unité attachée à chaque nombre.

Instantanés RIB, flux de mises à jour et reconstruction de l’état du routage

L’archive de RouteViews repose sur deux formes complémentaires de preuves. Les instantanés RIB enregistrent les routes détenues par un collecteur à un moment donné. Les fichiers de mise à jour enregistrent les annonces et les retraits observés entre les instantanés. La documentation actuelle décrit une cadence RIB de deux heures et des fichiers de mise à jour regroupés en intervalles de 15 minutes.

Les intervalles sont des conventions d’emballage, pas des garanties que tous les événements se produisent à ces frontières. Les mises à jour BGP arrivent en continu. Le collecteur les regroupe pour la distribution. Une exportation RIB peut aussi prendre du temps, surtout à mesure que les tables grossissent. Les analystes doivent comprendre les horodatages, le comportement du collecteur et l’exhaustivité des fichiers plutôt que de traiter chaque nom de fichier comme un échantillon instantané parfait.

La reconstruction de l’état commence généralement par un RIB et applique les mises à jour ultérieures dans l’ordre. Cela permet à un analyste de demander si l’origine d’un préfixe a changé, comment une annonce s’est propagée ou combien de temps un retrait est resté visible. La méthode révèle également comment des événements de collecteur peuvent être confondus avec des événements Internet.

Une réinitialisation de session BGP est l’exemple classique. Lorsqu’une session se rétablit, le pair peut transférer à nouveau sa table. Le sursaut de mises à jour qui en résulte peut ressembler à un changement de routage généralisé même si la topologie mondiale sous-jacente n’a pas changé de la même manière. La recherche sur l’identification des transferts de table de routage a développé des méthodes pour distinguer ces schémas lorsque les journaux de session explicites sont incomplets.

Un pair qui cesse silencieusement d’envoyer des données présente un problème différent. Le collecteur peut continuer à fonctionner pendant qu’un point d’observation devient obsolète ou absent. Un fichier peut exister tout en contenant moins d’informations que prévu. Inversement, un pair peut produire un volume extrême de mises à jour par flapping, changements d’attributs, désagrégation, défauts logiciels ou retransferts répétés de table.

Ces comportements créent le choix non résolu entre fidélité et filtrage. Préserver chaque message observé conserve la preuve de l’instabilité et des mauvaises configurations. Cela augmente aussi le stockage, la charge de traitement et le risque que des analyses naïves comptent le bruit répétitif comme un changement Internet significatif à l’échelle mondiale. Filtrer le bruit peut améliorer l’utilisabilité tout en supprimant la preuve même qu’un autre chercheur veut étudier.

L’examen 2025 de RouteViews décrit la surveillance de l’impact par pair et la possibilité de désactiver les sessions qui menacent la stabilité de la plateforme. C’est un contrôle opérationnel nécessaire, mais cela introduit une question de gouvernance et de documentation: quand un flux cesse-t-il d’être une preuve précieuse et devient-il un risque d’infrastructure inacceptable? Aucune règle publique universelle ne peut éliminer le jugement, car la réponse dépend du volume, de la cause, de la valeur analytique et de la santé du service.

La valeur du projet dépend donc de plus que la collecte de messages. Elle dépend de l’enregistrement de suffisamment de métadonnées, de la surveillance de la santé des sessions, de la préservation des fichiers, de la documentation des changements et de l’aide aux utilisateurs pour distinguer les événements de routage des artefacts de mesure. L’archive est un instrument. Comme tout instrument, elle doit être étalonnée et interprétée.

Le backend moderne: FRRouting, BMP, Bimper et Kafka

L’identité historique de RouteViews est liée aux fichiers MRT et à l’accès direct aux routeurs, mais sa plateforme actuelle comprend une architecture logicielle et de streaming plus large. Des présentations de 2026 décrivaient Ubuntu Server 24.04 comme système d’exploitation standard des collecteurs et FRRouting 10.5 sur les collecteurs logiciels, avec un Cisco ASR1004 conservé tandis que le projet continuait de passer des appareils physiques aux machines virtuelles.

Le passage aux collecteurs logiciels modifie le modèle d’exploitation. Une machine virtuelle standard peut être hébergée par un échange ou un réseau avec moins de matériel spécialisé, et la configuration peut être automatisée sur tous les sites. La spécification d’hôte publiée par RouteViews demande au moins 16 Go de mémoire, de préférence 32 Go, quatre CPU virtuels, 100 Go de stockage, une interface de gestion ou de transit et une interface côté échange. Ces exigences décrivent le nœud de collecte, pas l’archive centrale ni le parc de traitement de flux.

Les collecteurs produisent des fichiers MRT pour l’archive historique et peuvent aussi exporter l’état BGP via le protocole BGP Monitoring Protocol. BMP est conçu pour exposer les informations de routage d’un routeur aux systèmes de surveillance sans faire de ces systèmes des entités à la sélection de route. Dans l’architecture de RouteViews, Bimper reçoit les enregistrements BMP des collecteurs, transmet les messages bruts compatibles à Kafka et exporte des métriques opérationnelles via Prometheus. L’outil bimperctl permet au personnel d’inspecter les connexions et l’état du service.

Bimper a été développé parce qu’OpenBMPd rencontrait des problèmes de stabilité sous la charge de RouteViews. Ce détail est important, car il montre RouteViews comme opérateur d’infrastructure logicielle, et non simple utilisateur d’outils existants. Le projet avait un goulot d’étranglement de production dans le chemin des données en direct et a construit un composant destiné à gérer ses propres exigences d’échelle et d’observabilité.

Kafka fournit une couche de distribution entre la collecte et les consommateurs. Sans une telle couche, chaque système en aval pourrait interroger directement les collecteurs ou maintenir une logique de traitement de session distincte. Une plateforme de streaming peut gérer plus efficacement la diffusion, la contre-pression et l’indépendance des consommateurs, bien qu’elle crée ses propres dépendances de fiabilité, d’ordre, de rétention et d’exploitation.

L’archive et le flux en direct répondent à des besoins différents. La recherche historique valorise l’exhaustivité, la reproductibilité et la capacité de retraiter une période avec de nouvelles méthodes. La surveillance en direct valorise la faible latence et la livraison continue. Un flux peut se reconnecter et reprendre imparfaitement; une archive peut arriver plus tard mais préserver un fichier stable. RouteViews a besoin des deux, car les utilisateurs opérationnels et les chercheurs posent des questions différentes sur les mêmes observations sous-jacentes.

Ce backend accroît aussi l’importance de la surveillance. Un collecteur peut être sain alors que sa connexion BMP échoue. Kafka peut accepter des données pendant qu’un consommateur prend du retard. Des fichiers MRT peuvent être écrits alors qu’un flux en direct est retardé. Les métriques Prometheus et les outils de contrôle de service rendent ces états internes visibles pour les opérateurs qui doivent maintenir la plateforme. Le produit central du projet est l’observabilité, et sa propre infrastructure doit donc elle aussi être observable.

L’API et le Looking Glass séparent les utilisateurs des collecteurs

L’accès telnet direct était approprié lorsque RouteViews servait une population gérable d’opérateurs humains. Au fil du temps, des scripts automatisés ont commencé à émettre des milliers de commandes sur les interfaces des collecteurs. Un routeur conçu pour maintenir des sessions BGP et enregistrer des routes est devenu un moteur de requête sans limites. Le résultat a répété le problème original du routeur central au niveau de la couche d’accès: une ouverture utile a créé une charge qui menaçait le système fournissant les données.

RouteViews a répondu en construisant un Looking Glass basé sur navigateur et une API structurée. Le Looking Glass a été lancé en mai 2025 et prend en charge des requêtes courantes de préfixe, d’expression de chemin, de résumé et orientées RPKI depuis des nœuds sélectionnés. Au lancement, son backend traduisait encore les requêtes web en commandes exécutées via l’interface telnet. La direction prévue était de déplacer davantage de requêtes vers l’API à mesure que la couverture s’étendait.

L’API couvre actuellement dix collecteurs: AMS-IX à Amsterdam, LINX à Londres, NAPAfrica à Johannesburg, Equinix SG1 à Singapour, Equinix SYD1 à Sydney, IX.br à São Paulo et quatre collecteurs multihop à l’University of Oregon. Elle expose les métadonnées des collecteurs, les informations RIB, les informations sur les pairs, les informations sur les AS adjacents et les préfixes appris de sessions spécifiées. Les métadonnées sont rafraîchies toutes les deux minutes.

L’API est explicitement conçue pour les données actuelles plutôt que pour la recherche historique approfondie. Cette séparation évite une erreur produit courante. Un service de requête actuel et une archive en masse sur plusieurs décennies ont des structures d’indexation, de stockage et de coût différentes. Essayer de faire jouer les deux rôles à une seule interface peut dégrader chacun. RouteViews oriente l’analyse longitudinale vers les fichiers MRT tout en offrant un accès structuré pour les questions fréquentes d’état actuel.

L’API soutient aussi les opérations internes. RouteViews a développé des outils qui comparent les préfixes originaires d’un pair potentiel, les observations bilatérales et de serveur de route existantes, la contribution régionale et la couverture des collecteurs. Certains outils peuvent générer ou modifier la configuration des collecteurs. Cela réduit l’effort manuel et les erreurs, mais crée une nouvelle dépendance à des enregistrements PeeringDB exacts et à une automatisation sûre.

Le Looking Glass et l’API contraignent la charge de travail d’une manière que l’accès CLI direct ne peut pas. Ils peuvent limiter les types de requêtes, mettre en cache les réponses répétées, appliquer une authentification ou des contrôles de débit et renvoyer des résultats structurés. Ils rendent aussi l’accès plus facile pour les utilisateurs qui ne veulent pas analyser des fichiers MRT ni apprendre la syntaxe des commandes de routeur.

La transition était incomplète à la date limite de juillet 2026. La couverture de l’API représentait un sous-ensemble de la plateforme, et le Looking Glass dépendait encore partiellement de l’interface héritée. Retirer telnet trop vite pourrait casser des scripts et des flux de travail construits sur des décennies. Le conserver indéfiniment pourrait préserver les problèmes de charge et de sécurité que la modernisation vise à résoudre.

Le point stratégique important est que RouteViews passe d’un accès centré sur le routeur à un accès centré sur les services sans abandonner l’archive. Le collecteur doit collecter. L’archive doit préserver. L’API doit répondre aux requêtes actuelles structurées. Le Looking Glass doit soutenir le diagnostic humain. Kafka doit distribuer les données en direct. Séparer ces fonctions est la forme actuelle de gestion de l’échelle du projet.

Construire une vue mondiale à partir de pairs volontaires

RouteViews ne contraint aucun système autonome à contribuer. Sa couverture émerge de sessions BGP volontaires, de relations d’hébergement et de la volonté des réseaux d’exposer leurs informations de routage. Cela produit un bien public par des décisions locales: chaque pair choisit ce qu’il exporte, chaque hôte choisit l’infrastructure qu’il fournit et chaque utilisateur choisit comment consommer les données.

Le modèle demande peu de capitaux centraux par rapport à la possession de chaque emplacement de collecteur, mais son succès dépend de relations sociales et opérationnelles. Le personnel de RouteViews doit recruter des pairs, vérifier la préparation technique, coordonner les connexions d’échange, dépanner les sessions et maintenir la confiance. Les relations mondiales de NSRC avec les opérateurs, les réseaux de recherche et d’éducation et les communautés d’échange offrent un environnement institutionnel adapté à ce travail.

La politique de peering 2025 a formalisé un passage d’une collecte large à une croissance sélective. Les pairs préférés fournissent des tables complètes stables, une visibilité régionale ou périphérique utile, des chemins distinctifs et des opérations de qualité production. Les candidats doivent maintenir des informations PeeringDB à jour, utiliser un espace d’adressage public et un ASN public, filtrer les routes à usage spécial, éviter d’envoyer une route par défaut et prendre en charge IPv4 et IPv6 lorsque c’est possible. RouteViews n’accepte pas Add-Path.

La sélectivité est une reconnaissance du coût. Chaque session consomme de la mémoire, du traitement, de la surveillance et de l’attention du personnel. Chaque mise à jour entre dans le stockage et éventuellement dans le flux en direct. Un flux qui duplique une vue de serveur de route existante peut ajouter peu d’informations. Un pair bruyant ou instable peut affecter l’ensemble de la plateforme de manière disproportionnée.

La sélectivité crée aussi un pouvoir discrétionnaire. Le coordinateur de peering évalue si un réseau est stable, régionalement utile ou suffisamment non redondant. La politique publique autorise des exceptions, y compris l’acceptation possible de réseaux expérimentaux, mais aucun processus d’appel formel ni d’examen externe n’a été trouvé. La flexibilité est utile sur le plan opérationnel; la surface de gouvernance doit néanmoins rester visible, car la sélection façonne le jeu de données utilisé par les chercheurs et les systèmes de sécurité.

Les sources actuelles contiennent aussi une ambiguïté de titre de rôle. Nina Bargisen est identifiée comme coordonnatrice de peering de RouteViews dans l’examen opérationnel de janvier 2026 et la publication de la politique 2025. Les dossiers de l’University of Oregon identifient Owen Conway comme ingénieur réseau et coordinateur de peering de RouteViews. Les preuves n’établissent pas si les rôles sont complémentaires, reflètent une transition ou proviennent de relations d’emploi différentes. Un profil responsable nomme les deux sans fabriquer de résolution.

L’équipe élargie identifiée dans une présentation de 2026 comprenait Hans Kuhn, Nina Bargisen, Owen Conway, Philip Smith, Philip Paeps et Anton Berezin. Les dossiers universitaires listent Steve Huter comme directeur de NSRC et Hans Kuhn comme directeur principal de l’infrastructure de recherche. Un poste vacant d’ingénieur d’infrastructure RouteViews d’avril 2026 décrivait des responsabilités couvrant la maintenance des collecteurs, le développement d’outils, les relations sectorielles, l’intégrité des données, la sécurité du routage et le soutien à la recherche.

Ces dossiers montrent que la plateforme dépend autant de personnes spécialisées que de machines données. La collecte BGP mondiale exige du jugement en peering, des opérations de routage, de l’automatisation, des systèmes distribués, de la gestion de stockage et du soutien aux utilisateurs. Une petite équipe spécialisée crée de l’efficacité et de la continuité, mais elle crée aussi un risque de personne clé et de recrutement.

La sécurité du routage utilise les preuves de RouteViews mais reste hors du contrôle de RouteViews

Les fuites de routes et les détournements deviennent souvent visibles comme des changements de routage inattendus. Un préfixe peut apparaître avec un nouvel ASN d’origine, une route plus spécifique peut se propager, le chemin AS peut changer brusquement ou la route précédente peut être retirée. RouteViews fournit les observations à partir desquelles les systèmes de surveillance et les analystes d’incidents peuvent détecter ou reconstruire ces schémas.

Le projet ne garantit pas la détection automatique. Un événement doit se propager jusqu’à au moins un point d’observation pertinent, le pair doit l’exporter et le chemin de collecte doit rester sain. Un incident localisé peut être invisible si aucun réseau contributeur ne le voit ou ne le signale. Un événement généralisé peut être visible rapidement depuis de nombreuses sessions tout en exigeant du contexte pour distinguer une action malveillante d’une mauvaise configuration ou d’un changement de politique légitime.

RPKI ajoute une couche de validation externe. Les Route Origin Authorisations peuvent être comparées aux annonces d’origine observées pour les classer comme valides, invalides ou introuvables. Le Looking Glass de RouteViews prend en charge des vérifications orientées RPKI. RouteViews lui-même n’émet pas de ROA, ne décide pas quels réseaux doivent appliquer la validation d’origine de route ni ne retire les routes invalides de la table mondiale.

La distinction entre preuve et application est importante sur le plan opérationnel. Une plateforme de sécurité peut alerter sur les données de RouteViews. Un opérateur peut configurer des filtres ou la validation d’origine. Un registre et un détenteur de ressources peuvent gérer les ROA. Une équipe de réponse peut contacter les réseaux. RouteViews fournit un flux d’observation partagé qui aide ces acteurs à se coordonner, mais il n’absorbe ni leur autorité ni leur responsabilité.

Les mêmes données soutiennent la recherche sur la topologie et les relations. Les chemins AS fournissent des preuves à partir desquelles les chercheurs infèrent les relations fournisseur-client, le peering, les cônes de clients et les dépendances de transit. CAIDA utilise les données de RouteViews dans les correspondances préfixe-AS, AS Rank et les produits associés. Ces sorties sont dérivées par une méthodologie. Ce ne sont pas des enregistrements contractuels directs ni la preuve que chaque adjacence représente un arrangement commercial spécifique.

La correspondance préfixe-origine est de même temporelle et observationnelle. Elle associe des adresses à l’AS d’origine visible dans les données de routage à un moment donné. Elle est utile pour la recherche en sécurité, performance et politique, mais ce n’est pas un registre de propriété légale. Une route plus spécifique, un déploiement anycast, un événement temporaire ou un arrangement multi-origine peuvent compliquer la correspondance.

La pertinence de RouteViews pour la sécurité vient donc de la position d’infrastructure et de la continuité historique. Il enregistre les signaux du plan de contrôle de nombreux réseaux et les rend disponibles aux systèmes qui ont besoin d’une perspective externe. Sa limite est tout aussi structurelle: il ne voit que les routes qui lui sont envoyées et ne peut pas convertir l’observation en conformité universelle.

Dépendance de la recherche et relation avec CAIDA

Les données de RouteViews sont devenues un fondement de la mesure d’Internet parce qu’elles sont publiques, anciennes et exprimées dans des formats largement pris en charge. Les chercheurs les utilisent pour étudier la croissance des tables de routage, la topologie des AS, le changement de chemin, la désagrégation des préfixes, la résilience, les détournements, les fuites et l’adoption de mécanismes de sécurité. Une présentation de 2019 citait environ 500 publications, mais aucun total actuel dédupliqué de manière indépendante n’a été vérifié.

La conclusion sûre est une utilisation extensive en recherche, pas un nombre précis actuel d’articles.

CAIDA est l’une des institutions en aval les plus importantes. Elle dérive les correspondances préfixe-AS et les produits au niveau AS à partir des observations de RouteViews et fournit des outils tels que BGPStream qui aident les chercheurs à traiter les données de RouteViews et de RIPE RIS. CAIDA, MIT CSAIL et UO NSRC ont aussi collaboré au projet Global Measurement Infrastructure for Internet Security d’octobre 2021 à septembre 2025.

Le projet ILANDS, dirigé par CAIDA et prévu jusqu’en mars 2027, traite de la mise à l’échelle et de l’infrastructure de données réseau à long terme, y compris les défis de routage et de stockage. Ces collaborations montrent RouteViews intégré dans un écosystème de mesure plus large plutôt qu’exploité comme un service universitaire isolé. Les montants et objectifs des subventions doivent néanmoins être répartis avec soin: les subventions dirigées par CAIDA ou couvrant l’ensemble de NSRC ne sont pas des budgets propres à RouteViews.

La relation avec RIPE RIS est complémentaire. RIS exploite ses propres collecteurs de routes distants distribués et des services de routage publics via RIPE NCC. Il utilise aussi des balises de routage actives, une caractéristique distincte de l’identité de collecteur généralement passif de RouteViews. Les deux plateformes se coordonnent pour améliorer la redondance et la visibilité mondiale tout en restant des systèmes séparés avec des points d’observation et des interfaces différents.

Les chercheurs combinent souvent RouteViews et RIS parce qu’aucune plateforme n’est complète. Le chevauchement permet la vérification croisée et améliore la résilience. Les différences révèlent comment les résultats de mesure dépendent de la sélection des collecteurs. Isolario et d’autres plateformes ajoutent d’autres perspectives, tandis que les moniteurs commerciaux enrichissent les données publiques avec des points d’observation propriétaires, des alertes et un soutien.

L’existence d’alternatives ne réduit pas la valeur de RouteViews. Elle clarifie l’usage correct. Une analyse robuste sélectionne les sources selon la question, documente les points d’observation et teste si les conclusions survivent aux changements du jeu de données. RouteViews n’est pas universellement supérieur à chaque plateforme homologue. Ses forces distinctives sont la profondeur d’archive, la familiarité des opérateurs, les données MRT publiques, la combinaison de collecteurs IXP et multihop et sa continuité institutionnelle à l’University of Oregon.

Le DOI du projet, 10.7264/1y7v-2d90, fournit un mécanisme de citation destiné à rendre l’usage académique plus visible et reproductible. La citation fait partie de la durabilité, car elle permet de reconnaître la contribution de l’infrastructure. Elle ne révèle pas à elle seule combien de produits, articles ou systèmes opérationnels dépendent des données.

Biais, redondance et limites d’une vue fondée sur le volontariat

Les pairs de RouteViews ne sont pas un échantillon aléatoire d’Internet. Ce sont des réseaux disposés et capables d’établir des sessions BGP selon la politique du projet, souvent dans des échanges où RouteViews a un collecteur ou via des arrangements multihop. Le placement des collecteurs dépend en partie d’hébergements donnés. L’ensemble de points d’observation qui en résulte reflète les relations entre opérateurs, la maturité de l’interconnexion et la sélection stratégique.

Un biais géographique peut survenir parce que les régions dotées de grands IXP bien organisés sont plus faciles à observer. Un biais de type de réseau peut survenir parce que les fournisseurs de transit, les réseaux de recherche et les opérateurs techniquement engagés peuvent être plus disposés à contribuer que les réseaux à accès fermé ou les entreprises. Un biais topologique peut survenir parce que certaines parties du graphe des AS ont de nombreux points d’observation tandis que d’autres n’en ont aucun.

Ces biais n’invalident pas les données. Ils définissent la population que les données peuvent représenter. Une étude du routage mondial qui utilise RouteViews doit identifier quels collecteurs et pairs ont été sélectionnés et éviter de traiter l’absence dans l’archive comme la preuve qu’une route n’existait nulle part.

La redondance est le coût correspondant d’une collecte large. De nombreux pairs exportent des meilleurs chemins identiques ou étroitement liés. La redondance améliore la résilience et peut révéler des désaccords, mais elle augmente le stockage et le calcul. La valeur marginale d’un nouveau flux dépend de la tâche. Un chemin redondant pour la couverture mondiale des préfixes peut encore être précieux pour un incident régional.

Les flux de serveur de route compliquent l’interprétation, car une seule session peut exposer de nombreux entités d’échange. Les flux bilatéraux peuvent dupliquer ces routes. Un serveur de route peut modifier la représentation du chemin selon sa conception. Les analystes ont besoin de métadonnées qui distinguent la relation source et évitent de traiter chaque ASN représenté comme un pair direct.

L’export du meilleur chemin crée un autre angle mort. Un pair peut connaître plusieurs chemins mais n’envoyer à RouteViews que la route sélectionnée. Les alternatives cachées ne peuvent devenir visibles que lorsque la politique ou l’accessibilité change. L’archive révèle donc les chemins utilisés ou exportés, pas l’ensemble complet d’options disponibles à l’intérieur de chaque réseau.

La topologie physique est également cachée. Deux chemins AS qui semblent disjoints peuvent partager la fibre, des installations, l’alimentation ou une organisation en amont. Les données de routage sont essentielles pour comprendre la diversité du plan de contrôle, mais elles ne peuvent pas prouver l’indépendance physique sans preuves supplémentaires.

La conclusion disciplinée est que RouteViews est un instrument de mesure aux propriétés d’échantillonnage connues, et non une tentative ratée d’omniscience. Davantage de collecteurs peuvent améliorer la couverture, mais aucun ensemble volontaire fini ne supprime tous les biais. L’obligation scientifique est de décrire l’instrument et de borner l’inférence.

Pairs bruyants, croissance du stockage et économie de la préservation de tout

RouteViews a signalé que le stockage alloué aux RIB et aux mises à jour est passé de 11,1 To à 67 To en 2025. Le même examen décrivait les plus grands pairs à routes complètes comme fournissant environ 1,1 million de préfixes IPv4 et 253 000 préfixes IPv6. Une présentation distincte évoquait environ 50 To compressés, reflétant probablement une date plus ancienne ou une définition de stockage différente.

La croissance est en partie attendue. Les tables de routage s’étendent, davantage de pairs envoient des routes complètes et davantage de collecteurs créent des vues parallèles. La taille RIB peut être modélisée raisonnablement à partir du nombre de préfixes et de la fréquence de collecte. Le volume de mises à jour est plus difficile à prévoir, car il dépend du comportement.

Un seul pair instable peut générer un très grand nombre de messages. Le flapping de routes, les changements d’attributs répétés, les réinitialisations de session, les défauts logiciels et la désagrégation peuvent produire des sursauts de mises à jour qui dominent le stockage. Une partie de ce bruit est significative sur le plan opérationnel. Un chercheur étudiant l’instabilité peut valoriser exactement les messages qu’un autre utilisateur veut filtrer.

Le problème de stockage n’est donc pas résolu en supprimant les doublons sans discernement. L’objectif de l’archive est de préserver les preuves. Toute politique de filtrage modifie l’instrument. En même temps, préserver chaque message répété peut ralentir l’accès, augmenter les coûts de cloud et de réplication et encourager des analyses trompeuses fondées sur le nombre brut de messages.

Le backend moderne donne à RouteViews plus d’outils pour gérer la tension. Bimper et Prometheus peuvent identifier les pairs à fort impact. Kafka peut isoler les consommateurs. La politique de configuration peut désactiver une session menaçant la stabilité. Le stockage cloud et les travaux BigQuery peuvent fournir une capacité supplémentaire de distribution et d’analyse.

Le dépôt RouteViews-Google décrit la synchronisation, les sommes de contrôle, le transfert gRPC, le stockage dans Google Cloud et la conversion vers des tables analytiques. L’activité de développement s’est poursuivie en juillet 2026. Le dépôt public n’établit pas une couverture de production complète, une parité d’archive, une politique de rétention, une répartition des coûts ni des garanties de service. C’est une preuve de mise en œuvre active, pas la preuve qu’un miroir cloud a remplacé l’archive de l’University of Oregon.

La préservation à long terme exige plus que l’ajout de disques. Les fichiers ont besoin de sommes de contrôle, de réplication, de reprise après sinistre, de métadonnées et de formats accessibles. Une archive sur plusieurs décennies accumule aussi des structures historiques hétérogènes qui doivent rester interprétables. La distribution cloud peut réduire la charge sur un système de livraison unique et abaisser la barrière à l’analyse à grande échelle, mais elle peut aussi introduire une dépendance fournisseur et un coût récurrent.

La question économique centrale est de savoir quelles observations valent la peine d’être préservées et qui paie pour leur disponibilité continue. La réponse de RouteViews a historiquement favorisé l’ouverture et l’ampleur. Le défi de durabilité est de rendre cette réponse abordable sur le plan opérationnel sans changer silencieusement le sens de l’archive.

Le modèle institutionnel: hébergement universitaire, exploitation par NSRC et soutien communautaire

RouteViews est hébergé par l’University of Oregon et géré par le Network Startup Resource Center. Les dossiers universitaires actuels placent NSRC au sein des bibliothèques de l’UO. Steve Huter est listé comme directeur de NSRC, Hans Kuhn comme directeur principal de l’infrastructure de recherche et Owen Conway comme ingénieur réseau et coordinateur de peering de RouteViews. L’examen opérationnel et la présentation du projet identifient d’autres membres de l’équipe ainsi que le rôle de peering de Nina Bargisen.

Ce foyer institutionnel donne à RouteViews un soutien juridique, d’emploi, de subvention et administratif sans créer une entité corporative autonome. L’arrangement signifie aussi que la position financière de RouteViews ne peut pas être reconstituée à partir des revenus et comptes du projet, car aucun budget audité, aucune masse salariale, aucune réserve ni bilan distinct n’est publié.

Le modèle de financement combine soutien universitaire et subventions, contributions directes, hébergement en nature, collaboration technique et pairs volontaires. Le soutien historique comprenait la subvention NSF 0323769 pour le projet Oregon Route-Views, une sous-subvention DARPA NETPATH, l’University of Oregon, Cisco, Juniper et Sprint. La liste des soutiens 2025 comprenait Amazon, Catchpoint, Google, ICANN, Internet Society, Internet Society Foundation, MaxMind, NSF, Verisign, des fondations et des donateurs individuels.

Les montants et restrictions de ces contributions ne sont pas publics sous une forme propre à RouteViews. NSRC indique que Google a fourni un financement substantiel et du matériel, et l’University of Oregon a annoncé une subvention NSF de 3 732 343 $ à NSRC. Ces chiffres soutiennent l’environnement institutionnel plus large et ne doivent pas être présentés comme des revenus directs de RouteViews.

L’hébergement en nature est économiquement significatif même lorsqu’il n’apparaît pas dans un budget monétaire. Un hôte de collecteur peut fournir une machine virtuelle, un port, du transit, de l’alimentation, du refroidissement et du temps de personnel. Les pairs volontaires fournissent les données dont dépend le service. La véritable base de ressources de la plateforme est donc répartie entre institutions et réseaux.

Le modèle maximise l’accès public. RouteViews indique que ses données sont librement disponibles, et le site affiche une licence CC BY 4.0. Les conditions propres à un jeu de données et les artefacts historiques doivent néanmoins être vérifiés plutôt que de supposer qu’un seul pied de page régit chaque chemin d’accès. Les contrôles de capacité de l’API et les attentes d’attribution peuvent coexister avec un accès libre.

Des produits commerciaux utiliseraient les données de RouteViews. Les présentations du projet nomment des exemples dans la surveillance et l’intelligence réseau. La réutilisation commerciale ouverte démontre l’impact et peut améliorer les opérations de routage, mais elle crée un problème de passager clandestin. Une entreprise peut construire des services générateurs de revenus sur une archive publique sans redevance de licence obligatoire proportionnelle à son usage.

RouteViews a réagi en demandant aux utilisateurs commerciaux qui réussissent de reconnaître et de soutenir le projet. Aucun tarif commercial obligatoire ni contrat de soutien n’a été identifié. Cela préserve l’ouverture tout en laissant la durabilité dépendre de contributions volontaires, de subventions et d’un engagement institutionnel.

La surface de gouvernance est en conséquence informelle en public. Aucun conseil d’administration dédié à RouteViews, comité consultatif autonome, objectif de niveau de service, processus d’appel contre le retrait d’un pair, politique de rétention publiée ni plan de succession n’a été trouvé. La gouvernance semble fonctionner via la gestion de l’Université et de NSRC, les obligations de subvention, le jugement du personnel et les relations avec les pairs et les hôtes.

Cela peut bien fonctionner lorsque l’institution inspire confiance et que l’équipe est stable. Cela crée aussi des questions à mesure que la dépendance croît. Les utilisateurs commerciaux, les chercheurs et les opérateurs peuvent s’appuyer sur RouteViews comme infrastructure sans avoir de rôle formel dans la définition des priorités de rétention, d’accès ou de résilience. L’absence de société distincte évite une forme de bureaucratie; elle n’élimine pas le besoin d’une gestion transparente d’un service partagé.

Le mécanisme d’impact de RouteViews

L’influence de RouteViews peut être retracée comme une chaîne plutôt que comme une revendication d’autorité. Premièrement, un système autonome exporte volontairement des routes BGP vers un collecteur. Deuxièmement, le collecteur enregistre la vue sélectionnée du plan de contrôle comme état RIB et mises à jour. Troisièmement, RouteViews préserve et distribue les données par fichiers, flux et services. Quatrièmement, opérateurs, chercheurs et éditeurs analysent les observations. Cinquièmement, ces utilisateurs peuvent modifier la surveillance, la réponse aux incidents, le filtrage, les modèles de topologie, la politique ou l’investissement.

Chaque maillon a un décideur distinct. Le réseau contributeur contrôle l’export. RouteViews contrôle la collecte et la publication dans ses systèmes. L’utilisateur en aval contrôle l’analyse. Un opérateur contrôle s’il change sa politique de routage. Une équipe de sécurité contrôle si elle alerte. Un chercheur contrôle la méthodologie. L’impact du projet émerge de l’interopérabilité entre ces décisions.

Cette division est une force, car aucune approbation centrale n’est requise pour que les données deviennent utiles. Un réseau contribue parce qu’il le choisit. Un chercheur télécharge parce que l’archive est ouverte. Un éditeur intègre parce que le format est réutilisable. Un opérateur agit parce que la preuve est convaincante dans son propre contexte.

C’est aussi une limite aux revendications causales. RouteViews peut fournir des preuves utilisées lors d’une enquête sur un détournement sans être l’organisation qui a détecté l’incident en premier ni l’a corrigé. CAIDA peut construire un jeu de données dérivé de RouteViews sans rendre RouteViews responsable de la méthodologie. Un produit commercial peut dépendre de l’archive sans divulguer quelle part de sa production provient de RouteViews.

La forme de pouvoir la plus forte du projet est épistémique. Il façonne ce qui peut être connu du routage interdomaine et quelles questions historiques peuvent être posées. C’est lourd de conséquences, car les décisions d’infrastructure sont contraintes par les preuves disponibles. Une route qui n’a jamais été observée est plus difficile à enquêter; une longue archive peut révéler des schémas invisibles dans les journaux d’un seul opérateur.

Le pouvoir épistémique ne doit pas être confondu avec l’exhaustivité factuelle. L’instrument sélectionne la réalité via la participation des pairs, l’export de politique, le placement des collecteurs et les décisions de stockage. RouteViews mérite la confiance lorsque ces frontières sont documentées, pas lorsqu’elles sont cachées derrière une revendication de vue mondiale.

Le cadre éditorial de Lu Heng est utile ici comme discipline plutôt que comme source factuelle sur RouteViews. La séparation pertinente est entre l’état en cours et l’affirmation institutionnelle. La valeur de RouteViews est démontrée par les collecteurs qui reçoivent des routes, les archives qui préservent les enregistrements et les utilisateurs qui s’y fient. Le projet n’a pas besoin de revendiquer la propriété de la vérité du routage. Sa crédibilité vient de ce qu’il reste une couche d’observation remplaçable, inspectable et bornée.

Pourquoi BTW suit RouteViews

BTW suit RouteViews parce que l’observabilité du routage est une infrastructure. Les routeurs qui transportent le trafic ne sont qu’une partie d’un Internet opérationnel. Les opérateurs ont aussi besoin de systèmes qui montrent comment l’accessibilité est représentée au-delà de leurs propres réseaux, préservent les preuves pendant les incidents et permettent des comparaisons à long terme.

RouteViews est particulièrement important parce qu’il combine un attachement de production au BGP avec une archive historique remontant à 1997. Cette profondeur rend le projet utile pour des questions auxquelles les tableaux de bord commerciaux construits plus tard ne peuvent pas répondre. Il est aussi suffisamment distribué mondialement pour exposer les différences régionales tout en restant transparent sur l’impossibilité d’une couverture complète.

Le projet illustre un principe d’infrastructure plus large: une visibilité partagée peut être créée sans centraliser le contrôle opérationnel. RouteViews ne décide pas des routes pour ses pairs. Il enregistre ce qu’ils choisissent de révéler. Le jeu de données qui en résulte peut soutenir la coordination entre acteurs indépendants tout en préservant leur autorité d’accepter, de rejeter et d’interpréter localement.

Ses faiblesses sont tout aussi instructives. La participation volontaire crée un biais. L’accès ouvert crée une pression de financement. L’hébergement donné crée une dépendance. Les interfaces héritées créent une dette technique. Une petite équipe spécialisée crée un risque de continuité. La croissance du stockage crée un problème de préservation non résolu. Une dépendance commerciale croissante peut dépasser la gouvernance et la contribution.

RouteViews ne doit donc être ni idéalisé comme une carte complète d’Internet ni rejeté comme une archive académique. C’est un système de mesure de production dont les sorties sont devenues intégrées dans la recherche, la surveillance et la sécurité. Son importance réside dans la position intermédiaire: assez proche du routage réel pour fournir des preuves opérationnelles, assez limité pour que chaque utilisateur comprenne ce que les preuves ne contiennent pas.

Preuves principales et questions non résolues

La preuve principale de ce profil est le dossier de recherche approfondi fourni sur RouteViews, qui s’appuie à son tour sur l’examen 2025 de RouteViews de janvier 2026, la politique de peering officielle et la documentation de l’API, les dossiers de l’University of Oregon et de NSRC, des présentations historiques APNIC et NANOG, PeeringDB, les spécifications IETF, la documentation de RIPE RIS, les pages de projet et de ressources de CAIDA, des travaux académiques sur la valeur des points d’observation et le biais de mesure, ainsi que les dépôts publics du projet.

Le dossier soutient l’origine en 1995, la contribution précoce de Randy Bush à MAE-WEST, le rôle précoce principal de David Meyer, l’archive de novembre 1997, la cadence de deux heures de 2001, le modèle de collecteur IXP de 2003, la collecte IPv6, l’hébergement actuel par l’Université et NSRC, AS6447, les intervalles d’archive actuels, les chiffres de sessions et de stockage de janvier 2026, l’architecture API, Looking Glass, Kafka et Bimper et l’expansion des collecteurs de 2025.

Plusieurs faits importants restent non résolus. Aucun nombre exact de collecteurs actifs aligné sur une date n’a été trouvé. Les chiffres d’archive de 50 To et 67 To utilisent des dates ou définitions différentes. Nina Bargisen et Owen Conway sont tous deux publiquement associés à la coordination du peering. Les métadonnées de serveur de route de PeeringDB entrent en conflit avec la politique officielle qui accepte les routes de serveur de route. L’exhaustivité et la parité de production de l’archive Google Cloud ne sont pas établies.

RouteViews ne publie aucun budget autonome, effectif, registre d’utilisateurs commerciaux, historique de disponibilité formel ni tableau de bord d’exhaustivité d’archive.

L’article évite donc plusieurs affirmations. RouteViews n’est pas traité comme un transporteur, un point d’échange Internet, une société constituée séparément, une vue complète du routage mondial, un service automatique d’application contre les détournements ni le propriétaire de chaque collecteur. Les routes complètes ne sont pas décrites comme tous les chemins. Les nombres de sessions ne sont pas convertis en nombres de collecteurs. Les totaux de subventions pour NSRC ou les collaborations avec CAIDA ne sont pas attribués entièrement à RouteViews.

Les sources soutenant le plus directement le profil comprennent:

La question centrale non résolue n’est pas de savoir si RouteViews a de la valeur. L’archive, le réseau de collecteurs et l’usage en aval l’établissent. La question est de savoir si le projet peut préserver son ouverture historique et son honnêteté méthodologique tout en devenant une plateforme de données plus grande, plus rapide et davantage orientée services. Cette issue dépendra du stockage, de la réplication, de la couverture de l’API, de la continuité du personnel, des relations avec les hôtes, de métadonnées transparentes et d’un modèle de financement qui reflète la valeur commerciale aussi bien qu’académique extraite du système.