Zusammenfassung

  • Der APNIC-RDAP-Eintrag ordnet AS136022 Janani Technology zu und führt das Registerobjekt als active. Das ist ein administrativer Status der Nummernressource, kein Beleg für laufende Routen, BGP-Sitzungen, Geräte oder Dienste.
  • Das erfasste PeeringDB-Profil enthält genau eine Zeile für die ASN, aber keine Exchange-LAN-Verbindungen; zudem bleiben Website, Netztyp, allgemeine Peering-Policy, IRR-AS-Set sowie IPv4- und IPv6-Präfixzahlen leer. Fehlende Erklärungen sind keine Messung dafür, dass Peering, Adressressourcen oder Betrieb fehlen.
  • Die eingefrorene RIS-Antwort für den 7. August 2026 um 00:00 UTC weist für qualifizierende Routen eine IPv4-Sichtbarkeit von 326/327 und eine IPv6-Sichtbarkeit von 320/320 aus. Diese Werte gelten nur für den genannten Zeitpunkt, die aufgeführten Peers und die Ausschlussschwelle; sie belegen weder universelle Erreichbarkeit und Route Authorization noch Kapazität, Resilienz oder Kundendienst.

AS136022 schafft einen eindeutigen Bezug zwischen den Quellen

Ein autonomes System ist ein Netz oder eine Gruppe von Netzen, die nach außen eine gemeinsame Routing-Politik vertritt. Die Autonomous System Number, kurz ASN, gibt dieser Routing-Domain eine eindeutige öffentliche Kennung. Über das Border Gateway Protocol (BGP) tauschen Netze Informationen darüber aus, welche Adressbereiche über welche Routing-Domain erreichbar sein können.

Mit AS136022 lässt sich prüfen, ob der Verzeichniseintrag von Janani Technology, das APNIC-Objekt, das PeeringDB-Profil und die RIS-Beobachtung dieselbe Nummernressource betreffen. Das reduziert die Gefahr, einen ähnlichen Firmennamen oder ein anderes Netz in eine Untersuchung einzubeziehen.

Die Kennung selbst ist jedoch kein Sensor. Auch bei eindeutigem Gegenstand bleibt offen, ob zu einem bestimmten Zeitpunkt eine Route angekündigt, von einer Gegenstelle akzeptiert oder für eine Anwendung nutzbar war. Nach der Identitätsprüfung muss deshalb die Evidenz folgen, die zur jeweiligen Betriebsfrage passt.

APNIC RDAP ist das administrative Register

RDAP, das Registration Data Access Protocol, stellt öffentliche Registerinformationen zu Internet-Nummernressourcen strukturiert bereit. In der eingefrorenen APNIC-Antwort sind Start- und Endnummer beide 136022, der Handle lautet AS136022, der Objektname JANANITECHNOLOGY-AS-AP. Unter den Entitätsnamen steht Janani Technology.

Als Registrierungsereignis nennt die Antwort den 3. Februar 2019 um 08:31:56 UTC. Das letzte Änderungsereignis ist auf den 18. Januar 2021 um 03:52:25 UTC datiert. Diese Zeiten gehören zur Verwaltungsgeschichte des Objekts. Sie bezeichnen nicht automatisch die Inbetriebnahme eines Routers, eine Routing-Änderung, den Beginn eines Angebots oder eine Auswirkung auf Kunden.

Auch active ist ausschließlich als Registerstatus zu lesen. Das Feld prüft weder, ob Geräte laufen, noch ob eine BGP-Sitzung besteht, eine Route autorisiert ist oder ein Dienst funktioniert. Ein Register schafft Eindeutigkeit und Nachvollziehbarkeit für Nummernressourcen; den Zustand des ausgeführten Netzes ersetzt es nicht.

Ein spärliches PeeringDB-Profil ist eine Erklärungslücke

Die erfasste PeeringDB-Antwort enthält für ASN 136022 eine Netzzeile. Ihre record id ist 40097, der Name lautet Janani Technology, der Profilstatus ok. Als Aktualisierungszeit steht der 4. April 2026 um 16:50:22 UTC im Datensatz.

Die eingebettete Liste der netixlan-Verbindungen ist leer. Auch Website, Informationstyp, allgemeine Peering-Policy, IRR-AS-Set sowie IPv4- und IPv6-Präfixzahlen sind in dieser Antwort leer oder null. Das beschreibt den Inhalt des erfassten Profils, nicht den vollständigen Betrieb des Netzes.

Aus null Exchange-LAN-Zeilen folgt nicht, dass Janani Technology an keinem Internet Exchange präsent ist, keine bilaterale Verbindung nutzt oder an anderer Stelle nicht peert. Ein leeres Policy-Feld belegt weder eine offene noch eine selektive oder restriktive Praxis. Fehlende Präfixzahlen beweisen nicht, dass die ASN keinen Adressraum oder keine Routen hat.

Ebenso ist ok nur der Status der PeeringDB-Zeile. Er ist keine Telemetrie für BGP-Sitzungen und kein Health Check für Router oder Dienste. Das Profil bleibt als Koordinationspunkt nützlich, solange seine Lücken als nicht veröffentlichte Angaben und nicht als negative Betriebsmessungen behandelt werden.

Die eingefrorene RIS-Sicht hat Zeit, Nenner und Schwelle

RIS sammelt BGP-Informationen von teilnehmenden Beobachtungspunkten. Der hier verwendete routing-status-Datensatz hat ein query_time vom 7. August 2026 um 00:00 UTC. Für qualifizierende Routen nennt er Sichtbarkeit bei 326 von 327 aufgeführten IPv4-Full-Feed-Peers und bei 320 von 320 aufgeführten IPv6-Full-Feed-Peers.

Im Feld announced space stehen ein IPv4-Präfix mit 256 Adressen sowie zwei IPv6-Präfixe, entsprechend zwei /48-Einheiten. Außerdem nennt die Antwort einen beobachteten Nachbarn. Dieser Wert von 1 gehört zum Modell des Endpunkts. Er ist keine Zahl direkter kommerzieller Peers, Verträge, Exchange-Sitzungen, Standorte oder physisch unabhängiger Wege.

Die Antwort weist ausdrücklich darauf hin, dass Routen ausgeschlossen werden, die von weniger als zehn RIS-Full-Feed-Peers gesehen wurden. Die beiden Sichtbarkeitsquoten müssen daher zusammen mit diesem Schwellenwert, dem Zeitpunkt, der Adressfamilie und dem konkreten Kollektorsatz gelesen werden.

326/327 und 320/320 sind präzise Aussagen über die zurückgegebene Beobachtung. Sie garantieren keine weltweite Erreichbarkeit, Route Authorization, Pfadpräferenz, geringe Latenz, freie Kapazität, Ausfallsicherheit oder funktionierende Kundenanwendung. Sichtbare Routen und ein erreichbarer Dienst sind verwandte, aber nicht identische Fragen.

Abfragezeit, First seen und Last seen bleiben getrennt

Das Last-seen-Feld der Antwort nennt 103.134.41.0/24 mit Origin 136022 und dem Zeitpunkt 7. August 2026, 00:00 UTC. Das First-seen-Feld betrifft dagegen 103.134.42.0/24 und nennt den 13. Februar 2019 um 16:00 UTC.

Dass query_time und Last-seen-Zeit übereinstimmen, macht sie nicht zu demselben Feld. Query time beschreibt den Kontext des zurückgegebenen Routing-Status. Last seen ist ein vom Endpunkt ausgewähltes Präfixfeld; First seen ist ein anderes historisches Feld für ein anderes Präfix. Ohne eine dafür geeignete Route-History dürfen daraus weder Netzstart und Unterbrechung noch eine lückenlose Ankündigung konstruiert werden.

Auch eine Kollektorbeobachtung mit Origin-ASN beweist nicht automatisch, dass der Adressinhaber die Ankündigung autorisiert hat oder eine gültige Route-Origin-Autorisierung vorlag. Für eine Autorisierungsfrage braucht es die entsprechenden Register- und Sicherheitsnachweise.

Eine belastbare Prüfung ergänzt Schicht für Schicht

Zuerst wird AS136022 als Gegenstand festgehalten. Dann lässt sich prüfen, ob Nummer, Objektname und Entitätsname bei APNIC zum Janani-Technology-Verzeichniseintrag passen. Dieser Schritt klärt die administrative Identität und verhindert Namensverwechslungen.

Danach werden in PeeringDB nur die tatsächlich vorhandenen Erklärungen gelesen. Leere Felder bleiben offene Fragen. Soll eine konkrete Exchange-Verbindung oder Sitzung geprüft werden, müssen autorisierte Betriebsquellen zusätzlich Konfiguration, Vertrag, Sitzungsstatus sowie empfangene und angekündigte Routen belegen.

Für eine Routing-Frage gehören Kollektorprodukt, Query time, Adressfamilie, Peer-Nenner, Ausschlussschwelle und Präfixe in die Dokumentation. Für Route Authorization kommen die passenden Autorisierungsdatensätze hinzu. Eine Frage zur Kundenerfahrung erfordert zeitlich abgestimmte End-to-End-Tests und Anwendungsbeobachtungen.

APNIC-Registrierung, PeeringDB-Profil und eingefrorene RIPE-RIS-Momentaufnahme sind unterschiedliche Evidenzschichten. Keine davon beweist allein eine laufende Peering-Sitzung, universelle Erreichbarkeit, Route Authorization, Kapazität, Resilienz oder Kundendienst.

Was die öffentlichen Datensätze nicht belegen

Die vier Quellen stützen die administrative Zuordnung von Janani Technology zu AS136022, den Inhalt des erfassten PeeringDB-Profils und eine zeitlich begrenzte RIS-Beobachtung. Nicht belegt sind die angebotenen Dienste, das Betriebsgebiet, Kunden, Standorte, Geräte, Upstream-Eigentum, physische Topologie, Unternehmensgröße oder Marktposition.

Offen bleiben außerdem Exchange-Präsenz, Route-Server-Beziehung, Sitzungszustand, Verkehr, Durchsatz, Latenz, Kapazität, Fehlerursache, physische Diversität, Resilienz und Servicequalität. Der Wert öffentlicher Daten liegt hier in einer überprüfbaren Realitätsschicht: benannte Objekte, veröffentlichte Erklärungen und methodisch begrenzte Beobachtungen. Belastbare Betriebsurteile brauchen zusätzliche, zeitlich und sachlich passende Evidenz.

Worauf künftig zu achten ist

  • Änderungen am Objektnamen, an der Entitätszuordnung, am Registerstatus oder an den Ereignisdaten von AS136022 bei APNIC;
  • neue oder geänderte Angaben zu Name, Policy, Präfixzahlen und Exchange-Verbindungen im PeeringDB-Profil von Janani Technology;
  • spätere Beobachtungen, die Query time, Adressfamilie, RIS-Peer-Nenner und die Ausschlussschwelle vollständig ausweisen;
  • Registerinformationen zur Route-Origin-Autorisierung, falls eine Autorisierungsfrage untersucht wird;
  • autorisierte Sitzungsdaten oder dienstspezifische, zeitgestempelte Tests, wenn es um Peering oder Kundenerfahrung geht.

Quellen