Zayo Group, LLC und AS6461: Was kann ein Glasfaser-Backbone über

Zusammenfassung

Öffentliche Routing-Beobachtungen zeigten AS6461 zu genau angegebenen Zeitpunkten im August 2026 aus Sicht der einbezogenen Messpunkte als breit sichtbar. Das ist ein starkes Indiz für eine aktive Routing-Präsenz, aber kein Beweis für universelle Erreichbarkeit oder die Einhaltung einer Kundenvereinbarung.
Ein gültiges Ergebnis einer Route Origin Authorisation (ROA) für genau ein Präfix, ein großer angegebener Glasfaser-Footprint sowie dokumentierte Optionen wie Bidirectional Forwarding Detection (BFD), Multihoming, BGP-Communities und eine Peering-Richtlinie belegen unterschiedliche Fähigkeiten. Erst ein konkretes, vermessenes und getestetes Servicedesign kann zeigen, ob daraus Kontinuität für einen Kunden entsteht.

Die wichtigste Trennung betrifft vier Ebenen. Register und Verzeichnisse halten Namen, Kontakte und Nummernressourcen fest. Routing-Kollektoren beobachten, welche Wege ihre Messpunkte zu einer bestimmten Zeit sehen. RPKI-Daten können für einen bestimmten Ursprung und ein bestimmtes Präfix eine kryptografisch prüfbare Autorisierung anzeigen. Anbieterunterlagen beschreiben Produkte, technische Optionen und betriebliche Regeln. Keine dieser Ebenen darf stillschweigend die anderen vertreten.

Auch die Bezeichnungen müssen getrennt bleiben. RIPE NCC führt einen Mitgliedseintrag mit dem Namen Zayo Group, LLC. PeeringDB zeigt die Organisation Zayo Group und das Netz Zayo mit AS6461. ARIN nennt den Autonomen Systemeintrag ZAYO-6461, führt Zayo Bandwidth als Registrant und enthält operative Kontakte mit der Organisationsangabe Zayo Group. Historische SEC-Unterlagen verbinden Zayo Group, LLC vorsichtig mit der früheren Geschäftsbereichsbezeichnung Zayo Bandwidth; aktuelle Gleichheit aller Bezeichnungen lässt sich daraus nicht ableiten.

Verzeichniseintrag: Zayo Group, LLC

Das Alltagsproblem hinter der technischen Frage

Eine Klinikgruppe möchte zwei Standorte, ein Rechenzentrum und mehrere Cloud-Dienste zuverlässig verbinden. Im Angebot steht ein großer Backbone, also ein überregionales Kernnetz, dazu BGP, Schutzoptionen und eine hohe verfügbare Bandbreite. Für eine nicht technisch arbeitende Einkaufsabteilung klingt das nach Ausfallsicherheit. Für die Netzwerkabteilung ist es zunächst nur eine Liste möglicher Bausteine.

Der Unterschied zeigt sich beim ersten realen Fehler. Zwei Leitungen können auf zwei Rechnungen erscheinen und trotzdem durch denselben Kabelkanal ins Gebäude gelangen. Sie können an unterschiedlichen Ports enden, aber dieselbe Hardware oder Stromversorgung nutzen. Sie können physisch getrennt sein, während eine fehlerhafte Routing-Regel beide logischen Wege gleichzeitig unbrauchbar macht. Und sie können im Routing sichtbar bleiben, obwohl der Dienst hinter dem Anschluss nicht mehr antwortet.

Ein großes Backbone kann für all diese Fälle bessere Gestaltungsoptionen bieten. Es kann mehr Städte, Netzknoten und Verbindungen zu anderen Betreibern umfassen. Daraus folgt aber nicht, dass genau der Anschluss der Klinik jede dieser Optionen nutzt. Der entscheidende Satz lautet deshalb nicht: „Der Anbieter verfügt über sehr viel Glasfaser.“ Er lautet: „Diese beiden konkreten Wege sind gegen diese benannten Fehler getrennt, und wir haben ihr Verhalten unter kontrollierten Bedingungen beobachtet.“

Routenkontinuität ist zudem nicht identisch mit Geschäftskontinuität. Eine Route kann nach wenigen Sekunden wieder erscheinen, während eine Anwendung noch Minuten benötigt, um Sitzungen neu aufzubauen. Ein Routing-Protokoll kann fehlerfrei arbeiten, während ein DNS-Dienst, eine Firewall oder ein Identitätssystem ausfällt. Umgekehrt kann ein externer Messpunkt eine Routenänderung registrieren, ohne dass Endkunden eine Unterbrechung bemerken. Gute Prüfung verbindet daher physische Wege, logisches Routing, Anwendungen, Betriebsprozesse und Vertragsdefinitionen.

Vier Namen, vier Quellenkontexte

Bei der Identität beginnt die Sorgfalt mit der Frage: Wer sagt welchen Namen und zu welchem Zweck?

Der Mitgliedereintrag des RIPE NCC verwendet Zayo Group, LLC. Er belegt, dass dieser Name in diesem Mitgliedsverzeichnis steht. Er misst weder den Betrieb von AS6461 noch die Qualität einer einzelnen Leitung. Der Pfad der Seite enthält weiterhin eine ältere Bezeichnung, und die Kontaktdaten allein eignen sich nicht für eine Aussage über aktuelle gesellschaftsrechtliche oder operative Zuständigkeiten.

PeeringDB verwendet zwei Ebenen. Das öffentliche Profil nennt das Netz Zayo und ordnet ihm die autonome Systemnummer 6461 zu. Als Organisation erscheint Zayo Group. PeeringDB ist für die Planung von Zusammenschaltungen wertvoll, weil Netzbetreiber dort Informationen zu Peering, Standorten, Kontakten und Richtlinien pflegen. Dennoch bleiben es von Betreibern gepflegte Verzeichnisdaten. Ein Feld „Operational“ ist keine gemessene Verfügbarkeitsquote. Zwei unterschiedliche Webadressen für das Profil sind außerdem zwei Ansichten desselben Datensatzes und keine zwei unabhängigen Bestätigungen.

ARIN wiederum führt den Eintrag des autonomen Systems AS6461 unter der Bezeichnung ZAYO-6461. Im Registrantenfeld steht Zayo Bandwidth; in darunterliegenden operativen Kontakten wird Zayo Group als Organisation genannt. Der Datensatz belegt diese Zuordnungen im Nummernregister. Er beweist nicht, dass Zayo Bandwidth heute eine eigenständige juristische Person ist oder dass die Bezeichnung rechtlich vollständig mit Zayo Group, LLC gleichgesetzt werden kann.

Zwei SEC-Unterlagen helfen bei der historischen Einordnung. Der Jahresbericht für das Geschäftsjahr 2019 identifiziert Zayo Group, LLC als Gesellschaft mit beschränkter Haftung nach dem Recht von Delaware und beschreibt sie zu diesem Zeitpunkt als operatives Mutterunternehmen von Tochtergesellschaften. Ein Quartalsbericht aus dem Jahr 2013 erklärt, Zayo Group, LLC habe historisch einen Geschäftsbereich namens Zayo Bandwidth betrieben und diesen früheren Bereich ab Januar 2013 in mehrere Berichtssegmente gegliedert. Das ist eine belastbare historische Verbindung.

Es ist keine aktuelle Erklärung, dass jede heutige Registrierung mit „Zayo Bandwidth“ exakt dieselbe juristische Einheit bezeichnet.

Eine öffentliche Mitteilung der US-amerikanischen Federal Communications Commission vom 25. Juni 2026 nennt Zayo Group, LLC als Gesellschaft nach dem Recht von Delaware und als Inhaberin der dort bezeichneten internationalen Section-214-Berechtigung. Der Kontext ist ein noch zu prüfender Antrag auf Kontrollübertragung. Die Mitteilung authentifiziert den regulatorischen Namen und den beschriebenen Genehmigungskontext. Sie bewertet weder die Leistungsfähigkeit von AS6461 noch die Zuverlässigkeit eines Netzdienstes.

In den Produkt- und Technikunterlagen dominiert die Marke Zayo. Deshalb bleiben in diesem Text die Formulierungen bewusst quellennah: „RIPE NCC führt Zayo Group, LLC“, „PeeringDB führt Zayo und Zayo Group“, „ARIN führt Zayo Bandwidth“ und „Zayo beschreibt“. Das ist keine sprachliche Pedanterie. Im Störungsfall müssen Vertragspartner, Routing-Verantwortliche und Eskalationsstellen eindeutig zugeordnet sein.

Die wichtigsten Begriffe in verständlicher Sprache

Eine autonome Systemnummer, kurz ASN, ist eine öffentliche Kennung für ein Netz, das mit anderen selbstständig verwalteten Netzen Routing-Informationen austauscht. AS6461 ist eine solche Kennung. Eine ASN verrät nicht, wie viele Glasfasern ein Netz besitzt, welche juristische Gesellschaft jeden Dienst erbringt oder wie ein Kundenanschluss intern aufgebaut ist.

Das Border Gateway Protocol, kurz BGP, ist das Verfahren, mit dem Netze bekannt geben, welche IP-Adressblöcke über sie erreichbar sind, und Wege zwischen Netzen auswählen. Eine BGP-Route ähnelt einem Wegweiser: Sie zeigt einen möglichen Weg zu einem Ziel. Sie garantiert nicht, dass eine Anwendung am Ziel funktioniert, dass zwei Wege physisch getrennt sind oder dass jedes Paket ohne Verlust ankommt.

Die Resource Public Key Infrastructure, kurz RPKI, ist ein kryptografisches System, das bestimmte Aussagen über den zulässigen Ursprung einer IP-Route prüfbar macht. Es verschlüsselt keinen Kundenverkehr. Seine hier relevante Funktion ist die Ursprungsvalidierung: Passt das Netz, das ein Präfix ankündigt, zu einer signierten Freigabe?

Eine Route Origin Authorisation, kurz ROA, ist das signierte Objekt dieser Freigabe. Es nennt eine ASN, ein Präfix und häufig die größte zulässige Präfixlänge. Für die konkrete Kombination aus AS6461 und 64.125.0.0/16 meldete der erfasste RIPEstat-Aufruf den Status „valid“. Das passende ROA nannte Ursprung 6461, das Präfix /16 und eine maximale Länge von 16. Diese Aussage gilt genau für dieses Paar. Sie ist weder eine Prüfung aller AS6461-Präfixe noch eine Autorisierung jedes Zwischennetzes im Pfad.

Eine Internet Routing Registry, kurz IRR, ist ein Verzeichnis für Routing-Richtlinien. Betreiber können daraus Filter ableiten, müssen die Einträge aber aktuell halten und mit ihrer tatsächlichen Routing-Absicht abgleichen. Zayos Interconnection-Richtlinie von 2022 verlangt nach eigener Aussage IRR-Daten und/oder gültige RPKI-ROAs und sieht die Ablehnung RPKI-ungültiger Ankündigungen vor. Das dokumentiert eine Regel, nicht ihre fehlerfreie Umsetzung in jeder einzelnen Sitzung.

Eine private Netzkopplung, auf Englisch Private Network Interconnection oder kurz PNI, ist eine direkte Verbindung zwischen zwei Netzen statt einer Kopplung über die gemeinsam genutzte Vermittlung eines öffentlichen Internetknotens. Eine PNI kann dedizierte Kapazität und eine klare bilaterale Betriebsbeziehung bieten. Sie ist jedoch nicht automatisch geografisch getrennt. Zwei direkte Verbindungen können dieselbe Gebäudeeinführung, denselben Glasfaserstrang oder dieselbe Stromversorgung teilen.

Multihoming bedeutet im Allgemeinen, mehr als eine Verbindung oder mehr als einen Routing-Weg vorzusehen. Bidirectional Forwarding Detection, kurz BFD, ist ein Verfahren, mit dem bestimmte Weiterleitungsfehler zwischen Systemen schneller erkannt werden können. Eine BGP-Community ist eine Kennzeichnung an einer Route, mit der Richtlinienwünsche oder Eigenschaften signalisiert werden. Alle drei Werkzeuge können Teil eines robusten Designs sein. Keines zeigt allein, ob es für den betreffenden Kunden bestellt, korrekt eingerichtet und erfolgreich getestet wurde.

Was die zeitgebundenen Routing-Daten tatsächlich zeigen

Die Routing-Beobachtungen sind der Teil der Beweiskette, der am nächsten am laufenden Internet liegt. Gerade deshalb müssen Uhrzeit und Beobachterumfang erhalten bleiben.

Am 5. August 2026 um 16:00 UTC meldete die AS-Übersicht von RIPEstat AS6461 als angekündigt. Der Abruf der angekündigten Präfixe betrachtete ein ausgewähltes Fenster vom 22. Juli bis zum 5. August 2026 und enthielt 234 Präfixdatensätze. Diese Zahl beschreibt das Ergebnis dieses Endpunkts in diesem Zeitraum. Sie ist weder ein unveränderliches Inventar noch ein Beleg dafür, dass jeder Adressblock derselben juristischen Einheit gehört.

Zum Abfragezeitpunkt 5. August 2026, 16:00 UTC, zeigte der Routing-Status Sichtbarkeit bei 326 von 326 einbezogenen IPv4-Peers des RIPE Routing Information Service und bei 322 von 322 IPv6-Peers. In der Ansicht des angekündigten Adressraums standen 210 IPv4- und 13 IPv6-Präfixe. Innerhalb dieses Beobachternetzes war die Sichtbarkeit also breit.

„326 von 326“ bedeutet aber nicht „von jedem Anschluss der Welt erreichbar“. Die Messung umfasst die Peers, die in der Ansicht des Dienstes enthalten waren. Mobilfunknetze, Unternehmensanschlüsse, Cloud-Regionen oder einzelne Kundenstandorte können andere Erfahrungen machen. Der Wert sagt auch nichts über Latenz, Paketverlust, Kapazitätsengpässe oder die Gesundheit einer Anwendung aus.

Ein weiterer RIPEstat-Schnappschuss vom 5. August 2026 um 23:59:52 UTC enthielt 76.627 BGP-Routendatensätze und darunter Pfade, die in AS6461 endeten. 76.627 ist keine Zahl physisch getrennter Glasfaserwege und keine Zahl eindeutiger Kunden. Routing-Kollektoren können dasselbe Ziel aus vielen Blickwinkeln sehen; dadurch entstehen mehrere Datensätze. Als Kontinuitätskennzahl wäre die Zahl ungeeignet.

Cloudflare Radar liefert eine weitere Beobachterperspektive. Die am 6. August erfasste Seite bezeichnet AS6461 als ZAYO-6461 und Zayo Bandwidth. Sie erläutert, dass die Ansicht Informationen über angekündigte Präfixe und RouteViews-Kollektoren zusammenführt. Das stützt die öffentliche Routing-Identität aus einer weiteren Quelle. Auch diese Ansicht ist kein vollständiges Topologiemodell, keine juristische Feststellung und keine Messung eines kundenspezifischen Service Level Agreement (SLA).

Zeitstempel verhindern drei häufige Fehler. Erstens verändern sich Routen, Präfixe und Messpunkte. Zweitens beantworten ein zweiwöchiges Präfixfenster, ein Sichtbarkeitsstatus und eine Routing-Tabelle unterschiedliche Fragen und müssen nicht dieselbe Anzahl liefern. Drittens darf eine historische Beobachtung nicht als dauerhafte Zusage formuliert werden. Eine präzise Aussage lautet: „Zu diesem Zeitpunkt sahen alle in dieser RIPEstat-Ansicht vertretenen Peers AS6461.“ Die unzulässige Verkürzung wäre: „AS6461 ist überall und immer erreichbar.“

Was das einzelne ROA beweist und was nicht

Die RPKI-Prüfung ist ein gutes Beispiel dafür, wie ein klares technisches Ergebnis durch zu breite Sprache verfälscht werden kann. Der Status „valid“ für AS6461 und 64.125.0.0/16 sagt, dass die konkrete Ursprungsankündigung mit einem zu diesem Zeitpunkt verfügbaren, prüfbaren ROA übereinstimmte. Die maximale Länge 16 bedeutet in diesem Datensatz, dass die Freigabe genau bis zu dieser Präfixlänge reichte.

Das Ergebnis beantwortet nicht, ob alle anderen Präfixe des Netzes ebenfalls abgedeckt waren. Es validiert nicht die vollständige Kette von Netzen, die eine Route durchläuft. Es garantiert nicht, dass alle Betreiber ungültige Routen gleich behandeln. Es schützt nicht gegen einen Faserbruch, einen Stromausfall, Überlastung oder einen Fehler in einer Kundenfirewall. Und es macht aus einer erlaubten Route keine ständig verfügbare Route.

RPKI-Ursprungsvalidierung ist trotzdem wichtig. Sie kann Betreibern helfen, unpassende Ursprungsankündigungen zu erkennen und Richtlinien darauf aufzubauen. Ihr Wert steigt, wenn die Abdeckung vollständig, die maximalen Längen sorgfältig gewählt, die Filter aktuell und die Reaktionen auf ungültige Zustände betrieblich erprobt sind. Für die Beschaffung folgt daraus eine einfache Regel: Nicht einen Mustercheck verallgemeinern, sondern alle für den Dienst relevanten Ursprung-Präfix-Paare prüfen.

Auch IRR und RPKI sind keine Gegensätze, die automatisch das eine durch das andere ersetzen. Ein IRR-Eintrag beschreibt veröffentlichte Routing-Absicht; ein ROA autorisiert einen Ursprung kryptografisch. Betreiber können beide Informationsarten für Filter verwenden. Beide benötigen korrekte Daten, klare Verantwortliche und einen Prozess für Änderungen. Ein Fehler in einem Verzeichnis bleibt ein Betriebsrisiko, wenn niemand ihn rechtzeitig erkennt und korrigiert.

Backbone-Größe: Fähigkeit statt Ergebnis

Zayos eigene IP-Transit-Seite nannte zum Zeitpunkt der Erfassung ein Glasfaser-Backbone von mehr als 17 Millionen Meilen, über 400 Märkte, mehr als 1.200 Rechenzentren, mehr als 375 globale Points of Presence und über 47 Terabit Peering-Kapazität. Das sind Aussagen des Anbieters über seine Plattform. Sie sind für die Einordnung der möglichen Reichweite relevant, aber in der vorliegenden Quellenlage keine unabhängig vermessenen Größen.

Die IP-Transit-Übersicht verbindet das Angebot ausdrücklich mit AS6461 und beschreibt direkte Internetanbindung mit niedriger Latenz. Die technische Beschreibung für Dedicated Internet Access nennt eine Zustellung über Glasfaser oder Ethernet zum Zayo-Netz und führt statisches Routing, Standardrouten, BGP, optionales BFD, Link Aggregation, Multihoming und Router-Redundanz als Möglichkeiten auf. IP Transit und Dedicated Internet Access sind unterschiedliche Produkte. Ein Merkmal aus dem DIA-Dokument darf deshalb nicht ungeprüft als Bestandteil jedes IP-Transit-Angebots dargestellt werden.

Die Größe eines Backbone kann Kontinuität erleichtern. Mehr Netzknoten und Kopplungen können zusätzliche Wege schaffen. Eigene Glasfaser kann einem Betreiber mehr Kontrolle über Ausbau und Wartung geben. Hohe Peering-Kapazität kann Reserven bereitstellen. Doch aus „kann“ wird erst durch ein konkretes Design ein „ist“.

Der lokale Zugang bleibt häufig der entscheidende Übergang. Selbst ein sehr großes Kernnetz hilft einem Standort nicht, wenn beide Zuleitungen denselben Tiefbauabschnitt nutzen. Ein Kunde kann zwei BGP-Sitzungen haben, die auf demselben Router enden. Ein BFD-Mechanismus kann einen Fehler erkennen, ohne dass der nachfolgende Umschaltprozess die Anwendung rechtzeitig wiederherstellt. Communities können viele Richtlinienoptionen bieten, obwohl die für den Kunden ausgewählte Markierung nicht wie erwartet wirkt.

Diese Beispiele behaupten keinen Mangel im Zayo-Netz. Sie erklären, warum eine allgemeine Architekturbeschreibung und eine konkrete Dienstleistung zwei Beweisstufen sind. Backbone-Größe ist ein Hinweis auf Gestaltungsspielraum. Kundenspezifische Routenkontinuität muss durch Pfadunterlagen, Konfiguration, Messungen und Tests belegt werden.

Richtlinien und Communities als Bedienoberfläche

Zayos globale Interconnection-Richtlinie, überarbeitet am 7. Juli 2022, beschreibt Auswahl- und Betriebsbedingungen für Peering mit AS6461. Sie verlangt unter anderem gepflegte RIR- und PeeringDB-Kontakte, eine jederzeit erreichbare Netzbetriebsstelle, IRR-Daten und/oder gültige ROAs sowie Zusammenarbeit bei Missbrauchs- und Routing-Problemen. Sie erklärt außerdem, RPKI-ungültige Ankündigungen abzulehnen.

Der Haftungsausschluss des Dokuments gehört zur Aussage. Die Richtlinie bezeichnet sich als Leitlinie, nicht als Vertrag oder Regelwerk für eine bestimmte Peering-Beziehung, und kann nach Ermessen von Zayo geändert werden. Daraus folgt: Das Dokument zeigt eine veröffentlichte Erwartung und einen technischen Rahmen. Es zeigt nicht, dass jeder Peer jede Bedingung aktuell erfüllt oder dass ein bestimmter Vorfall vertragsgemäß behandelt wurde.

Die veröffentlichte Liste der BGP-Communities ist ähnlich zu lesen. Sie enthält Kennzeichnungen für die Unterdrückung von Ankündigungen, mehrfaches Voranstellen im AS-Pfad, lokale Präferenz, Blackholing und regionale oder netzbezogene Behandlung. Das ist eine umfangreiche Bedienoberfläche für Routing-Politik. Ob eine Kennzeichnung auf einer bestimmten Route gesetzt, angenommen und korrekt umgesetzt wurde, lässt sich aus der Tabelle nicht erkennen.

Für Betreiber entsteht daraus eine Prüfaufgabe: Welche Communities gelten für den gekauften Dienst? Werden sie auf allen vorgesehenen Sitzungen unterstützt? Welche Kombinationen sind zulässig? Wie wird ihre Wirkung aus unabhängigen Blickwinkeln geprüft? Was geschieht bei einer fehlerhaften Markierung? Ein dokumentiertes Steuerelement ist ein Anfang, nicht das Ende der Kontrolle.

Die Beweiskette für echte Kontinuität

Eine belastbare Kontinuitätsaussage benötigt mindestens fünf definierte Elemente: das geschützte Objekt, das betrachtete Fehlerbild, das erwartete Verhalten, den Messpunkt und die vertragliche Folge.

Das geschützte Objekt kann eine physische Leitung, eine BGP-Sitzung, die Erreichbarkeit bestimmter Präfixe oder eine Anwendung sein. Diese Dinge können unabhängig voneinander ausfallen. Ein zweiter Glasfaserweg schützt nicht automatisch eine Datenbank. Eine sichtbare Route schützt nicht automatisch einen DNS-Dienst. Eine gültige Ursprungsfreigabe schützt nicht automatisch die Stromversorgung.

Das Fehlerbild legt fest, was „redundant“ bedeutet. Zwei Ports schützen gegen den Ausfall eines Ports. Zwei Router können gegen einen Gerätefehler schützen. Zwei Gebäudeeinführungen können gegen einen lokalen Kabelschaden schützen. Zwei Netzanbieter können die Abhängigkeit von einem Betreiber verringern. Keine Variante schützt automatisch gegen alle anderen Fehler.

Das erwartete Verhalten braucht eine Zeitangabe. Wie schnell wird ein Fehler erkannt? Wann ändert sich die Route? Wie viel Paketverlust ist zu erwarten? Wann stellt die Anwendung ihre Sitzungen wieder her? Was passiert bei der Rückkehr zum bevorzugten Weg? BFD kann die Erkennung bestimmter Fehler beschleunigen, aber Erkennungszeit und Wiederherstellungszeit sind nicht dasselbe.

Der Messpunkt bestimmt, was eine Verfügbarkeitszahl bedeutet. Ein Monitor am Provider-Rand kann „grün“ zeigen, während eine Anwendung hinter dem Kundenrouter nicht antwortet. Ein externer Routing-Kollektor kann die Route sehen, während ein bestimmter Zugangsprovider ein Problem hat. Messwerte müssen daher Standort, Intervall, Aggregation und Ausschlüsse nennen.

Die vertragliche Folge klärt schließlich, was nach einer bestätigten Abweichung geschieht. Gutschriften, Eskalationen, technische Überprüfungen oder Kündigungsrechte sind unterschiedliche Instrumente. Ein Service Level Agreement, kurz SLA, ist nur so aussagekräftig wie seine Messdefinition und sein Geltungsbereich. Die Größe des Backbone kann diese Vertragsdetails nicht ersetzen.

Checkliste für Einkauf und Betrieb

Eine Organisation kann die öffentlichen Informationen nutzen, um eine präzise Prüfung anzustoßen. Die folgenden Punkte gelten nicht als Bewertung eines einzelnen Anbieters, sondern als Vorgehen für wichtige Internetverbindungen.

Identität und Verantwortung

Vertragsgesellschaft, Rechnungssteller, technischer Betreiber und Eskalationsstelle getrennt benennen.
Abweichungen zwischen Zayo Group, LLC, Zayo Group, Zayo, Zayo Bandwidth und ZAYO-6461 schriftlich für den konkreten Vertrag erklären lassen.
Festlegen, wer Routing-Änderungen anfordern, ROAs oder IRR-Einträge pflegen und Notfallmaßnahmen freigeben darf.
Technische und Missbrauchskontakte auf Aktualität und tatsächliche Erreichbarkeit prüfen.
Für rechtliche, regulatorische und operative Aussagen jeweils die richtige Quelle bestimmen.

Physische Auslegung

Für jede Leitung den Übergabepunkt, Gebäudeeingang, Kabelweg, Netzknoten und die Stromabhängigkeit erfassen.
Den ersten gemeinsamen Punkt scheinbar getrennter Wege identifizieren.
Klären, ob Diversität vertraglich zugesichert, optional bestellbar oder nur grundsätzlich im Netz möglich ist.
Wartungsprozesse so definieren, dass eine spätere Umschaltung die vereinbarte Trennung nicht unbeabsichtigt aufhebt.
Vertrauliche Streckeninformationen durch eine nachvollziehbare Risiko-Bescheinigung ersetzen, wenn eine vollständige Karte nicht offengelegt werden kann.

Logisches Design

Router, Ports, BGP-Sitzungen und Adressfamilien je Weg dokumentieren.
Prüfen, ob Primär- und Ersatzsitzung auf getrennten Geräten und Steuerungsbereichen enden.
Angenommene und angekündigte Präfixe, Filter, Grenzwerte und Präferenzen festhalten.
Bei BFD die abgedeckten Verbindungen, Parameter und Reaktion auf einen Fehler abstimmen.
Bei Multihoming genau benennen, ob die Trennung Links, Router, Standorte, Anbieter oder mehrere Ebenen betrifft.

Routing-Sicherheit

Alle für den Dienst relevanten Präfixe auf RPKI-Status prüfen, nicht nur 64.125.0.0/16.
Maximale Präfixlängen so wählen, dass legitime Ankündigungen möglich bleiben, ohne unnötig breite Freigaben zu schaffen.
IRR-Objekte mit der aktuellen Routing-Absicht vergleichen und veraltete Angaben korrigieren.
Ermitteln, wie Filter erzeugt, aktualisiert, überprüft und im Fehlerfall zurückgenommen werden.
Ausnahmen und Verantwortlichkeiten schriftlich festhalten.

Zusammenschaltung und Steuerung

Für wichtige Ziele klären, ob Verkehr über öffentlichen Austausch, PNI, Transit oder Kundenpfade läuft.
Kapazitäts- und Ausfallschwellen für eine Erweiterung oder Umschaltung definieren.
Nur die Communities als verfügbar behandeln, die für die konkreten Sitzungen bestätigt wurden.
Community-Wirkungen aus mehreren Messpunkten prüfen.
Einen gelisteten Peer oder Standort nicht ohne Routennachweis als genutzten Kundenweg voraussetzen.

Messung und Vertrag

Verfügbarkeit, Latenz, Paketverlust und Schwankung an festgelegten Punkten messen.
Intervalle, Zusammenfassung, Zeitzone und Umgang mit fehlenden Daten vereinbaren.
Provider-Rand, Ende-zu-Ende-Verbindung und Anwendungsgesundheit getrennt betrachten.
Geplante Wartung, Kundeneinfluss und Drittnetzstörungen klar klassifizieren.
Nachweis, Eskalationsweg und Rechtsfolge eines bestätigten SLA-Verstoßes festlegen.

Ein 30-Tage-Plan für belastbare Prüfung

Tage 1 bis 3: Ziel und Grenze festlegen

Die Beteiligten formulieren in einem Satz, was erhalten bleiben soll. Ein gutes Ziel nennt Standort, Anwendung, Fehler und gewünschte Wiederherstellung. Beispiel: „Beim Ausfall eines der beiden Zugangswege soll die Terminplattform der Klinikstandorte innerhalb des vereinbarten Zeitfensters erreichbar bleiben.“ Danach werden Vertragspartner, operative Kontakte, ASN, Präfixe und Zuständigkeiten in einer Tabelle getrennt erfasst.

UTC dient als gemeinsame Zeitbasis für Routing-Ereignisse; lokale Zeit bleibt für Geschäftsauswirkungen und Wartungsfenster erhalten. Mindestens ein Messpunkt im Kundennetz, ein Anwendungsmonitor und mehrere externe Beobachter werden festgelegt.

Tage 4 bis 7: Normalzustand vermessen

Über mehrere Arbeitstage werden Verfügbarkeit, Latenz, Paketverlust und BGP-Zustand erfasst. Kurze Unterbrechungen dürfen nicht in einem groben Tagesmittel verschwinden. Die tatsächlich ausgetauschten Präfixe werden mit den erwarteten Routen verglichen.

Für jedes relevante Präfix werden RPKI- und IRR-Daten geprüft. Das gültige Beispiel AS6461 mit 64.125.0.0/16 dient nur als Erklärung der Methode. Fehlende oder ungültige Einträge erhalten einen Verantwortlichen und einen Termin zur Korrektur.

Tage 8 bis 14: gemeinsame Risiken aufzeichnen

Kunde und Anbieter verfolgen die Wege vom Übergabepunkt in Richtung Kernnetz. Sie markieren gemeinsame Gebäudeeinführungen, Kanäle, optische Systeme, Router und Strombereiche. Parallel dazu prüfen sie BGP-Präferenzen, Filter, Route-Limits, Communities und die gewünschte Umschaltlogik.

Optionale Produktmerkmale werden mit dem Dienstauftrag abgeglichen. Nur was für diesen Anschluss bestellt und bestätigt ist, gehört in die Kontinuitätsannahme. Ein allgemeiner Produktprospekt ersetzt diesen Schritt nicht.

Tage 15 bis 21: kontrollierte Fehlerübungen

In einem genehmigten Wartungsfenster werden sichere, klar begrenzte Tests durchgeführt. Zuerst werden Überwachung und Kontakte geprüft. Danach kann ein vereinbarter Testweg kontrolliert entfernt werden, sofern beide Seiten den Ablauf, Abbruchkriterien und Wiederherstellungsverantwortliche festgelegt haben.

Erkennungszeit, Änderung der BGP-Sitzung, Routenkonvergenz, Paketwiederkehr und Anwendungswiederkehr werden getrennt gemessen. Auch die Rückkehr zum Primärweg wird beobachtet, weil sie eine zweite Änderung auslösen kann. Das Ergebnis besteht aus Zeitstempeln und Messwerten, nicht nur aus dem Satz „Der Test war erfolgreich“.

Tage 22 bis 26: Außen- und Innensicht vergleichen

Die Kundenmessung wird mit öffentlichen Routing-Beobachtungen und den Betriebsdaten des Anbieters verglichen. Unterschiede sind nicht automatisch Widersprüche; sie zeigen oft verschiedene Ebenen. Bleibt die Route sichtbar, während die Anwendung ausfällt, liegt die Suche hinter oder neben dem reinen BGP-Signal. Verschwindet ein Weg bei einem Kollektor, während der Dienst stabil bleibt, kann ein alternativer Pfad korrekt gearbeitet haben.

RPKI, IRR und Kontakte werden erneut geprüft. Wichtige Communities werden nicht anhand der Dokumentation, sondern anhand ihrer beobachteten Wirkung bewertet.

Tage 27 bis 30: Entscheidungen dokumentieren

Netzwerk, Anwendungen, Einkauf und Rechtsabteilung ordnen jede Aussage einer Kategorie zu: nachgewiesen, dokumentiert aber ungetestet, optional und nicht bestellt, außerhalb des Geltungsbereichs oder ungeklärt. So wird verhindert, dass eine Fähigkeit zur Garantie erklärt wird.

Zum Abschluss entstehen ein aktualisiertes Diagramm, ein Eskalationsplan, eine Liste offener Risiken und ein Termin für die nächste Prüfung. Dreißig Tage beweisen keine ewige Verfügbarkeit. Sie zeigen, ob die Kontinuitätsaussage eine überprüfbare technische und organisatorische Grundlage hat.

Hinweis zum begleitenden Bild

Das begleitende Bild ist eine eigens erstellte, fotorealistische redaktionelle Illustration. Es zeigt eine nicht identifizierbare Person bei der Prüfung eines generischen, unbeschrifteten Routendiagramms und einer Kontinuitäts-Checkliste. Es enthält keine Logos, lesbaren IP-Adressen, autonomen Systemnummern, Kundendaten, Kennzahlen oder Karten realer Infrastruktur. Die Szene zeigt oder behauptet weder Zayo Group, LLC noch Zayo Group, Zayo Bandwidth, die Marke Zayo, Beschäftigte, Kunden, Büros, Anlagen, Glasfaserwege, Betriebsergebnisse, Störungen, Schwächen, Fehlverhalten oder Empfehlungen.

Sie dient ausschließlich als allgemeines Sinnbild für die Prüfung von Netzabhängigkeiten.

Fazit

Die öffentliche Beweislage trägt eine präzise, aber begrenzte Aussage. Zayo beschreibt ein sehr großes Glasfaser-Backbone und verbindet Internetdienste mit AS6461. RIPEstat sah AS6461 zu benannten Zeitpunkten im August 2026 bei den einbezogenen Peers breit sichtbar. ARIN, RIPE NCC, PeeringDB, SEC und FCC dokumentieren jeweils unterschiedliche Teile von Identität, Registrierung und Kontext. Für genau AS6461 und 64.125.0.0/16 lag bei der erfassten Prüfung ein gültiges ROA-Ergebnis vor. Zayo veröffentlicht außerdem Regeln für Interconnection und eine umfangreiche Community-Tabelle.

Diese Fakten sprechen für ein substantielles Netz mit aktiver Routing-Präsenz und dokumentierten Steuerungsmöglichkeiten. Sie beweisen keine kundenspezifische Routenkontinuität und keinen SLA-Erfolg. Ein Kollektor sieht keinen gemeinsam genutzten Kabelkanal. Ein ROA stellt keinen Strom wieder her. Eine Community-Tabelle zeigt nicht ihre korrekte Anwendung. Eine Backbone-Zahl beschreibt nicht den Zugang zu einem einzelnen Gebäude.

Die sachgerechte Schlussfolgerung ist daher weder pauschales Vertrauen noch pauschales Misstrauen. Registereinträge bleiben Registereinträge, Messungen bleiben zeit- und beobachtergebunden, und Produktoptionen bleiben Möglichkeiten, bis ein konkreter Dienst sie in einem dokumentierten und getesteten Design zusammenführt.

Zayo Group, LLC und AS6461: Was kann ein Glasfaser-Backbone über Routenkontinuität beweisen?

Warum es wichtig ist