Haraguroicha Internet Service: Lokale Konnektivitätsrechnung abhängig von Upstream-Routen und Feldreparatur

Zusammenfassung

• Haraguroicha Internet Service ist öffentlich sichtbar als AS57429 und das ältere AS212359. Beide sind im selben RIPE as-set, kündigen IPv6-Adressraum an und werden als Bildungs- oder Forschungsnetze präsentiert; das ist ein solider Beleg für eine betriebene Routing-Domäne, nicht für ein Haushalts-Breitbandgeschäft.
• Der Betreiber kündigt Tunnel-Ursprünge in Neu-Taipeh, Taipeh, Taichung und Tokio an, die WireGuard, GRE oder IPsec nutzen. Die PeeringDB-Einträge weisen für beide AS keine Interconnection-Einrichtung aus. Diese Tatsachen stützen eine virtuelle, von einem Underlay abhängige Topologie und nicht eigene Glasfaser zwischen vier physischen Standorten.
• Aktuelle Routing-Beobachtungen zeigen den klarsten Pfad zu AS57429 über Walks Clouds AS38856, während die klarsten AS212359-Pfade über AS57429 führen. Die registrierte Richtlinie nennt mehr als einen möglichen Partner, aber gegenwärtige physische und kommerzielle Redundanz ist nicht nachgewiesen.
• Portbezeichnungen von 100 Mbit/s an den Taiwan-Ursprüngen über 10 Gbit/s in Tokio, zuzüglich 1 Gbit/s- und 500 Mbit/s-Exchange-Anbindungen, dürfen nicht als Kundenkapazität aufaddiert werden. Das vom Betreiber selbst gemeldete Verkehrsband beträgt nur 20–100 Mbit/s, und der Tunneldurchsatz bleibt durch Zugang, Transit, Hosting, Verschlüsselung und Überlastungsbegrenzungen eingeschränkt.
• Es wurde kein öffentlicher Tarif, keine Bestellseite, keine Teilnehmerzahl, keine Service-Level-Vereinbarung, kein Anlagenverzeichnis, kein Turm- oder Mastenplan, kein Feldteam, kein Ersatzteillager, keine Notstromspezifikation und kein getestetes Wiederherstellungsergebnis gefunden. Die sachgerechte Bewertung ist daher ein funktionierendes kleines Routing-Netzwerk mit unbestätigtem Endkunden- und Letzte-Meile-Status.

Der Name verweist auf ein Netzwerk, noch nicht auf einen Endkunden-Carrier

Die konkreteste öffentliche Bedeutung von Haraguroicha Internet Service ist ein Paar von Nummern autonomer Systeme.PeeringDB identifiziert AS57429unter diesem Namen, weist ihm einen regionalen geografischen Geltungsbereich zu und klassifiziert seinen Netzwerktyp als Bildungs- oder Forschungsnetz.Ein zweiter PeeringDB-Eintrag identifiziert AS212359als Haraguroicha Legacy Internet Service, ebenfalls ein Bildungs- oder Forschungsnetz, mit Asien-Pazifik-Geltungsbereich. Dieöffentliche Profil- und Peering-Seitedes Betreibers listet beide Nummern und lädt zu Peering-Kontakt ein.

Das ist ein aussagekräftiger betrieblicher Beleg. Ein autonomes System ist nicht einfach eine Web-Domain-Registrierung. Es ist eine administrative Identität, mit der über das Border Gateway Protocol Erreichbarkeit mit anderen Netzen ausgetauscht wird. Haraguroicha hat zwei solche Identitäten unterhalten, eine registrierte Routing-Richtlinie, delegierten Adressraum, Exchange-Einträge und beobachtbare Routen. Pakete können unter seinen Nummern versendet werden. Andere Netze haben eine Grundlage, diese Ankündigungen anzunehmen oder abzulehnen.

Es ist jedoch kein Beleg für einen herkömmlichen regionalen Breitbandanbieter. Dieselben öffentlichen Seiten veröffentlichen weder einen Privatkunden- noch einen Geschäftskundentarif, Installationsbedingungen, eine Verfügbarkeitsprüfung, Kundengeräte, Supportzeiten, eine Nutzungsrichtlinie für Teilnehmer, eine Service-Level-Verpflichtung oder eine Netzstatusseite. Die Klassifizierung als Bildungs- oder Forschungsnetz in PeeringDB widerspricht der Lesart, das Wort „Service“ sei ein Beweis für ein Massenmarktangebot.

Der Name mag den Dienst beschreiben, ein experimentelles Netz zu betreiben und zu vernetzen, und nicht den Verkauf von lokalem Internetzugang.

Die gegenwärtige Regulierungsgrenze in Taiwan macht diese Unterscheidung wesentlich. Das geänderteTelecommunications Management Actbesagt, dass Anbieter, die Teilnehmern Internetzugang anbieten, sich als Telekommunikationsunternehmen registrieren lassen müssen. Eine ASN, eine IPv6-Zuteilung oder ein Exchange-Port allein beantwortet nicht die Frage, ob ein Betreiber Teilnehmer im Sinne dieser gesetzlichen Bestimmung hat. Es wird hier nicht behauptet, dass Haraguroicha unter einem anderen rechtlichen Namen registriert ist oder nicht. Der engere Punkt ist, dass die öffentlichen Netzwerkdaten die Frage nicht klären.

Daher verwendet dieses Profil „Regionaler ISP“ als nützliche Infrastrukturkategorie, nicht als Schlussfolgerung über die kommerzielle Größe. Haraguroicha ist nachweislich ein kleines geroutetes Netz mit Bezug zu Taiwan. Es mag die eigenen Systeme des Betreibers, Forschungsverkehr, ausgewählte Peers oder private Nutzer transportieren. Es gibt nicht genügend Belege, um Haushalte, Unternehmen oder öffentliche Einrichtungen dahinter zu zählen. Diese Grenze ist immer dann von Bedeutung, wenn die Analyse von Routen zu Kunden, Umsätzen oder lokalen wirtschaftlichen Auswirkungen übergeht.

Ein Betreiber, zwei autonome Systeme und ein Routing-Set

Die Registrierungsgeschichte beginnt mit AS212359. DasRIPE-Datenbank-Objekt für AS212359wurde im November 2020 erstellt und beschreibt Haraguroicha Internet Service. AS57429 folgte im März 2022; seinRIPE-Objektverwendet den Namen HARAGUROICHA-AS. Beide verweisen auf dieselbe Ressourceninhaber-Organisation ORG-MA1764-RIPE, die Ming-Ray Hsu in Taiwan nennt und als „OTHER“ typisiert ist, nicht als Unternehmen. Die öffentliche Website ist ein persönliches Berufsprofil, kein Unternehmensauftritt.

DasAS-HARAGUROICHA-Registrierungsobjektenthält sowohl AS57429 als auch AS212359. Ein as-set erlaubt es dem Betreiber und seinen Partnern, bei der Erstellung von Routing-Filtern auf eine gepflegte Gruppe zu verweisen. Praktisch werden die beiden Nummern als eine administrative Routing-Familie präsentiert. Das as-set beweist nicht, dass jedes Präfix immer angekündigt wird, dass jeder Upstream dieselben Mitglieder akzeptiert oder dass die beiden Systeme physisch divers sind.

Die neuere Nummer scheint der hauptsächliche öffentliche Edge zu sein. PeeringDB verwendet den unqualifizierten Service-Namen für AS57429 und nennt AS212359 „Legacy“. Aktuelle Routenpfade setzen AS57429 für einen großen Teil des sichtbaren Raums des älteren Systems unmittelbar vor AS212359. Der Betreiber listet dennoch weiterhin beide Nummern, das as-set enthält beide und AS212359 kündigt weiterhin Routen an. „Legacy“ sollte folglich als Rollenbezeichnung gelesen werden, nicht als Beweis dafür, dass das ältere System stillgelegt ist.

In diesen Einträgen gibt es eine wichtige Eigentumsgrenze. Die sponsoring organizations von RIPE helfen bei der Verwaltung von Nummernressourcen. Die in Import- und Export-Richtlinien genannten Partner beschreiben beabsichtigte Routing-Beziehungen. Die Unternehmen, die einen virtuellen Server, einen Tunnel, eine Zugangsleitung oder eine physische Cross-Connect bereitstellen, können wiederum andere sein. Eine sponsoring organization ist nicht notwendigerweise ein Transit-Provider; eine registrierte Transit-Richtlinie ist nicht notwendigerweise eine aktive Session; und eine aktive Session verrät nicht, wem die darunterliegende Glasfaser gehört.

Das berufliche Profil des Betreibers fügt eine relevante, aber sorgfältig begrenzte Tatsache hinzu. Es gibt an, dass Ming-Ray Hsu Mitgründer und Chief Technology Officer von Walks Cloud Inc. ist und separat das Management von AS57429 und AS212359 auflistet. Die RIPE-Routing-Richtlinie nennt Walks Clouds AS38856 für beide Haraguroicha-Systeme. Diese Einträge machen den aktuellen Pfad verständlich, verschmelzen jedoch nicht die Vermögenswerte, Kunden oder Verpflichtungen von Haraguroicha mit denen von Walks Cloud.

Die öffentlichen Belege zeigen einen gemeinsamen betrieblichen Kontext und Routing-Kontakt, nicht aber eine veröffentlichte Eigentumsvereinbarung.

Die Standorttabelle beschreibt Tunnel-Ursprünge

Die eigene Seite von Haraguroicha listet vier Ursprünge auf. Neu-Taipeh, Taipeh und Taichung sind jeweils mit 100 Mbit/s gekennzeichnet. Tokio ist mit 10 Gbit/s gekennzeichnet. Die zugelassenen Dienste sind WireGuard, GRE und IPsec in unterschiedlichen Kombinationen. Die Formulierung ist aufschlussreicher als eine generische Regionalkarte, denn sie verrät, wie die Punkte erreicht werden: Es handelt sich um Tunnel-Endpunkte.

Jede genannte Technologie erzeugt einen logischen Pfad über ein bestehendes Netz.WireGuard kapselt IP-Pakete über UDPund verwendet authentifizierte Verschlüsselung zwischen konfigurierten Peers.GREverpackt ein Netzwerkschichtpaket in ein anderes, stellt aber selbst nicht die physische Leitung oder Verschlüsselung bereit. DieIPsec-Architektursichert IP-Verkehr zwischen definierten Sicherheitsendpunkten. In jedem Fall muss bereits ein Underlay die äußeren Pakete transportieren.

Das macht die Standorttabelle zu einer Karte erreichbarer Ursprünge, nicht zu einem Inventar eigener Zugangsanlagen. Ein Neu-Taipeh-Ursprung könnte ein Router in einem Büro, ein kleiner Server zu Hause, eine gehostete virtuelle Maschine, ein untergebrachtes Gerät oder ein aus der Ferne bereitgestellter Port von anderswo sein. Dieselbe Spanne gilt für Taipeh, Taichung und Tokio. Die Seite veröffentlicht für keinen Ursprung eine straßengenaue Einrichtungsadresse, ein Rack, den Gebäudeeigentümer, eine Cross-Connect-, Zugangs-Carrier- oder Leitungsbezeichnung. PeeringDB listet für beide AS keine Interconnection-Einrichtung.

Der physische Fußabdruck, der mit Zuversicht festgestellt werden kann, ist daher schmal. Der Ressourceninhaber ist mit Neu-Taipeh-Stadt verbunden. Der Betreiber kündigt Tunneleintrittspunkte in drei taiwanesischen Städten und Tokio an. AS57429 ist an einem Exchange in Fremont, Kalifornien, sichtbar, und AS212359 ist an einem Exchange in Zürich, Schweiz, gelistet, doch keiner der Exchange-Einträge beweist, dass Haraguroicha in diesen Städten einen Router besitzt oder untergebracht hat. Remote-Layer-2-Zustellung und Tunneling können ein AS auf eine Exchange-Fabric bringen, ohne ein lokales Rack.

Es gibt keinen öffentlichen Beleg für Haraguroicha-eigene Glasfaser zwischen Neu-Taipeh, Taipeh und Taichung, keinen Turm- oder Mastenplan, keine Richtfunk-Sektoren und keine Kunden-Anschlusskabel. Es gibt auch keinen Beleg, dass der Betreiber die Taiwan-Leitungen besitzt, auf denen seine Tunnel beginnen. Die vorsichtige Topologieannahme ist ein Overlay über Internet-, Hosting- und Exchange-Infrastruktur Dritter. Eine solche Architektur ist durchaus in der Lage, echten Verkehr zu tragen. Sie erbt lediglich mehr von ihrer physischen Ausfallsicherheit von Lieferanten, als eine Karte mit vier Bezeichnungen vermuten ließe.

Ein sichtbares IPv6-Netz mit weniger Adressraum, als die Bezeichnungen vermuten lassen

Aktuelle globale Routing-Beobachtungen bestätigen Aktivität. DieRIPEstat-Ansicht der angekündigten Präfixe für AS57429zeigte während des für dieses Profil verwendeten Beobachtungsfensters vier IPv6-Ankündigungen. Drei waren2a06:a005/44s, die auf der Betreiberseite aufgeführt sind; die vierte war2a0f:607:1024::/48. Dieentsprechende AS212359-Ansichtzeigte fünf IPv6-Ankündigungen.

Das ist ein besserer Beleg als eine ruhende Registrierung. Es deutet darauf hin, dass Routen-Kollektoren kürzlich Haraguroicha-Ursprünge von mehreren Beobachtungspunkten empfangen haben. CloudflaresAS57429-Übersichtund dieAS212359-Routing-Seiteerkennen die Namen ebenfalls und zeigen aktuelle Routing-Ansichten. Das Netz ist nicht bloß ein verlassener ASN-Eintrag.

Die Zahlen auf PeeringDB bedürfen der Interpretation. Beide Netzwerkeinträge nennen sechs IPv4-Präfixe und 50 IPv6-Präfixe. In Interconnection-Verzeichnissen werden diese Felder üblicherweise als Präfix-Limits verwendet, die ein Peer erwarten sollte, nicht als zertifizierte Anzahl tatsächlich aktuell angekündigter Blöcke. Sie sollten weder mit der Adressgröße multipliziert noch als Kundenbestand behandelt werden. Die Routen-Kollektoren zeigen vier bzw. fünf aktuelle IPv6-Ankündigungen, während im selben Ergebnis kein von Haraguroicha stammendes IPv4-Präfix auftauchte.

IPv4-Adressen auf einer Exchange-Fabric ändern diese Schlussfolgerung nicht. AS57429 hat eine IPv4-Peering-LAN-Adresse bei Lambda-IX und AS212359 eine bei 4b42. Eine Peering-LAN-Adresse erlaubt es den Routern, an diesem Exchange miteinander zu sprechen. Das ist nicht dasselbe wie die Ankündigung eines IPv4-Kundenblocks in der globalen Tabelle. Die öffentliche Routing-Identität von Haraguroicha ist derzeit viel deutlicher IPv6 als IPv4.

Die Adressblöcke offenbaren auch eine Lieferantenabhängigkeit. Der Betreiber schreibt mehrere /44s Route48 zu und andere Präfixe TunnelBroker.ch, FREETRANSIT, RHE-NET und Nato Internet Service. Diese Zuschreibungen sind selbstveröffentlicht und können späteren Ressourcenarrangements hinterherhinken, aber sie zeigen, dass die Adressverwaltung nicht mit dem Eigentum an der übergeordneten Zuweisung gleichzusetzen ist.

Wenn ein Sponsor seine Richtlinie ändert, einen Dienst einstellt, die Erlaubnis widerruft oder die Pflege von Routenobjekten beendet, muss der Betreiber möglicherweise umnummerieren, eine Routenberechtigung ersetzen oder einen anderen Sponsor finden, selbst wenn seine Router und Tunnel intakt bleiben.

Die aktuelle Origin-Validierung ist gemischt, aber überwiegend positiv. Direkte RIPEstat-Prüfungen der neun kürzlich beobachteten Ankündigungen ergaben am 10. Juli 2026 siebenvalid- und zweiunknown-Ergebnisse. Unbekannt bedeutet nicht ungültig; es bedeutet in der Regel, dass der Validator keine Route-Origin-Authorization gefunden hat, die den genauen Ursprung und das Präfix abdeckt. Die Unterscheidung ist dennoch wichtig, da Netze, die Route-Origin-Validation erzwingen, eine ungültige Route ablehnen können, während eine unbekannte Route die von jedem Netz gewählte Richtlinienbehandlung erhält. Die Pflege von Berechtigungen ist Teil dessen, gesponserten Adressraum nutzbar zu halten.

Der klarste Pfad verengt sich dennoch über Walks Cloud

Das Register beschreibt mehr Diversität, als die aktuellen Routenpfade zeigen. Das RIPE-Objekt von AS57429 akzeptiert Routen von AS41378 und AS38856. Das Objekt von AS212359 nennt AS38856 und AS20473. Das sind deklarierte Import- und Export-Richtlinien: Aussagen über beabsichtigten oder erlaubten Austausch. Sie sind nützlich für Filterung und Kontakt, aber sie sind kein Beweis, dass alle Sessions aktiv, unabhängig zugestellt oder in der Lage sind, gleichzeitig die volle Verkehrslast zu tragen.

Aktuelle RIPE-RIS-Pfade zeigen eine einfachere Struktur. Bei jeder der vier klaren Ankündigungen von AS57429 war das unmittelbar vorhergehende AS in den beobachteten Pfaden AS38856, Walks Cloud. Bei den klarsten AS212359-Ankündigungen war das unmittelbar vorhergehende AS AS57429. Eine repräsentativeBGP-State-Ansicht von2a0f:607:1024::/48zeigt die Walks-Cloud-zu-Haraguroicha-Kante; eine repräsentativeAS212359-Präfix-Ansichtzeigt AS57429 unmittelbar vor AS212359.

Routen-Kollektoren sehen nur das, was ihre Peers ankündigen, und Pfade können je nach Präfix, Zeit und Richtlinie variieren. Diese Beobachtungen können nicht beweisen, dass es ein einziges Kabel gibt. Sie belegen jedoch, dass der global sichtbare Pfad während des Messfensters auf ein einziges unmittelbares Upstream-Muster hinausläuft. Ein zweiter Name in einem Register begründet noch keinen nutzbaren Failover.

Physische Redundanz erfordert eine härtere Faktenlage. Werden zwei Upstream-Sessions von unterschiedlichen Carriern zugestellt? Treten sie in unterschiedliche Gebäude ein? Liegen sie auf unterschiedlichen Leitungswegen oder Masten? Enden sie an unterschiedlichen Routern, Stromversorgungen und virtuellen Hosts? Kann jede die volle Normallast tragen, wenn die andere verschwindet? Bewahrt der Failover dieselbe Origin-Validierung und dieselben Routenfilter? Keine dieser Details ist für Haraguroicha öffentlich.

Die AS212359-Konfiguration fügt eine weitere Konzentrationsebene hinzu. Wenn seine Routen die Welt über AS57429 erreichen und AS57429 die Welt über AS38856 erreicht, dann beeinträchtigt ein Fehler an der AS57429-Grenze beide Identitäten. Zwei Nummern autonomer Systeme können das Experimentieren, die Richtlinientrennung oder die Migration verbessern. Sie schaffen keine zwei Fehlerdomänen, wenn eine hinter der anderen sitzt.

Dieselbe Überlegung gilt für die menschliche Beziehung. Walks Cloud mag ein bequemer und technisch naher Upstream sein, weil der Haraguroicha-Betreiber dort auch eine Führungsrolle innehat, wie er angibt. Das kann die Konfiguration und Wiederherstellung beschleunigen. Es kann aber auch die Eskalation in derselben kleinen Gruppe konzentrieren. Organisatorische Vertrautheit ist wertvoll, aber sie ersetzt keinen unabhängig kontrahierten Pfad und eine zweite Reparaturorganisation.

Exchange-Ports sind Optionen, keine Summe von Bandbreite

Haraguroicha verfügt über mehr öffentliche Interconnection, als sein geringes Verkehrsband vermuten ließe. Die aktuellenPeeringDB-Daten für AS57429listen eine 1-Gbit/s-Anbindung an Lambda-IX als betriebsbereit und eine 500-Mbit/s-Anbindung an Poema IX als nicht betriebsbereit. Der AS212359-Eintrag listet eine betriebsbereite 4b42-Exchange-Anbindung, gibt jedoch keine nutzbare Portgeschwindigkeit an. Das sind wertvolle Hinweise, aber keiner sollte als garantierter Internet-Uplink gelesen werden.

DerLambda-IX-PeeringDB-Eintragverortet seine Exchange-Fabric in Fremont und listet dort eine physische Einrichtung. Die eigene Ursprungsliste von Haraguroicha erwähnt Fremont nicht, und sein PeeringDB-Netzwerkeintrag listet keine Einrichtung. Die 1-Gbit/s-Angabe gibt daher die logische Exchange-Port-Rate an, nicht die Route, Latenz oder Kapazität des Dienstes, der diesen Port erreicht. Ein aus der Ferne zugestelltes 1-Gbit/s-Exchange-Interface kann durch einen 100-Mbit/s-Tunnel oder einen überlasteten virtuellen Host begrenzt sein.

Poema ist in Bezug auf die Unterscheidung noch expliziter. Die eigene Erläuterung einesvirtuellen IXPbesagt, dass Hobby- oder Forschungsnetze typischerweise virtuelle Maschinen und Tunnel über professionelle ISPs anstelle eigener Glasfaser nutzen und dass ein solcher Exchange den Gesamtdurchsatz des zugrundeliegenden Netzes nicht erhöht. DieBeitrittsregelnbeschreiben eine nicht-kommerzielle Teilnahme, Tunnel- oder VM-Zugang sowie verpflichtendes Route-Server-Peering. Die 500-Mbit/s-Poema-Angabe von Haraguroicha ist daher ein Beleg für experimentelles Interconnection-Potenzial, nicht für bezahlten Transit oder ein 500-Mbit/s lokales Zugangsnetz. PeeringDB kennzeichnet die Verbindung derzeit als nicht betriebsbereit, was es zusätzlich verbietet, sie als verfügbare Redundanz zu betrachten.

Die Zürich-Anbindung des älteren AS weist ähnliche Mehrdeutigkeiten auf.4IXP gibt an, dass Teilnehmer sich per Cross-Connect, VLAN oder Tunnel verbinden können und dass es EoIP-, GRE-Tap- und VXLAN-Optionen bietet. PeeringDB kennzeichnet den Exchange-Eintrag von Haraguroicha als betriebsbereit, liefert jedoch keine positive Portrate. Der Exchange kann die Menge erreichbarer Peers vergrößern und Route-Server-Lernen bieten. Er begründet weder eine physische Haraguroicha-Präsenz in der Schweiz noch einen unabhängigen Pfad von Taiwan aus.

Peering und Transit erfüllen zudem unterschiedliche Aufgaben. An einem Exchange erreicht ein Netz die Routen, die andere Teilnehmer anzukündigen bereit sind. Transit ist der Dienst, Verkehr weiter ins übrige Internet zu tragen. Eine offene Peering-Richtlinie senkt die vertragliche Hürde für den direkten Austausch, zwingt große Netze jedoch nicht zum Peeren, stellt keine Default-Route bereit und trägt keinen Verkehr über die eigenen Kunden hinaus. Ein Netz benötigt weiterhin zuverlässigen Transit für Ziele, die nicht von Peers abgedeckt werden.

Die Arithmetik ist folglich nicht additiv. Ein 1-Gbit/s-Exchange-Port, ein 500-Mbit/s-Exchange-Port, drei 100-Mbit/s-Taiwan-Ursprünge und ein 10-Gbit/s-Tokio-Ursprung ergeben keine 11,8 Gbit/s Kundenkapazität. Manche Bezeichnungen beschreiben Interfaces, andere beschreiben Tunnelangebote, und einige teilen sich möglicherweise dasselbe Underlay. Verkehr kann zwei oder mehr von ihnen in Serie durchlaufen. Die langsamste überlastete oder ausgefallene Abhängigkeit bestimmt den nutzbaren Pfad.

Installiert, erreichbar und nutzbar sind unterschiedliche Kapazitäten

PeeringDB ordnet beide Haraguroicha-Systeme in ein selbst gemeldetes Verkehrsband von 20–100 Mbit/s ein. Das ist konsistent mit einem kleinen Netz und liegt weit unter den größten Interface-Bezeichnungen. Das Band ist jedoch kein geprüfter Verkehrsgraph, und die identischen Werte in beiden Einträgen beschreiben möglicherweise die kombinierte Umgebung und nicht zwei unabhängige Lasten. Es sollte als Größenordnungsaussage behandelt werden.

Installierte Kapazität ist die ausgehandelte Leitungsrate eines Interfaces oder die nominelle Grenze einer Leitung. Erreichbare Kapazität ist das, was passieren kann, nachdem Tunnel, Underlay und entfernter Endpunkt funktionieren. Nutzbare Kapazität ist das, was nach Protokoll-Overhead, Paketgröße, Verschlüsselungsarbeit, Verkehrsüberlastung, Routing-Richtlinie und Resilienzreserve übrig bleibt. Kundenverfügbare Kapazität wäre noch geringer, wenn das Netz Zugang verkaufte und viele Nutzer aggregieren müsste. Öffentliche Einträge zeigen Bruchstücke der ersten beiden Kategorien und fast nichts von den letzten beiden.

Tunnel bringen spezifische Beschränkungen mit sich. Das äußere Paket verbraucht Bytes, was den für das innere Paket verfügbaren Raum vor Fragmentierung verringert. Eine Nichtübereinstimmung der maximalen Übertragungseinheit kann zu schlechter Leistung führen, die wie zufälliger Anwendungsfehler aussieht. Verschlüsselung verbraucht CPU und kann bei einer kleiner virtuellen Maschine oder einem Router zur Obergrenze werden. UDP-basierter Transport kann viele Netze effektiv durchqueren, bleibt aber Verlusten, Umordnung und Überlastung im Underlay ausgesetzt.

GRE hat weniger Sicherheits-Overhead, benötigt jedoch gesonderten Schutz, wenn Vertraulichkeit oder Authentifizierung erforderlich ist.

Ein 10-Gbit/s-Interface in Tokio ist daher eine Obergrenze an einem Punkt, nicht ein Versprechen zwischen Taiwan und Tokio. Der virtuelle Host kann eine geteilte vCPU haben, die Zugangsleitung in einen Taiwan-Ursprung kann 100 Mbit/s betragen oder der Internetpfad zwischen den Endpunkten kann zur Hauptzeit schwanken. Wenn drei Taiwan-Ursprünge jeweils von Consumer- oder KMU-Zugängen abhängen, können deren Upstream-Raten und Überlastungsrichtlinien wichtiger sein als der nominelle Tokio-Port.

Resilienz verbraucht Spielraum. Wenn zwei 100-Mbit/s-Ursprünge normalerweise jeweils 70 Mbit/s tragen, kann keiner den Verkehr des anderen nach einem Ausfall aufnehmen. Beide Leitungen sind installiert und beide sind aktiv, dennoch ist das Paar nicht vollständig redundant. Eine nützliche Kapazitätsangabe würde die Hauptzeitlast pro Ursprung, Paketverlust, Latenz, CPU-Spielraum, maximale Übertragungseinheit und die während eines Failovers beobachtete Last veröffentlichen. Haraguroicha veröffentlicht keine dieser Messgrößen.

Dieselbe Regel gilt für Präfixe. Die Fähigkeit, neun IPv6-Blöcke anzukündigen, zeigt nicht, wie viele in Gebrauch sind, wie viele Dienste dahinterstehen oder ob sie zwischen Ursprüngen bewegt werden können. Adresskapazität ist in IPv6 reichlich vorhanden. Weiterleitung, Rechenleistung, Zugang und Personal sind knapp. Adressen zu zählen würde das physische Netz um eine enorme Spanne übertreiben.

Was eine lokale Konnektivitätsrechnung tatsächlich kaufen würde

Es gibt keine öffentliche Endkundenrechnung von Haraguroicha, die analysiert werden könnte. Der Titel verweist stattdessen auf den Kostenblock, der nötig ist, um dieses Netz lokal zuverlässig zu machen. Für einen kleinen Overlay-Betreiber ist die wiederkehrende Rechnung nicht nur „Bandbreite“. Sie ist die Summe aus Underlay-Zugang, Transit, Hosting, Remote-Exchange-Zustellung, Ausrüstung, Strom, Verwaltung von Adressressourcen und der Zeit, die nötig ist, um diese aufeinander abzustimmen.

Die Zugangsleitung an jedem Ursprung kommt zuerst. Wenn ein Router in Neu-Taipeh das weitere Netz über einen Breitbandanschluss eines Drittanbieters erreicht, finanziert dieser Anschluss den lokalen Mast, die Leitung, die Glasfaser, das Koaxial- oder Funknetz, auch wenn Haraguroicha es nicht besitzt. Preis und Reparaturbedingungen verkörpern das lokale physische Netz. Einen zweiten Dienst hinzuzukaufen hilft nur, wenn der zweite Anbieter nicht dieselbe Letzte-Meile-Einrichtung least oder auf denselben Aggregationsstandort zurückführt.

Transit bezahlt die globale Erreichbarkeit. Peering kann die Entfernung oder Kosten ausgewählten Verkehrs verringern, aber ein kleines Netz kann Transit normalerweise nicht durch eine Sammlung experimenteller Exchanges ersetzen. Hosting fügt entfernten Punkten virtuelle Maschinen oder dedizierte Router hinzu. Exchange-Zustellung fügt einen Tunnel, ein VLAN, eine virtuelle Maschine oder ein Cross-Connect hinzu. Manche Dienste mögen kostenlos oder von der Community unterstützt sein, aber ein Preis von null bedeutet nicht null Abhängigkeit.

Es kann stattdessen keine vertragliche Wiederherstellungszeit, begrenzten Support und die Notwendigkeit bedeuten, dass der Betreiber mehr Probleme selbst lösen muss.

Hardware und Strom sind mengenmäßig geringer, aber im Fehlerfall entscheidend. Ein kompakter Router, Switch, Speichergerät oder Server muss ersetzt werden, wenn ein Netzteil, Lüfter oder Flash-Speicher ausfällt. Batterien müssen getestet und schließlich ersetzt werden. Eine virtuelle Maschine vermeidet lokale Hardware, überträgt aber die physische Abhängigkeit auf ihren Host und das Rechenzentrum. Die Kosten sind dann in der Miete und in der vom Anbieter angebotenen Reaktionsfähigkeit enthalten.

Personal ist der bindende Kostenfaktor in einem Ein-Personen- oder sehr kleinen Netz. Derselbe Ingenieur kann Routing-Richtlinien pflegen, Systeme aktualisieren, Berechtigungen erneuern, auf Abuse-Meldungen antworten, einen Tunnel diagnostizieren, sich mit einem Zugangs-Carrier abstimmen und ein lokales Gerät aufsuchen. Das öffentliche Profil des Betreibers zeigt breite technische Erfahrung, listet aber kein Haraguroicha-Netzbetriebsteam oder Feldpersonal auf. Fachkenntnis ist sichtbar; Personalstärke nicht.

Das erklärt, warum Routenvielfalt und Feldreparatur in denselben Satz gehören. Eine zweite BGP-Session ist nur nützlich, wenn jemand einen entfernten Routing-Fehler von einem toten Modem, einem ausgefallenen Netzteil, einem durchtrennten Zugangskabel oder einem verschlossenen Technikraum unterscheiden kann. Eine schnelle Routing-Änderung kann das Underlay nicht reparieren, auf dem beide Tunnel laufen. Umgekehrt kann ein Feldtechniker eine lokale Leitung wiederherstellen, während ein veralteter Routenfilter das Präfix unerreichbar hält. Der Dienst ist die gesamte Kette.

Fehlerpfad eins: Das Underlay bricht zuerst

Betrachten wir einen Neu-Taipeh-Tunnelursprung. Sein logisches Interface mag in Ordnung sein, seine kryptografischen Schlüssel gültig und seine BGP-Konfiguration unverändert. Wenn der Zugangs-Carrier ein Zuleitungskabel, einen Aggregations-Switch oder die lokale Stromversorgung verliert, erreichen die äußeren Pakete den entfernten Endpunkt nicht mehr. Der Tunnel verschwindet, weil das physische Netz unter ihm verschwunden ist.

Das unmittelbare Symptom mag wie ein Haraguroicha-Ausfall aussehen, selbst wenn keine seiner Softwarekomponenten ausgefallen ist. Die Verantwortung für die Wiederherstellung beginnt beim Eigentümer des Underlays. Haraguroicha kann eine Störung melden, Verkehr auf einen anderen Ursprung umleiten, eigene Ausrüstung ersetzen oder Diagnosen bereitstellen. Es kann nicht die Glasfaser eines anderen Carriers spleißen, ohne Genehmigung einen Straßenverteiler betreten oder die Reparaturwarteschlange des Carriers umpriorisieren.

Drei Taiwan-Ursprungsbezeichnungen könnten eine nützliche geografische Trennung bieten. Neu-Taipeh, das Zentrum von Taipeh und Taichung sind nicht dieselbe Stadt. Dennoch wird Unabhängigkeit nicht allein durch Namen belegt. Zwei Ursprünge können denselben landesweiten Carrier, dasselbe vorgelagerte Aggregationsnetz, denselben entfernten virtuellen Host oder dieselbe kontoebenenbezogene Steuerungsebene nutzen. Neu-Taipeh und Taipeh können großstädtische Leitungswege oder Einrichtungen teilen. Ein Taichung-Tunnel kann immer noch zu einem Taipeh-Hub zurückführen, bevor er den Transit erreicht.

Der Tokioter Ursprung mag einen weiter entfernten Wiederherstellungspunkt bieten, doch Entfernung bringt eine weitere Abhängigkeit: den internationalen Pfad. Taiwans Ministerium für Digitale Angelegenheiten hat in seiner Arbeit zurResilienz von Seekabelsystemenwiederholt diversifizierte Kommunikationssysteme und Backup-Routen betont. Dieser nationale Kontext identifiziert nicht den Pfad von Haraguroicha. Er zeigt jedoch, warum „Tokio“ nicht allein deshalb als unabhängig behandelt werden kann, weil es im Ausland liegt. Wenn das Underlay zwischen Taiwan und Japan auf ein Kabelsystem oder eine Carrier-Edge hinausläuft, folgt der logische Tunnel diesem gemeinsamen Risiko.

Ein echter Underlay-Test würde Traceroutes und Carrier-Leitungsaufzeichnungen von jedem Ursprung vergleichen, den ersten gemeinsamen Aggregationspunkt identifizieren, Gebäudeeingänge und Stromdomänen kartieren und dann einen Zugangsdienst unter Last ausfallen lassen. Öffentliche Routenkollektoren können die private erste Meile nicht sehen, und eine geografische Bezeichnung kann diesen Test nicht ersetzen. Bis solche Belege existieren, sollten die vier Ursprünge als Routing-Optionen mit unbekannter physischer Korrelation gezählt werden.

Fehlerpfad zwei: Strom oder ein Host entfernt den Router

Jeder Ursprung benötigt ein Gerät mit Stromversorgung. An einem lokalen Standort kann das ein Router und ein Zugangsmodem sein. An einem gehosteten Standort kann es eine virtuelle Maschine sein, die auf einem Server läuft, einem Top-of-Rack-Switch und der Stromversorgungskette des Rechenzentrums. Das öffentliche Material identifiziert keine dieser Komponenten für Haraguroicha, daher muss die Stromanalyse bedingt bleiben.

Das taiwanesische Verteilnetz ist insgesamt zuverlässig, aber nicht immun gegen lokale Ausfälle. Taipower berichtete im Januar 2026, dass Verteilungsvorfälle über dreizehn Jahre erheblich zurückgegangen seien und die Speiseleitungsautomation landesweit abgeschlossen wurde, erklärte jedoch auch, dass Naturkatastrophen, äußere Einwirkungen und Gerätefehler lokale Speiseleitungen auslösen können. DieserBericht zur Stromresilienzstützt zwei Schlussfolgerungen zugleich: Die Wiederherstellungsfähigkeit hat sich verbessert, und standortbezogene Ausfälle bleiben möglich.

Eine Batterie kann einen kurzen Ausfall nur überbrücken, wenn sie den vollständigen Pfad versorgt. Einen Router am Leben zu halten, während der Straßenverteiler oder Gebäudeswitch des Zugangsanbieters dunkel wird, erzeugt keinen Dienst. Einen gehosteten Router am Leben zu halten, während der Tunnel-Endpunkt am anderen Ende den Strom verliert, ergibt ebenfalls keinen Ende-zu-Ende-Pfad. Langzeitresilienz benötigt koordinierte Laufzeiten über lokale Geräte, Zugang, Hosting und Transit hinweg.

Stromdiversität muss ebenfalls physisch sein. Zwei virtuelle Router auf einem Server, zwei Server hinter einer Rack-Stromverteilereinheit oder zwei Ursprünge, die aus einem Gebäudeanschluss gespeist werden, überstehen den entsprechenden gemeinsamen Fehler nicht. Ein Generator ist nur nützlich, wenn er startet, Treibstoff hat, die tatsächliche Last trägt und die für die Geräte erforderlichen Kühlungs- und Zugangssysteme schützt. Keiner dieser Schutzmechanismen ist für Haraguroicha dokumentiert.

Host-Ausfälle können einem Stromausfall ähneln. Ein Hypervisor-Absturz, ein Speicherfehler, ein Netzwerk-Wartungsfenster, eine Kontosperrung oder Kapazitätsdruck können einen virtuellen Router entfernen. Das Vier-Ursprungs-Design kann dieses Risiko verringern, wenn die Ursprünge unabhängige Hosts und Anbieter nutzen. Es kann es verstärken, wenn dieselben Verwaltungszugangsdaten, Konfigurationsfehler oder Automatisierungsänderungen alle Knoten betreffen. Die öffentliche Seite listet Endpunkte auf, legt jedoch keine Host-Diversität offen.

Die Belege, die nötig sind, um die Strombewertung zu verbessern, sind konkret: Gerätestandort nach Einrichtungsklasse, Batterielaufzeit bei normaler Last, Generator- oder Host-Verpflichtung, Doppelstromstatus, Stromabhängigkeit des Zugangsgeräts, Alarmpfad und ein aufgezeichneter Failover während eines echten oder kontrollierten Ausfalls. Ohne diese Fakten bleibt Strom eine unbepreiste Zeile in der öffentlichen Beschreibung und eine potenziell dominante Zeile in der Zuverlässigkeitsrechnung.

Fehlerpfad drei: Eine Route existiert auf dem Papier, wird aber nicht genutzt

BGP ist dafür konzipiert, Pfade zwischen autonomen Systemen auszutauschen. Seine BasisspezifikationRFC 4271erlaubt es jedem Netz, Richtlinien auf das anzuwenden, was es lernt und ankündigt. Diese Richtlinienflexibilität ist der Grund, warum eine registrierte Import-Zeile, eine aktive Session und ein global bevorzugter Pfad unterschiedliche Dinge sind.

Die Registereinträge von Haraguroicha nennen AS41378 und AS38856 für AS57429 sowie AS38856 und AS20473 für AS212359. Wären beide Partner in jedem Paar live, separat zugestellt und in der Lage, alle Präfixe zu tragen, könnte das Netz eine nützliche Routenredundanz aufweisen. Die jüngsten globalen Ansichten zeigen diesen Zustand nicht. Sie zeigen einen dominanten AS38856-zu-AS57429-Pfad und einen AS57429-zu-AS212359-Pfad.

Mehrere Ursachen könnten die Lücke erklären, ohne einen Fehler zu implizieren. Eine Backup-Session könnte konfiguriert, aber inaktiv sein. Sie könnte nur an einem lokalen Exchange ankündigen, eine Teilmenge von Präfixen tragen, eine geringere Präferenz haben, außerhalb der Kollektorsicht liegen oder für manuelle Aktivierung reserviert sein. Das Register könnte schlicht veraltet sein. Jede Möglichkeit hat eine andere betriebliche Konsequenz, weshalb eine Liste von AS-Nummern kein Resilienzergebnis ist.

Routenfilter fügen einen weiteren Fehlermodus hinzu. Wenn ein Upstream Filter aus dem AS-HARAGUROICHA-Set baut, kann ein fehlendes Mitglied oder Präfixobjekt eine beabsichtigte Ankündigung blockieren. Wenn ein Sponsor eine Route-Origin-Authorization ändert, kann sich die Validierung ändern.BGP-Betriebsleitfäden in RFC 7454empfehlen Kontrollen wie Präfixfilterung und Limits genau deshalb, weil das Akzeptieren jeder Route unsicher ist. Diese Kontrollen schützen das Internet, aber ein kleiner Betreiber muss seine Registrierungen darauf abgestimmt halten.

Das aktuelle Validierungsergebnis ist eher ermutigend als vollständig: Sieben sichtbare Routen waren gültig, zwei waren unbekannt, nicht ungültig. Eine stärkere Position würde jeden beabsichtigten Ursprung gültig machen, auf unerwartete Ursprungsänderungen überwachen und eine aktuelle Präfixliste veröffentlichen. Sie würde auch realistische Maximalpräfix-Limits setzen, anstatt es Peers zu überlassen, sie aus einer breiten 50-Präfix-Zulassung abzuleiten.

Schnelle Fehlererkennung hilft nur, nachdem Diversität existiert. PeeringDB kennzeichnet BFD-Unterstützung bei den gelisteten AS57429-Exchange-Anbindungen als falsch.Bidirectional Forwarding Detectionkann einen Fehler im Weiterleitungspfad schnell erkennen, aber dieses Flag sagt nur, was für diese Exchange-Sessions deklariert ist; es beweist nicht, dass BFD anderswo fehlt. Selbst perfekte Erkennung kann keinen Verkehr auf einen Pfad verschieben, der dasselbe ausgefallene Underlay teilt oder keine Kapazität hat.

Fehlerpfad vier: Überlastung überlebt jede Routing-Session

Ein Pfad kann oben bleiben und dennoch Nutzer im Stich lassen. Paketverlust, hohe Latenz, Jitter oder eine verringerte maximale Übertragungseinheit können BGP etabliert lassen, während Anwendungen stocken. Tunnel sind besonders anfällig für diese Trennung, weil die Kontrollsession bei geringer Bandbreite überleben kann, selbst wenn die Datenebene stark überlastet ist.

Das selbst gemeldete Verkehrsband von 20–100 Mbit/s ist so bescheiden, dass ein 100-Mbit/s-Ursprung zur Hauptzeit-Obergrenze werden könnte. Wenn die Bezeichnung zutrifft, kann ein einzelner populärer Download, ein Backup oder eine einem anderen Netz angebotene Route die Auslastung erheblich verändern. Das Fehlen eines öffentlichen Verkehrsgraphen verhindert die Trennung von Durchschnittslast und Spitzen und verhindert den Test, ob der nominelle 10-Gbit/s-Port von Tokio jemals die von seiner Bezeichnung suggerierte Engpassentlastung wird.

Peering kann einige Pfade verkürzen, aber ein virtueller Exchange kann auch Kapselung und einen indirekten Weg hinzufügen. Poemas eigene Beschreibung ist ungewöhnlich offen, dass seine virtuelle Fabric keinen zusätzlichen Underlay-Durchsatz schafft. Wenn Verkehr über dieselbe lokale Zugangsleitung in Poema eintritt, die es sonst für Transit nutzen würde, kann die Änderung des BGP-Next-Hop die Richtlinie verändern, ohne die überlastete erste Meile zu beseitigen.

Überlastung während eines Failovers ist der ernstere Test. Freie Kapazität muss dort vorhanden sein, wo der Verkehr ankommt, nicht nur dort, wo er abgeht. Wenn der Neu-Taipeh-Ursprung ausfällt und Taipeh seine Routen übernimmt, benötigen der überlebende Tunnel, der Host und der Upstream alle Spielraum. Eine erfolgreiche Routenänderung gefolgt von 10 Prozent Paketverlust ist kein resilienter Dienst.

Der Betreiber könnte diese Frage mit einem kleinen Satz öffentlicher Messungen klären: 95. Perzentil des Verkehrs nach Ursprung, Latenz und Verlust zu stabilen Zielen, Interface-Fehler, Tunnel-Overhead, Routenänderungszeit und Leistung während eines erzwungenen Ausfalls. Cloudflare Radar bietet aggregierte Qualitätsansichten, wo es genügend Beobachtungen hat, legt jedoch keine Haraguroicha-Service-Level-Aufzeichnung offen und identifiziert keine Kundenzugangsleitungen. Kein öffentlicher Beleg zeigt derzeit die Hauptzeit- oder Failover-Leistung.

Feldreparatur beginnt an der Eigentumsgrenze

Die Formulierung „Feldreparatur“ im Titel benötigt einen präzisen Gegenstand. Es gibt keine nachgewiesene Haraguroicha-Mastenlinie, keinen Funkturm und kein Kundenanschlusskabel, die zu reparieren wären. Die Feldanlagen, die das Netz am plausibelsten stützen, gehören Zugangs-Carriern, Gebäudeeigentümern, Hosting-Unternehmen und Stromversorgern. Die eigene Feldarbeit von Haraguroicha mag sich auf einen Router, Server, Modem, Kabel und eine Stromversorgungseinheit an einer kleinen Anzahl von Ursprüngen beschränken.

Das macht Arbeitskraft nicht irrelevant. Es macht Koordination zur zentralen Fähigkeit. Wenn ein Ursprung ausfällt, muss jemand feststellen, ob der Fehler an der lokalen Ausrüstung, am Zugang, an der Stromversorgung, an der Tunnelkonfiguration, am entfernten Host, an der BGP-Richtlinie oder am Upstream-Routing liegt. Jede Diagnose führt zu einer anderen Partei und einer anderen Wiederherstellungsuhr. Ein kleiner Betreiber kann Stunden mit dem Nachweis der Eigentümerschaft verlieren, bevor die Reparatur beginnt.

Die öffentliche Kontaktoberfläche erscheint hoch konzentriert. Die administrativen und technischen RIPE-Kontakte verweisen auf dieselbe Person, und die Seite des Betreibers leitet Peering-Anfragen an eine Identität. Ein einzelner erfahrener Ingenieur kann ein leistungsfähiges Forschungsnetz betreiben. Das Resilienz-Problem ist die Verfügbarkeit: Krankheit, Reisen, konkurrierende Beschäftigung, verlorene Zugangsdaten oder ein Vorfall, der mehrere Knoten betrifft, können aus Fachkenntnis eine Warteschlange machen.

Ersatzteile sind das physische Gegenstück zu dieser Warteschlange. Ein in Neu-Taipeh gelagerter Ersatz-Router oder ein Ersatz-Netzteil repariert einen Taichung-Endpunkt nicht sofort. Ein Konfigurations-Backup hilft nicht, wenn niemand Zugang zum Gebäude hat. Eine gehostete virtuelle Maschine kann nur dann aus der Ferne neu aufgebaut werden, wenn Konto-Zugang, Images und Routenberechtigungen verfügbar sind. Kein öffentliches Material identifiziert Ersatz-Hardware, Remote-Hands, sekundäre Administratoren oder Out-of-Band-Zugang.

Der Arbeitstest sollte daher jedem Anlagenwert folgen. Wer kann den Standort betreten? Wer kann das Gerät ersetzen? Welche Reaktionszeit ist vertraglich vereinbart? Gibt es einen zweiten Administrator? Kann ein Upstream das Routing ändern, wenn der primäre Kontakt nicht verfügbar ist? Sind Konfigurationen und Schlüssel ohne den ausgefallenen Knoten wiederherstellbar? Dies sind gewöhnliche betriebliche Fragen, keine Forderung nach einem großen Personalstab. Für ein kompaktes Netz kann klare Delegation mehr Resilienz bieten als ein weiterer ungetesteter Tunnel.

Wer verliert den Dienst, wenn die Kette versagt

Die Antwort kann vernünftigerweise nicht mit „Teilnehmern“ beginnen, weil keine Teilnehmerbasis öffentlich ist. Die erste betroffene Partei ist der Betreiber selbst: Seine Präfixe, Router und Systeme können unerreichbar werden. Dienste, die innerhalb der neun sichtbaren IPv6-Ankündigungen adressiert sind, wären dem entsprechenden Ursprungs- oder Upstream-Ausfall ausgesetzt. Peers, die direkt Verkehr austauschen, könnten diese Route verlieren und auf Transit zurückfallen, falls eine Alternative existiert.

AS212359 ist eine klar sichtbare nachgelagerte Abhängigkeit in der Routing-Topologie. Wenn seine Pfade über AS57429 laufen, kann ein Fehler am Edge des neueren AS die Erreichbarkeit auch für das ältere System aufheben. Das ist eine technische Abhängigkeit, kein Beleg für eine separate Kundenorganisation.

Forschungsnutzer, Freunde, Mitarbeiter oder private Systeme könnten ebenfalls betroffen sein, aber die öffentliche Aktenlage identifiziert sie nicht. Sie zeigt auch nicht, dass ein Krankenhaus, eine Schule, ein lokales Unternehmen oder ein Haushalt für den Primärzugang auf Haraguroicha angewiesen ist. Solche Nutzer zu benennen, würde soziale Auswirkungen erzeugen, die die Belege nicht stützen können.

Das Fehlen nachgewiesener Kunden ändert das Ausmaß des Schadens, nicht jedoch die Technik. Ein Forschungsnetz kann autoritatives DNS, Monitoring, Softwaredienste oder Experimente hosten, deren Unterbrechung für ihre Betreiber bedeutsam ist. Es kann auch als Trainingsumgebung dienen, in der sicheres Scheitern Teil des Zwecks ist. Ohne einen Dienstkatalog ist die korrekte Beschreibung ein Verlust der Erreichbarkeit für Systeme und Peers, die die Haraguroicha-Routing-Domäne nutzen.

Wenn doch Endkundenzugang existiert, würde die Eigentumsgrenze das Nutzererlebnis bestimmen. Ein Kunde hinter einer letzten Meile eines Drittanbieters könnte physisch mit dem Zugangs-Carrier synchron bleiben, während er das Haraguroicha-Routing verliert. Ein anderer Kunde könnte die lokale Leitung verlieren, während die globalen Routen von Haraguroicha sichtbar bleiben. Der Support müsste diese Fälle unterscheiden und erklären, welche Reparaturwarteschlange gilt. Keine öffentlichen Bedingungen zeigen, wie diese Verantwortung aufgeteilt wäre.

Was würde echte Redundanz belegen

Der wertvollste Beweis wäre kein weiterer Städtename oder ein Exchange-Abzeichen. Es wäre eine Abhängigkeitskarte, die für jeden Ursprung den physischen Standort, den Zugangs-Carrier, den Tunnel-Endpunkt, den Host, die Stromquelle, den Router, den Upstream und die Routing-Richtlinie trennt. Eine geschwärzte Version könnte die Sicherheit wahren und dennoch zeigen, ob zwei Pfade eine Fehlerdomäne teilen.

Upstream-Diversität braucht einen Live-Test. Jeder beabsichtigte Transit sollte dieselben autorisierten Präfixe über eine separat zugestellte Leitung ankündigen. Jeder Pfad sollte die volle Hauptzeitlast tragen können. Ein kontrollierter Rückzug sollte den Verkehr innerhalb eines festgelegten Intervalls verschieben, wobei Verlust und Latenz innerhalb eines festgelegten Ziels bleiben. Kollektoransichten vor und nach dem Test würden zeigen, ob das Backup das weitere Internet erreichte.

Ursprungsdiversität braucht dieselbe Disziplin. Neu-Taipeh, Taipeh, Taichung und Tokio sollten an tatsächliche Hosting- oder Gerätegrenzen gebunden sein, nicht nur an Tunnelbezeichnungen. Unabhängigkeit würde bedeuten, wo praktikabel unterschiedliche Underlay-Carrier, getrennte Host-Konten und Stromdomänen, keinen einzelnen zentralen Tunnel-Konzentrator und genügend freie Kapazität an jedem Wiederherstellungspunkt.

Strombelege sollten die gemessene Laufzeit und die Abdeckung der Abhängigkeiten umfassen. Eine lokale Batterie, die das Zugangsgerät überdauert, ist nützlich; eine, die nur den Router schützt, ist es nicht. Ein gehosteter Ursprung sollte offenlegen, ob der Anbieter redundante Stromversorgung und Remote-Hands bietet. Das Netz sollte wissen, welche Pfade verschwinden, wenn ein Gebäude oder Carrier den Strom verliert.

Reparaturbelege sollten primäre und sekundäre Einsatzkräfte, Ersatzteilorte, Standortzugangsrechte und Eskalationskontakte identifizieren. Ein einfaches Vorfallsprotokoll, das Erkennung, Diagnose, Routenbewegung, physische Reparatur und Wiederherstellung zeigt, würde mehr offenbaren als ein statisches Netzdiagramm. Es würde auch zeigen, ob der Betreiber die Wiederherstellung bewerkstelligen kann, während der Hauptingenieur nicht verfügbar ist.

Schließlich sollte der kommerzielle Status getrennt vom technischen Status geklärt werden. Ein aktueller Tarif, eine bestellbare Adresse, ein Teilnehmervertrag, ein Registrierungsnachweis unter einem offengelegten rechtlichen Namen, eine Kundenzahlspanne oder eine unabhängig verifizierte Installation würden ein Zugangsgeschäft begründen. Ohne diese Fakten sollte das Netz weiterhin als eine Routing-Operation für Bildung oder Forschung beschrieben werden und nicht durch Schlussfolgerung in einen Endkunden-Carrier hochgestuft werden.

Die verantwortungsvolle Schlussfolgerung lautet: aktives Overlay, unbestätigtes Zugangsnetz

Haraguroicha Internet Service hat mehr Substanz, als eine dünne Firmenkarte vermuten ließe. Zwei ASNs sind weiterhin bei einem Ressourceninhaber registriert. Beide sind in einem gepflegten as-set gruppiert. Neun IPv6-Ankündigungen waren kürzlich sichtbar. Das neuere AS erscheint an Lambda-IX, das ältere an 4b42, und der Betreiber veröffentlicht vier Tunnelursprünge. Die meisten sichtbaren Routen besitzen eine gültige Origin-Autorisierung. Dies sind Anzeichen eines funktionierenden kleinen Netzes.

Dieselben Belege ziehen eine feste Obergrenze. Die Topologie drückt sich in Tunneln aus, nicht in eigener Glasfaser. Die größten Exchange- und Ursprungsbezeichnungen entsprechen nicht dem nutzbaren Durchsatz. Aktuelle Routenbeobachtungen verengen sich auf AS38856 und AS57429, trotz breiterer Registerrichtlinien. Exchange-Teilnahmen sind remote-fähig, und eine aufgeführte AS57429-Anbindung ist derzeit als nicht betriebsbereit markiert. Keine Einrichtung, keine Zugangsanlage, keine Stromreserve, kein Feldteam, keine Service-Level-Verpflichtung und kein Kundenstamm sind öffentlich.

Diese Kombination stützt eine mittlere Netzbelegnote und eine schwache Endkundenzugangsbehauptung. Haraguroicha kann als regionaler IPv6-Routing- und Peering-Betrieb mit Bezug zu Taiwan analysiert werden. Es kann noch nicht so analysiert werden, als besäße es ein Breitbandnetz in vier Städten oder verkaufe einen nachgewiesenen lokalen Dienst.

Die lokale Konnektivitätsrechnung ist daher eine Abhängigkeitsrechnung. Sie bezahlt Dritte für den Zugang, der die Tunnel trägt, das Hosting, das die Endpunkte am Leben hält, den Transit, der Ziele erreicht, die Peers nicht abdecken, die Stromversorgung unter jedem Gerät und die Menschen, die diagnostizieren, welcher Eigentümer was reparieren muss. Die Zahl der ASNs und Portbezeichnungen ist von Bedeutung, aber die Wiederherstellung hängt davon ab, ob diese Kosten wirklich unabhängige Routen und erreichbare Hände kaufen. Die öffentlichen Belege zeigen noch nicht, dass sie das tun.