Résumé

  • AFRINIC enregistre exactement l’AS37599 sous le handle AS37599, avec le nom d’objet ORG-TDEL1-AFRINIC et Teraco Data Environments (PTY) LTD comme titulaire. Le statut active décrit l’objet administratif ; il ne mesure ni la visibilité d’une route ni le fonctionnement d’un service.
  • PeeringDB publie un profil réseau et six connexions d’échange déclarées, tandis que NAPAfrica liste Teraco Data Environments et l’ASN 37599 à JB1, CT1 et DB1. Ces entrées éclairent la coordination publique, sans prouver des sessions actives, du trafic, une capacité utilisable, une diversité physique ou un chemin client.

Le numéro de système autonome fixe d’abord une identité

Un système autonome est un réseau, ou un ensemble de réseaux, qui présente une politique de routage commune au reste d’internet. Son numéro de système autonome, ou ASN, permet de reconnaître ce domaine lorsque des réseaux échangent des informations de joignabilité au moyen de BGP, le Border Gateway Protocol.

Cette unicité a une valeur opérationnelle immédiate. Le mot Teraco peut désigner une entreprise, des services de centre de données ou un contexte d’interconnexion. L’AS37599 désigne, lui, un objet de numéro précis. Avant de chercher une cause ou d’attribuer un incident, les équipes peuvent confirmer qu’elles examinent le bon domaine de routage et la bonne organisation enregistrée.

L’identifiant ne contient pas son propre diagnostic. Il ne dit pas si un préfixe est annoncé à l’instant présent, si un autre réseau accepte cette annonce ou si une application est joignable. Une identité de registre peut être exacte alors que l’état courant reste inconnu. Cette frontière est le point de départ du dossier, pas une réserve à ajouter à la fin.

AFRINIC tient le grand livre de la ressource

L’objet RDAP d’AFRINIC couvre exactement le numéro 37599 : ses valeurs de début et de fin sont toutes deux 37599. Il utilise le handle AS37599, porte le nom ORG-TDEL1-AFRINIC et inscrit Teraco Data Environments (PTY) LTD comme titulaire. Son statut administratif est active.

Deux événements donnent une chronologie au dossier. L’enregistrement est daté du 17 mai 2013 à 09 h 56 UTC. La dernière modification est datée du 5 août 2026 à 10 h 55 UTC. Ces heures appartiennent à l’objet administratif publié par AFRINIC. Elles ne sont ni la date de mise en service d’un routeur, ni l’historique complet des installations, fournisseurs ou politiques de Teraco.

Le registre répond ainsi à une question étroite : quelle organisation AFRINIC associe-t-il actuellement à cette ressource numérique ? Une réponse claire facilite la coordination des questions de routage et d’abus et limite les erreurs d’identité. Le registre agit comme un grand livre vérifiable : il conserve l’unicité, le titulaire et les événements qu’il expose.

Le terme active ne doit pas devenir un voyant vert pour l’infrastructure. AFRINIC ne teste pas une session BGP, une interface, une salle de données ou une application client. Il ne confirme ni trafic, ni performance, ni disponibilité. Le bon usage consiste à prendre le registre au sérieux pour l’identité sans lui attribuer une compétence de surveillance qu’il n’a pas.

Le profil PeeringDB est une déclaration du participant

La réponse réseau de PeeringDB contient une seule ligne pour l’ASN 37599. Elle nomme le réseau Teraco Data Environments, utilise également l’étiquette NAPAfrica, pointe vers le site de Teraco, classe l’entrée comme Network Services et déclare une politique générale de peering Open. Elle indique aussi l’ensemble IRR AS-TERACO.

La même fiche affiche 500 préfixes IPv4 et 100 préfixes IPv6. Ces nombres sont des champs maintenus par le participant dans un répertoire. Ils ne viennent pas d’un collecteur de routes dans cette source. Ils ne disent donc pas quels préfixes sont visibles depuis un point donné, lesquels sont effectivement originés à cet instant ou quelle politique les accepte.

Ces limites n’annulent pas l’utilité du profil. Un opérateur peut comparer le nom, l’ASN, la politique annoncée et l’ensemble IRR avec son inventaire actuel. Une divergence crée une question précise à résoudre. Une concordance n’autorise pas à conclure que le routage en production correspond à la déclaration sans vérifier la couche en fonctionnement.

Six lignes d’échange ne prouvent pas six chemins

La réponse séparée de PeeringDB sur les connexions d’échange contient six lignes pour l’AS37599. Elles couvrent des entrées NAPAfrica IX à Johannesburg, Cape Town et Durban, avec deux lignes distinctes à Durban, ainsi que des entrées MAPS à Johannesburg et Cape Town. Les six portent les indicateurs de répertoire operational=true et is_rs_peer=true.

Deux lignes déclarent 100 000 Mbps : l’une à Johannesburg et l’autre à Durban. Les quatre autres déclarent 10 000 Mbps. Des adresses d’échange sont également publiées. Ces champs donnent à une équipe réseau une liste de vérification concrète : l’ASN est-il attendu sur l’échange, l’adresse correspond-elle à la session prévue et la relation avec le serveur de routes fait-elle toujours partie du plan ?

La réponse n’apporte pas la télémétrie nécessaire pour y répondre. Operational reste un attribut du répertoire, pas un contrôle continu de l’état BGP. La vitesse inscrite n’est ni le trafic actuel, ni la marge disponible, ni la capacité contractuelle. Une adresse d’échange n’expose pas le parcours complet d’un client.

Le nombre de lignes ne mesure pas non plus la résilience. Six connexions logiques peuvent partager de la fibre, de l’énergie, un bâtiment, un réseau amont, un système de gestion ou une équipe d’exploitation. À l’inverse, une protection réelle peut exister sans apparaître dans ces champs. La diversité physique doit être démontrée par les dépendances et les scénarios de panne concernés, pas déduite d’un compteur de répertoire.

Les trois codes de NAPAfrica délimitent une présence publiée

Le répertoire officiel des participants de NAPAfrica liste Teraco Data Environments avec l’ASN 37599 dans des lignes pour JB1, CT1 et DB1. Cette seconde source soutient une affirmation précise : l’échange publie ces entrées de participant pour l’organisation et le numéro.

Elle ne montre pas qu’une session est établie maintenant, qu’un paquet client traverse l’un de ces codes ou que les six lignes PeeringDB correspondent chacune à un chemin indépendant. Elle ne permet pas non plus d’assimiler chaque composant de l’échange NAPAfrica à l’AS37599. Un répertoire de participants décrit une surface de coordination ; il ne remplace pas l’observation des sessions et des routes.

Cette distinction compte pendant un incident. Une entrée peut rester publiée pendant une modification de session. L’absence de données de télémétrie sur la page ne constitue pas davantage la preuve d’une panne. Le répertoire indique où chercher et avec quel identifiant, pas le résultat de la recherche.

Le site de Teraco fournit le contexte de service

Teraco se présente comme une société de Digital Realty et décrit des services de colocation, d’interconnexion et de cloud exchange. Son site situe ce contexte de centres de données à Johannesburg, Cape Town et Durban. Le domaine rejoint celui publié dans PeeringDB et le contexte d’identité des contacts Teraco dans le dossier AFRINIC.

Ce rapprochement confirme une identité organisationnelle étroite. Il ne prouve pas que l’AS37599 transporte tous les services mentionnés. Un opérateur de centres de données peut employer plusieurs ressources réseau, partenaires, plateformes et chemins de livraison. Une page de colocation ne révèle pas le préfixe d’un locataire, la route d’une connexion cloud ou les dépendances physiques derrière un service.

Le site est une description de première partie, pas une mesure indépendante. Il ne suffit pas pour juger la disponibilité, l’efficacité des contrôles de sécurité, la capacité, la continuité ou la performance. Chacun de ces résultats exigerait un service défini, une date, une méthode de test et une observation.

Les cinq sources occupent des couches distinctes

Couche Ce qu’elle peut établir Ce qu’elle ne ferme pas
Objet RDAP d’AFRINIC Numéro, handle, titulaire, statut et événements administratifs Route visible, session, trafic ou état de service
Profil réseau PeeringDB Identité, politique et nombres de préfixes déclarés par le participant Préfixes réellement visibles, capacité ou performance
Six lignes PeeringDB Connexions, adresses, flags et vitesses déclarés Sessions actives, chemins clients et diversité physique
Répertoire NAPAfrica Présence publiée à JB1, CT1 et DB1 Utilisation actuelle par un client ou un service
Site de Teraco Présentation des services et des villes par l’entreprise Dépendance à l’AS37599 et résultat opérationnel

Les couches peuvent se renforcer sur l’identité sans devenir interchangeables. Le registre maintient une ressource unique. Les répertoires exposent les déclarations d’interconnexion. Le site explique le contexte commercial. La réalité courante du routage et du service doit venir d’outils qui observent cette réalité.

Une enquête utile passe du dossier au système en fonctionnement

Un opérateur peut d’abord confirmer que l’AS37599 est toujours l’identité prévue, que l’ensemble AS-TERACO et la politique publiée correspondent au plan, et que les six entrées concernent bien le périmètre examiné. Il peut ensuite consulter l’état des sessions BGP, les routes acceptées et annoncées, des vues de collecteurs nommés et des mesures d’interface sur une période définie.

Un client peut demander quel ASN et quel chemin servent le produit contractuel. Si le service dépend d’un échange, d’une connexion cloud ou d’un site précis, la dépendance doit être définie et vérifiée sans déduire le résultat d’une page publique. Une affirmation de continuité doit s’appuyer sur un test daté et sur les risques partagés pertinents.

Une équipe d’intervention devrait conserver chaque couche dans sa chronologie : identité AFRINIC, déclaration PeeringDB, ligne NAPAfrica, observation de route, télémétrie de session et test de bout en bout. Une route visible ne prouve pas qu’une application répond. Une session établie ne prouve pas une capacité suffisante. Un échec applicatif ne rend pas le registre inexact.

L’absence de ces mesures dans les cinq sources ne prouve aucune panne. Elle indique seulement que le dossier public atteint sa limite. La conclusion défendable reste précise : AFRINIC associe Teraco Data Environments (PTY) LTD à l’AS37599, et PeeringDB et NAPAfrica publient une surface d’interconnexion déclarée. Le routage actuel, le trafic, la diversité physique et les résultats clients demeurent à démontrer.

Points à surveiller

  • un changement du titulaire, du statut administratif, des contacts ou des événements de l’AS37599 chez AFRINIC ;
  • une modification du nom réseau, de la politique, des nombres de préfixes ou de l’ensemble IRR dans PeeringDB ;
  • l’ajout, le retrait ou la modification matérielle d’une des six connexions d’échange déclarées ;
  • un changement des lignes exactes JB1, CT1 et DB1 dans le répertoire NAPAfrica ;
  • une évolution du domaine ou de la présentation publique des services de colocation et d’interconnexion de Teraco ;
  • une preuve autoritative et horodatée de route, de session, d’interface ou de service répondant à une question opérationnelle courante.

Chaque changement doit garder son horodatage et sa couche d’origine. Un événement de registre, une déclaration de participant, une observation BGP et un test de service peuvent être exacts tout en décrivant des objets et des moments différents. C’est cette séparation qui transforme les données publiques en outil de coordination plutôt qu’en garantie non fondée.

Sources