Zusammenfassung

  • AFRINIC ordnet AS37599 dem Registranten Teraco Data Environments (PTY) LTD zu und führt das Objekt des autonomen Systems administrativ als aktiv. Das belegt die öffentliche Ressourcenidentität, nicht den aktuellen Zustand von Routen, Sitzungen oder Kundendiensten.
  • PeeringDB veröffentlicht einen Netzdatensatz und sechs erklärte Exchange-Verbindungen; NAPAfrica nennt Teraco Data Environments an JB1, CT1 und DB1. Diese Angaben erleichtern die Koordination, beweisen aber weder Verkehr und nutzbare Kapazität noch physische Vielfalt oder einen bestimmten Kundenpfad.

Die Nummer schafft Eindeutigkeit, keine Betriebsdiagnose

Ein autonomes System ist ein Netz oder eine Gruppe von Netzen, die gegenüber dem übrigen Internet eine gemeinsame Routing-Politik vertritt. Die Autonomous System Number, kurz ASN, gibt dieser Routing-Domain eine eindeutige öffentliche Kennung. Beim Border Gateway Protocol, meist BGP genannt, verwenden Netze solche Nummern, um Informationen über erreichbare Ziele und die dafür vorgesehenen Pfade auszutauschen.

Diese Identität ist für die Praxis wichtig. Wenn mehrere Organisationen, Standorte und technische Systeme an einer Störung beteiligt sein könnten, verhindert eine genaue ASN, dass Teams nur mit ähnlich klingenden Firmennamen arbeiten. Sie grenzt den Gegenstand ein, schafft einen gemeinsamen Referenzpunkt und erleichtert den Abgleich mit Kontakten und Richtlinien. Das ist die Aufgabe eines Registers als belastbares Verzeichnis.

Die ASN ist dennoch kein Sensor. Sie sagt nicht, ob ein Router antwortet, ob ein Netz an einem bestimmten Beobachtungspunkt sichtbar ist oder ob ein Kunde sein Ziel erreicht. Genau diese Trennung macht die öffentliche Evidenz nutzbar: Zuerst wird geklärt, welches Objekt gemeint ist. Danach müssen passende Betriebsdaten die aktuelle Frage beantworten.

AFRINIC dokumentiert die eingetragene Ressourcenidentität

Der RDAP-Datensatz von AFRINIC umfasst genau die autonome Systemnummer 37599. Er verwendet den Handle AS37599, nennt das Objekt ORG-TDEL1-AFRINIC und führt als Registranten Teraco Data Environments (PTY) LTD. Der administrative Status lautet active. Als Registrierungsereignis ist der 17. Mai 2013 verzeichnet, als letztes Änderungsereignis der 5. August 2026.

Damit beantwortet AFRINIC eine klar begrenzte Frage: Welche Organisation ist im öffentlichen Datensatz dieser Nummernressource zugeordnet, und welche Wartungsereignisse weist das Register aus? Eine solche Zuordnung unterstützt eindeutige Kommunikation und nachvollziehbare Pflege. Der Änderungszeitpunkt zeigt, wann das Register ein Ereignis für dieses Objekt verzeichnet hat; er beschreibt nicht jede Änderung an Geräten, Richtlinien, Standorten oder Dienstleistungen.

Auch active ist ein administratives Attribut des Registerobjekts. Es ist kein Live-Signal für BGP, Exchange-Ports, Rechenzentren oder Anwendungen. Aus dem Feld folgt weder, dass AS37599 in diesem Moment Präfixe ankündigt, noch dass eine bestimmte Gegenstelle diese Routen akzeptiert. Umgekehrt ist das Fehlen solcher Messungen im RDAP-Datensatz kein Hinweis auf eine Störung. Das Register misst diese Ebene schlicht nicht.

Das PeeringDB-Netzprofil ist eine Erklärung des Teilnehmers

PeeringDB liefert für ASN 37599 genau einen Netzdatensatz. Er nennt Teraco Data Environments und führt zusätzlich die Bezeichnung NAPAfrica. Der Eintrag verweist auf die Teraco-Website, ordnet das Profil dem Typ Network Services zu, nennt eine offene allgemeine Peering-Policy und führt das IRR-Set AS-TERACO.

Außerdem stehen dort 500 IPv4- und 100 IPv6-Präfixe. Diese Werte sind teilnehmergepflegte Verzeichnisfelder. Sie sind weder eine Auswertung eines Route Collectors noch eine vollständige Liste aktuell sichtbarer Ankündigungen. Aus ihnen lässt sich nicht ablesen, welche Präfixe zu einem bestimmten Zeitpunkt tatsächlich originiert werden, an welchen Blickpunkten sie erscheinen oder welche Richtlinie eine Gegenstelle anwendet.

Für ein Netzteam bleibt das Profil wertvoll. ASN, erwarteter Name, Policy und IRR-Set bilden eine konkrete Prüfliste. Ein Unterschied zwischen dokumentierter Erwartung und aktueller Beobachtung sollte eine gezielte Klärung auslösen. Eine Übereinstimmung ersetzt aber nicht die Prüfung des laufenden Routings. Verzeichnis und Telemetrie beantworten verschiedene Fragen.

Sechs Verbindungszeilen sind nicht automatisch sechs unabhängige Wege

Der gesonderte PeeringDB-Endpunkt für Exchange-Verbindungen enthält sechs Zeilen zu AS37599. Genannt werden NAPAfrica IX in Johannesburg, Kapstadt und Durban, wobei Durban zweimal erscheint, sowie MAPS in Johannesburg und Kapstadt. Alle sechs Zeilen tragen die vom Teilnehmer gepflegten Kennzeichnungen operational und is_rs_peer.

Zwei Zeilen nennen 100.000 Mbps, vier weitere 10.000 Mbps. Hinzu kommen Exchange-Adressen. Diese Felder helfen bei präzisen Folgefragen: Passt die veröffentlichte Adresse noch zur geplanten Sitzung? Soll die Verbindung über einen Route Server laufen? Welche der Zeilen gehört zu dem Dienst oder Vorfall, der gerade untersucht wird?

Die Angaben beantworten diese Fragen nicht selbst. Ein operational-Flag ist keine fortlaufende Sitzungsüberwachung. Eine eingetragene Geschwindigkeit zeigt weder aktuellen Verkehr noch freie Reserven, vertraglich verfügbare Kapazität oder Verhalten während eines Fehlers. Auch die Zahl der Zeilen erlaubt keinen Schluss auf sechs physisch unabhängige Pfade. Glasfaser, Strom, Gebäude, Upstreams, Managementsysteme oder Betriebsteams können gemeinsame Abhängigkeiten haben, die in einem öffentlichen Interconnection-Verzeichnis nicht erscheinen.

Wer Resilienz beurteilen will, braucht daher eine definierte Ausfallannahme und Nachweise zu den tatsächlichen Abhängigkeiten. Die Verzeichniszeilen können die Prüfung strukturieren; sie können physische Diversität nicht stellvertretend beweisen.

Die NAPAfrica-Liste bestätigt veröffentlichte Teilnehmerzeilen

Auf der eigenen Teilnehmerseite führt NAPAfrica Teraco Data Environments mit ASN 37599 bei JB1, CT1 und DB1. Das stützt eine enge Aussage: Das Exchange-Verzeichnis veröffentlicht diese Kombination aus Teilnehmer, ASN und drei Standortcodes.

Nicht belegt ist damit, dass jede dazugehörige BGP-Sitzung gerade etabliert ist oder dass die Pakete eines bestimmten Kunden einen dieser Punkte passieren. Die gemeinsame Nennung von Teraco und NAPAfrica bedeutet auch nicht, dass AS37599 sämtliche Route Server, Plattformkomponenten oder Dienste des Internetknotens repräsentiert. Ein Teilnehmerverzeichnis beschreibt Koordinationspunkte; es ist keine vollständige Eigentums- oder Kontrollkarte.

Gerade in einer Störung ist diese Grenze wichtig. Ein Verzeichniseintrag kann bestehen bleiben, während eine Sitzung geändert wird oder ein Dienst beeinträchtigt ist. Umgekehrt belegt das Fehlen öffentlicher Live-Daten keinen Ausfall. Die Liste zeigt, wo eine Untersuchung ansetzen kann, nicht wie sie ausgeht.

Die Unternehmenswebsite setzt den Dienstekontext

Teraco beschreibt sich auf der eigenen Website als Unternehmen von Digital Realty und stellt Colocation, Interconnection und Cloud Exchange sowie Rechenzentrumsstandorte in Johannesburg, Kapstadt und Durban dar. Die Domain passt zum Website-Feld bei PeeringDB und zu den Teraco-Kontakten im AFRINIC-Objekt. Dadurch entsteht eine schmale, nachvollziehbare Identitätsbrücke zwischen Ressourcenregister, Interconnection-Verzeichnis und Unternehmensdarstellung.

Die Website ordnet jedoch nicht automatisch jedes Angebot AS37599 zu. Ein Rechenzentrumsbetreiber kann mehrere Netzressourcen, Plattformen, Partner und Lieferpfade einsetzen. Eine Produktbeschreibung zeigt auch nicht, welchen Pfad ein Kunde nutzt oder welche technischen und physischen Abhängigkeiten dahinterliegen.

Als Quelle aus erster Hand erklärt die Website, was Teraco öffentlich anbietet. Sie ist keine unabhängige Messung von Verfügbarkeit, Sicherheit, Durchsatz, Resilienz oder Kontinuität. Aussagen zu solchen Ergebnissen benötigen einen abgegrenzten Dienst, einen Zeitpunkt, eine Methode und ein beobachtetes Resultat.

Eine Prüfreihenfolge für Betrieb, Kunden und Incident Response

Netzbetreiber können zunächst bestätigen, dass AS37599 weiterhin die erwartete Routing-Identität ist. Danach lässt sich prüfen, ob die sechs veröffentlichten Exchange-Zeilen, Adressen, Policies und das IRR-Set noch zum vorgesehenen Design passen. Erst anschließend beantworten aktuelle BGP-Daten die Betriebsfragen: Welche Sitzungen sind etabliert? Welche Routen werden akzeptiert und angekündigt? Was sehen benannte Route Collectors? Welche Interface-Messungen gelten für welchen Zeitraum?

Kunden sollten nach der ASN und dem tatsächlichen Lieferpfad ihres vertraglichen Produkts fragen. Ist ein bestimmter Internetknoten, Cloud-Anschluss oder Standort relevant, sollte der Anbieter die Abhängigkeit auf den Dienst beziehen können. Für Aussagen über Ausfallsicherheit braucht es zusätzlich Belege darüber, welche Komponenten Glasfaser, Strom, Gebäudezugang, Upstream oder Steuerung teilen.

Incident-Responder sollten jede Beobachtung mit Zeit, Blickpunkt und Evidenzart festhalten. AFRINIC klärt die öffentliche Ressourcenidentität. PeeringDB und NAPAfrica zeigen erklärte Koordinationspunkte. Sitzungsdaten und Routing-Beobachtungen beschreiben das laufende Netz. End-to-End-Tests prüfen schließlich DNS, Zugang, Anwendung und externe Abhängigkeiten des betroffenen Dienstes.

Diese Reihenfolge schützt vor vorschneller Attribution. Eine sichtbare Route beweist keine funktionierende Anwendung. Eine etablierte Sitzung belegt keine ausreichende Kapazität. Ein fehlgeschlagener Diensttest macht den Registereintrag nicht falsch. Jede Ebene trägt nur den Schluss, für den sie gebaut oder gemessen wurde.

Was weiter beobachtet werden sollte

  • Änderungen am Registranten, administrativen Status, den Kontakten oder Ereignisdaten von AS37599 bei AFRINIC;
  • Änderungen an Name, Policy, Präfixfeldern oder IRR-Set im PeeringDB-Netzprofil;
  • Ergänzungen, Entfernungen oder wesentliche Feldänderungen bei den sechs erklärten Exchange-Verbindungen;
  • Änderungen an den genauen Teilnehmerzeilen JB1, CT1 und DB1 bei NAPAfrica;
  • Änderungen an der Teraco-Domain oder der öffentlichen Darstellung von Colocation und Interconnection;
  • autoritative, datierte Routing-, Sitzungs-, Interface- oder Servicedaten, die eine konkrete Betriebsfrage beantworten.

Der belastbare Schluss bleibt damit eng und nützlich: AFRINIC verbindet Teraco Data Environments (PTY) LTD mit AS37599, während PeeringDB und NAPAfrica eine erklärte Interconnection-Oberfläche veröffentlichen. Der aktuelle Routingzustand, Verkehr, physische Vielfalt und Kundenergebnisse sind durch diese Einträge allein nicht bewiesen.

Quellen