PIT-IX nennt drei Gebäude – und kein einziges davon

Zusammenfassung

• Der Datensatz des Knotens meldet drei Standortverknüpfungen, sechsunddreißig registrierte Netze und einen IX-F-Import von einundvierzig Netzen, aktualisiert am 4. November 2026 um 01:14 Uhr – genug, um die billige Frage zu beantworten: ein Club in einem einzigen Raum ist das nicht.
• Derselbe Datensatz nennt keinen dieser drei Standorte, und AS30365, die Autonome Systemnummer, mit der ein Mitglied tatsächlich eine BGP-Sitzung aufbaut, führt null Standortverknüpfungen, null exchange-Verknüpfungen und überhaupt kein Datum einer Standortverknüpfung. Wer über einen Anschluss nachdenkt, kann nicht erkennen, welches der drei Gebäude den Strom verlieren müsste, damit sein Verkehr stehenbleibt.

Der Datensatz ist nicht dünn. Er trägt den Namen PIT-IX, die Alternativbezeichnung PIT-IX Pittsburgh, den Langnamen Pittsburgh Internet Exchange, die Stadt Pittsburgh und die Kontinentgruppe Nordamerika. Er meldet fac_count 3, net_count 36 und ixf_net_count 41, mit einem IX-F-Importzeitstempel von 2026-11-04T01:14:26Z, also wenige Stunden vor der Lektüre (PeeringDB-Datensatz zum Knoten PIT-IX). Er gibt als Medium Ethernet an, Unicast und IPv6 auf wahr, Multicast auf falsch. Er erklärt eine offene Peering-Politik, keine Anforderung an den Standort, keine Anforderung an Verträge – und im selben Atemzug Servicelevel und Bedingungen als „Not Disclosed“. Der Knoten datiert sich auf 2017-11-07, die letzte Bearbeitung auf 2025-08-05.

Das ist ein Inventar, und ein ordentlich geführtes. Eine Karte ist es nicht.

Drei zu zählen kann fast alles bedeuten

Drei Standorte sind ein echter und ein schwacher Befund. Drei Käfige im selben Gebäude teilen sich eine Stromeinspeisung, eine Kälteanlage, einen Glasfaserzugang und meist auch denselben Kanalverlauf unter derselben Straße. Drei getrennte Gebäude mit eigenen Netzeinspeisungen und eigenen Kabelwegen verhalten sich völlig anders, wenn ein Bagger den falschen Kanal findet. Eine Standortzahl unterscheidet diese beiden Welten nicht, weil die Zahl in beiden dieselbe ist.

Der Organisationsdatensatz füllt genau einen Ort: 1016 North Lincoln Ave, Pittsburgh, Pennsylvania 15233, bei 40.450257, -80.020202, ein Eintrag aus 2017, zuletzt berührt 2022 (PeeringDB-Organisation 18417). Nichts in den überlieferten Datensätzen bindet diese Adresse an einen der drei gezählten Standorte. Sie kann einer davon sein. Sie kann ein Büro sein. Sie kann ein Rechtssitz ohne jede Vermittlungstechnik hinter der Tür sein. Der Leser kann es nicht entscheiden, und der Datensatz bietet nicht einmal eine Vermutung an. Die Mengen für Carriers und Campus sind bei dieser Organisation beide leer, es gibt also nicht einmal einen Transport-Hinweis, an dem sich ziehen ließe.

Die ASN, die das Mitglied konfiguriert, hat leere Spalten

Hier liegt die schärfere Kante. Ein Mitglied von PIT-IX peert nicht mit dem Knotenobjekt. Es konfiguriert eine BGP-Sitzung zu einem Autonomen System, und die Netzliste der Organisation nennt es: AS30365, „PIT-IX Route Servers“, typisiert als Routenserver, regional zugeschnitten, verknüpft mit dem IRR-AS-SET AS-PITIX, mit Prefix-Obergrenzen von 100.000 für IPv4 und 30.000 für IPv6 (PeeringDB-Organisation 18417). Der Netzdatensatz zu dieser ASN zeigt mit der Website auf den Knoten und wiederholt denselben Namen (PeeringDB-Netzdatensatz zu AS30365). Die Registeransicht stimmt beim Inhaber überein: Der Block 29696–30719, von ARIN innerhalb des IANA-Registers der 16-Bit-AS-Nummern zugeteilt, gehört „PITIX - Pittsburgh Internet Exchange“ (RIPE-NCC-AS-Übersicht zu AS30365).

Die Identität ist also aus drei Richtungen bestätigt. Und in genau dem Datensatz, der sie bestätigt, steht fac_count auf 0, ix_count auf 0 und netfac_updated ist leer. Die letzte Aktualisierung der Verknüpfung zwischen Knoten und diesem Netzobjekt datiert auf den 2023-09-14.

Ein Nullfeld ist kein Zeuge. Es beweist nicht, dass der Routenserver nirgends steht; es beweist, dass der Datensatz über seinen Standort keine Aussage trifft. Genau darin liegt das ganze Problem: Das ist der Datensatz, den ein potenzieller Peer, ein Versicherer oder ein Netzwerkingenieur bei einer Prüfung vor dem Anschluss tatsächlich liest. Die Frage, die entscheidet, ob der Verkehr eines Mitglieds den Ausfall eines Gebäudes übersteht – hängt meine Routenserver-Sitzung an derselben physischen Anlage wie mein Port? –, hat in keinem Feld der ASN eine Antwort, die man ihm zu konfigurieren gibt.

Im selben Haushalt gibt es eine zweite ASN, und sie verwischt mehr, als sie klärt: AS400798, „Pittsburgh Internet Exchange Services“, angelegt am 2023-06-28, mit ix_count 1 und fac_count 1 sowie einer Aktualisierung der Knoten-Netz-Verknüpfung vom 2026-03-26. Welche Identität die Mitgliederdienste trägt und welche das Switch-Fabric, steht in keinem überlieferten Feld.

Sechsunddreißig und einundvierzig

Die beiden Netzzahlen unterscheiden sich um fünf, und nichts Überliefertes definiert die Grundgesamtheit der einen oder der anderen. Der Leser kann nicht feststellen, ob der IX-F-Import reine Routenserver-Einträge enthält, ob die eine Zahl Mitglieder und die andere prefixnahe Sitzungen zählt, oder ob die Differenz der gewöhnliche Rückstand zwischen dem eigenen Verzeichnis des Betreibers und dem automatisierten Feed ist. Der IX-F-Zeitstempel belegt, dass am Morgen des 4. November 2026 ein Import lief; er belegt weder Verkehr noch Verfügbarkeit noch die Erfahrung eines einzelnen Mitglieds (PeeringDB-Datensatz zum Knoten PIT-IX). Ein frisches Dateidatum ist keine gesunde Fabric.

Was ein Peer wirklich braucht – und was dieser Datensatz zurückhält

Vier Dinge entscheiden, ob der Redundanzanspruch von PIT-IX versicherbar ist statt nur bewunderbar.

Erstens die Namen. Eine Standortzahl ohne Adressen lässt sich weder mit dem eigenen Fußabdruck eines Mitglieds abgleichen noch mit seinen Carriern oder den Gebäuden, in denen seine Kunden ohnehin sitzen.

Zweitens, ob die Routenserver-Funktion in mehr als einem der drei Standorte existiert. Ein Anycast-Routenserver und getrennte Instanzen je Standort sind zwei verschiedene Produkte mit unterschiedlichem Ausfallverhalten und unterschiedlichen Betriebskosten; der Datensatz schweigt zwischen beiden.

Drittens, ob Port und Routenserver-Sitzung eines Mitglieds gezielt in verschiedene Fehlerdomänen gelegt werden können. Ohne diese Zuordnung verlangt ein Mitglied, das Vielfalt will, ein Versprechen, hinter dem nichts Geschriebenes steht.

Viertens, wie der Verkehr zwischen den Standorten läuft und wer diesen Transport kontrolliert. Die Statistikseite und die Routenserver-Seite des Knotens, beide in den Datensätzen referenziert, wurden für diesen Artikel nicht abgerufen, ebenso wenig die Standortzeilen zu Knoten 1999: Die drei Anfragen lieferten Berechtigungs- und Kapazitätsfehler. Die Standortliste fehlt, weil sie nicht abgerufen wurde, nicht weil jemand ihre Nichtexistenz gezeigt hätte.

Diese Einschränkung gehört neben den Befund und nicht in eine Fußnote, denn sie ist genau der Unterschied zwischen einem Betreiber, der seine Topologie verbirgt, und einem Datensatz, der nie nach ihr gefragt wurde.

Die kommerzielle Seite ist noch trockener. Servicelevel und Bedingungen sind beide als nicht offengelegt markiert. Wer Anschlussoptionen vergleicht, sieht, dass PIT-IX existiert, offen ist und den einen Raum hinter sich gelassen hat. Bei der Resilienz bietet der öffentliche Datensatz eine Zahl, wo eine Karte nötig wäre. Solange die drei Gebäude keine Namen haben und der Routenserver in mindestens zwei von ihnen keine Adresse, lautet die ehrliche Lesart: eine Zählung, und keine Topologie.