Ein sichtbarer BGP-Nachbar, drei IPv4-/24er und kein IPv6: Der Failover-Test von Cactus Network Solutions

Zusammenfassung

• Am 16. Juli 2026 um 08:00 UTC beobachtete RIPE RIS, dass AS135632 die Präfixe103.77.9.0/24,116.206.164.0/24und116.206.167.0/24originierte: 768 IPv4-Adressen in drei Routen, ohne originierte IPv6. Jeder der 1.063 gesammelten AS-Pfade platzierte AS141421, MUX Broadband, unmittelbar vor Cactus.
• Die Belege weisen ein sichtbares benachbartes autonomes System nach, nicht ein physisches Kabel. Sie offenbaren nicht, wie viele BGP-Sitzungen, Übergaben, Schaltungen, Router, Gebäude, Dachrelais, Leerrohre oder Stromversorgungen unter dieser logischen Beziehung liegen.
• Das Routeninventar hat sich wesentlich verändert. RIPE sah im Juli 2025 acht IPv4-Präfixe und einen Nachbarn, Mitte Oktober keine von Cactus originierten Routen, bis April 2026 sieben Präfixe über AS141421 und bis Mai drei. Diese Beobachtungen belegen Routing-Änderungen, nicht Kundenverlust, physische Migration oder reduzierte installierte Kapazität.
• Cacti Website und Mail werden in AS31898 gehostet, nicht in AS135632, sodass diese öffentlichen Kontaktflächen bei einem Entzug von Cactus-originierten Routen erreichbar bleiben könnten. Der Kunden zugang, lokale Dienste, interne Vermittlung und Support-Operationen hängen von Vereinbarungen ab, die in öffentlichem Routing oder Firmenmaterial nicht sichtbar sind.

Die Sitzung stoppt um 08:00 UTC

Beginnen Sie mit dem Fehler, nicht mit der Broschüre.

Um 08:00 UTC stoppt die Edge-Sitzung, die die drei öffentlichen Präfixe von Cactus Network Solutions zu AS141421 trägt, den Austausch nutzbarer Erreichbarkeit. Die Ursache könnte eine ausgefallene Schnittstelle, ein upstream-Wartungsfehler, ein Router-Neustart, ein beschädigter Zugangsschaltkreis, ein Konfigurationsfehler oder Stromausfall an einem der Enden sein. Sobald ein Routenaufbewahrungsintervall abläuft und keine zweite Sitzung oder Nachbar beginnt, dieselben Präfixe anzukündigen, ist der Effekt außerhalb des Netzwerks einfach: Andere autonome Systeme lernen nicht mehr, wie sie103.77.9.0/24,116.206.164.0/24und116.206.167.0/24erreichen.

Dies ist keine hypothetische Topologie, die aus einem Firmennamen erfunden wurde. DerRIPEstat-Routing-Status-Snapshotzum Veröffentlichungszeitpunkt zählte drei originierte IPv4-Routen, 768 Adressen, keine IPv6-Routen und einen beobachteten Nachbarn. Der entsprechendeBGP-State-Captureenthielt 1.063 Collector-Pfade. AS135632 war in allen der Ursprung, und AS141421 war in allen der unmittelbar vorhergehende autonome System.

Was im Fehlermoment erreichbar bleibt, ist aufschlussreicher als das, was verschwindet.

Cacti öffentliche Domain löste sich in derA-Antwort von Google Public DNSzu192.185.56.104auf. RIPEsNetzwerkinformationsantwortfür diese Adresse platzierte ihre abdeckende Route in AS31898, außerhalb von AS135632. DerMail-Exchangerder Domain warmail.cactuspk.com,der sich zur selben extern gehosteten IPv4-Adresse auflöste. Ihreautoritativen Nameserververwendeten ebenfalls denwebsitewelcome.com-Namespace. Daher würde der Entzug von Cacti eigenen Routen nicht von selbst das Hosting-Präfix der öffentlichen Website oder das des Mail-Hosts entziehen.

Die Website könnte noch laden. Ein E-Mail-Server könnte noch E-Mails annehmen. Ein Anrufer könnte die veröffentlichte Telefonnummer über einen separaten Telekommunikationsdienst erreichen. Keines dieser Ergebnisse beweist, dass ein Cactus-Abonnent das weitere Internet erreichen kann. Mitarbeiter in einem von Cactus bedienten Büro könnten möglicherweise nicht auf die extern gehosteten Support-Systeme zugreifen, selbst wenn diese Systeme für alle anderen verfügbar bleiben.

Ein Kunde und ein Support-Ingenieur könnten somit entgegengesetzte Seiten desselben Fehlers sehen: Die Support-Seite ist aus dem Ausland online, während der Kundenkreis keinen nutzbaren Weg nach außen hat.

Lokale Kommunikation ist eine separate Unbekannte. Wenn Kundenzugangsfunkgeräte, Switches, Adressierung und lokale Dienste weiterhin mit Strom versorgt werden, könnten Pakete zwischen zwei Punkten innerhalb derselben Routing-Domäne weiterlaufen, auch ohne globale Route. Sie könnten auch von zentralen Systemen oder Pfaden abhängen, die mit der upstream-Übergabe ausfallen. Öffentliche Belege zeigen nicht die interne Topologie, ob Teilnehmer öffentliche oder private Adressierung verwenden, wo die Authentifizierung stattfindet oder ob lokaler Verkehr lokal geschaltet wird.

Die korrekte Antwort auf „was bleibt erreichbar?“ ist daher eine zu messende Liste, keine sichere Annahme.

Was die öffentliche Routing-Tabelle feststellt

BGP ist ein Inter-Domain-Erreichbarkeitsprotokoll. Die grundlegendeBGP-Spezifikationbeschreibt den Austausch von Präfixen und AS-Pfad-Informationen zwischen Routing-Systemen. Sie kodiert keine Straßenroute, Glasfaserzeichnung, Dachstandort, Stromversorgung, Portgeschwindigkeit oder Reparaturvertrag. Die Cactus-Belege müssen in diesen Schichten gehalten werden.

Zum Redaktionsschluss zeigte dasErgebnis der angekündigten Präfixevon RIPE für den 1. bis 16. Juli dieselben drei /24er durchgehend vom Beginn des angeforderten Intervalls bis zur letzten verfügbaren Beobachtung um 08:00 UTC am 16. Juli. Das Routing-Status-Ergebnis besagte, dass 320 von 326 IPv4-RIS-Peers die Routen sahen. Kein IPv6-Präfix war für einen der 321 IPv6-Peers in diesem Snapshot sichtbar.

Der Pfadbeweis pro Präfix ist ungewöhnlich konsistent. RIPE gab360 Pfade für103.77.9.0/24,360 für116.206.164.0/24und343 für116.206.167.0/24zurück. Jeder erfasste Pfad für jedes Präfix endeteAS141421 AS135632. Es gab keinen gesammelten Pfad, in dem ein anderes autonomes System direkt vor Cactus erschien.

Dieses Ergebnis ist stärker als die Aussage, dass ein kommerzielles Verzeichnis einen Anbieter auflistet. Es ist eine route-by-route-Beobachtung über Hunderte von Collector-Ansichten. Dennoch ist seine Grenze ebenso wichtig. Mehrere physische Verbindungen oder mehrere BGP-Sitzungen können zwischen denselben beiden autonomen Systemen existieren, während sie denselben AS-Pfad erzeugen. Umgekehrt kann eine BGP-Sitzung über Infrastruktur mit verborgener Schutz innerhalb eines Lieferantennetzwerks geführt werden. Der AS-Pfad allein kann diese Fälle nicht unterscheiden.

Das vom Betreiber gepflegtePeeringDB-Profil für AS135632identifiziert Cactus, auch unter dem Namen Sprint Broadband, als ein pakistanisches Kabel/DSL/ISP-Netzwerk. Es veröffentlicht keine Exchange- oder Facility-Zeilen. Diese Abwesenheit schränkt ein, was über PeeringDB verifiziert werden kann; es beweist nicht, dass Cactus keine Ausrüstung in einer gemeinsamen Einrichtung, keine private Zusammenschaltung, keinen entfernten Exchange-Zugang und keinen geschützten Großhandelsdienst hat.

APNICs öffentlicherOrganisationseintrag für ORG-CNSP1-APidentifiziert Cactus Network Solutions (CNS) Pvt Ltd als pakistanisches lokales Internet-Register und gibt eine Adresse in New Garden Town, Lahore an. DerMaintainer-Eintragund derIncident-Response-Kontakteintragbewahren dieselbe organisatorische Identität und aktuelle Kontaktverwaltung. Dies sind gute Belege dafür, dass das Unternehmen weiterhin ein aktiver Ressourceninhaber ist. Eine Verwaltungsadresse ist kein Beleg für einen Core-Router, ein Relay, ein Lager, einen Kundenaggregationspunkt oder eine upstream-Übergabe in diesem Gebäude.

Drei /24er sind weder Kapazität noch Kundenzahl

Ein /24 enthält 256 IPv4-Adressen. Drei /24er enthalten daher 768 Adressen. Diese Arithmetik ist exakt und betrieblich begrenzt.

Die Zahl offenbart keine Teilnehmer. Ein Haushalt könnte eine öffentliche Adresse erhalten, viele Haushalte könnten eine durch Carrier-Grade-Übersetzung teilen, ein Unternehmen könnte mehrere erhalten, und Infrastrukturschnittstellen könnten einen Teil des Pools verbrauchen. Adressen können auch reserviert, geroutet aber ungenutzt, für Netzwerkausrüstung verwendet oder dynamisch zugewiesen sein. Keine öffentliche Quelle legt Cacti aktuelle Adressierungspolitik dar.

Ebenso wenig offenbart die Adresszahl die Bandbreite. Ein 100 Mbit/s-Transit-Commitment und ein 10 Gbit/s-Transit-Commitment können dieselben drei Präfixe originieren. Die Routen sagen, wohin Pakete gehen sollen; sie geben nicht an, wie viel Verkehr die Übergabe vor Stau tragen kann, welche Klassen priorisiert werden, welche Burst-Bedingungen gelten oder wie viel Reservekapazität nach einem Fehler vorhanden ist.

Jedes /24 hat seine eigene Geschichte, aber denselben aktuellen Ausgang

Die drei aktuellen Routen sollten nicht als eine unteilbare Statistik behandelt werden. Jede wird unabhängig beworben, kann unabhängig zurückgezogen werden und kann eine andere Mischung aus Infrastruktur- oder Teilnehmeradressen tragen. Öffentliche Daten offenbaren diese Mischung nicht, aber sie machen das Routing-Verhalten jedes /24 separat beobachtbar.

Die niedrigere Pfadzahl für116.206.167.0/24ist kein Beleg für niedrigere Bandbreite oder schlechteren Kundenservice. Es bedeutet, dass in dieser erfassten Antwort weniger Collector-Pfade vorhanden waren. Collector-Teilnahme, Filterung und Timing können variieren. Was bei den drei Ergebnissen gemeinsam ist, ist wichtiger: Jeder erfasste Pfad verwendete AS141421 an der letzten externen AS-Grenze.

Es gab auch keine beobachtete abdeckende Route, die den Verlust einer spezifischeren Ankündigung auffangen würde. RIPE gab keinen BGP-Zustand für das abdeckende103.77.8.0/22oder116.206.164.0/22zum selben Zeitstempel zurück. Daher würde in der erfassten öffentlichen Tabelle der Entzug von103.77.9.0/24keine von Cactus originierte /22-Route hinterlassen, die es abdeckt. Gleiches gilt für die beiden sichtbaren116.206/24er.

Dieses Detail gibt Cactus zwei verschiedene Resilienzprobleme.

Das erste ist ein gemeinsamer Fehler. Wenn die Grenze AS135632-AS141421 aufhört, alle Exporte zu tragen, können alle drei Routen zusammen verschwinden, da sie denselben sichtbaren Nachbarn teilen. Das zweite ist ein selektiver Fehler. Ein Routenfilter, ein präfixspezifischer Richtlinienfehler oder ein lokales Originationsproblem können ein /24 entfernen, während die anderen beiden gesund bleiben. Kunden im betroffenen Bereich könnten unerreichbar sein, selbst wenn ein aggregiertes Dashboard anzeigt, dass AS135632 noch online ist.

Deshalb sollte ein externer Monitor mindestens eine kontrollierte Adresse in jedem originierten Präfix testen. Eine einzelne Sonde zur Firmenwebsite wäre nutzlos, da die Site außerhalb des Cactus-ASN liegt. Eine einzelne Sonde innerhalb von116.206.167.0/24würde einen selektiven Entzug von103.77.9.0/24übersehen. Die Erreichbarkeit sollte von mehreren unabhängigen Netzwerken aus getestet werden, wobei das Ergebnis mit dem BGP-Zustand zur gleichen Zeit verknüpft wird. Das würde mindestens drei Ereignisse unterscheiden: Route abwesend, Route vorhanden aber Endpunkt nicht erreichbar, Endpunkt erreichbar mit verschlechterter Paketzustellung.

Die Routenhistorie bietet dem Betreiber auch einen natürlichen Testfall.103.77.9.0/24kehrte nach fast vier Wochen Abwesenheit im April und Mai 2026 zurück, während116.206.164.0/24und116.206.167.0/24auf beiden Seiten dieses Intervalls sichtbar waren. Öffentliche Daten können nicht sagen, ob die zurückkehrende Route Teilnehmer, Infrastruktur oder ungenutzten Raum trug. Cactus kann das. Es könnte das Ereignis nutzen, um zu erklären, ob der Entzug geplant war, wie Adressnutzer behandelt wurden, welche Alarme ausgelöst wurden und warum die Route zurückkehrte.

Die vier nicht mehr nach dem 16. April sichtbaren /24er verdienen die gleiche disziplinierte Formulierung.103.77.10.0/24,103.77.11.0/24,116.206.165.0/24und116.206.166.0/24erschienen in RIPEs Historie und waren zum Redaktionszeitpunkt abwesend. Das ist eine Ankündigungstatsache. Es ist kein Beleg dafür, dass der entsprechende registrierte Adressraum verkauft, aufgegeben, widerrufen oder physisch getrennt wurde. Ein aktuelles Präfixinventar sollte jeden Block als geroutet, reserviert, intern genutzt, über eine andere Vereinbarung zugewiesen oder stillgelegt kennzeichnen, mit Datum und Autorität für den Zustand.

Für einen Käufer ist dies kein bürokratisches Detail. Wenn eine versprochene statische Adresse in einem /24 liegt, das manchmal unabhängig zurückgezogen wird, ist die Service-Level-Frage routenspezifisch. Wenn kritische Ausrüstung auf zwei der aktuellen /24er verteilt ist, kann das vor einem präfixspezifischen Fehler schützen, aber nicht vor der gemeinsamen AS141421-Grenze. Wenn alle Kunden-Übersetzungspools, DNS-Resolver und Verwaltungssysteme in einem /24 liegen, bieten die anderen beiden Routen möglicherweise weniger praktische Trennung, als die Routenzahl vermuten lässt. Die öffentliche Tabelle kann diese Platzierungen nicht offenbaren.

Der Drei-Routen-Fußabdruck ist daher klein genug, um präzise geprüft zu werden. Cactus kann ein nicht sensitives Inventar veröffentlichen, jedes Präfix überwachen, normale und alternative Exporte testen und bei jeder Routenänderung ein Ereignisprotokoll führen. Das wäre aufschlussreicher als eine breite Betriebszeit-Prozentsatz, da es genau zeigen würde, welche Adresspopulation unter welchem Fehler erreichbar blieb.

Die Unternehmenshomepage macht viel größer erscheinende Behauptungen, einschließlich Gigabit-Service, einem reinen IP-Wireless-Netzwerk, institutionellen Standleitungen und mehr als 20.000 vertrauenswürdigen Nutzern. Aber dieLive-Cactus-Homepageenthält auch Verkaufstexte über Breitbandpläne in Indien, Theme-Anbieter-Testimonials und generische Sprache, die nichts mit dem Lahore-Betreiber zu tun hat. DieKontaktseiteenthält eine Aivahthemes-Populäritätsbehauptung neben der Lahore-Adresse. Eine separateKontaktseitehat Beispiel-Details aus Chicago und New York. Diese Rückstände machen die numerischen Größenangaben der Site als Betriebstatsachen ungeeignet.

Die sicherere Schlussfolgerung ist kleiner. Die Site ist erreichbar, präsentiert Cactus als Residential- und Business-Internet-Provider, veröffentlicht Lahore-Kontaktdaten und spricht über drahtlose, Glasfaser- und Standleitungsdienste. Sie liefert keine zuverlässige aktuelle Teilnehmerzahl, bestellbare Abdeckungskarte, aktives Turminventar, Transitskapazität, Nutzungsreihe oder geprüfte Betriebszeitaufzeichnung. Der 768-Adressen-Routen-Fußabdruck sollte nicht mit Zahlen aus kompromittierten Verkaufstexten aufgebläht werden.

Eine unabhängigeIPinfo-Seite für AS135632bestätigt die aktuelle Drei-Präfix-, 768-Adressen- und Null-IPv6-Ansicht und bezeichnet das Netzwerk als Consumer-ISP. Sie berichtet auch von einer kleinen Gruppe von ping-responsive Cactus-Adressen. Diese Sonden unterstützen die Annahme, dass Endpunkte in den Routen von Pakistan aus antworten; sie identifizieren keine Kunden, aktive Servicebereiche, Funkstandorte, Überlastung oder Resilienz. Ein unabhängigesbgp.tools-Profillistet immer noch sieben IPv4-Präfixe und dieselbe upstream-ASN. Seine größere Zahl spiegelt ein breiteres oder anders getaktetes Inventar als die RIPE-Ansicht zum Veröffentlichungszeitpunkt wider. Der Unterschied ist ein Grund, Behauptungen mit Zeitstempeln zu versehen, nicht die größere Zahl auszuwählen.

Das Routeninventar hat sich bereits verändert

Der nützlichste Beleg zum Failover ist kein Versprechen. Es ist, was die Routen getan haben.

Am16. Juli 2025beobachtete RIPE, dass AS135632 acht IPv4-Präfixe originierte, die 2.048 Adressen abdeckten, ohne IPv6 und mit einem Nachbarn. Der an diesem Tag sichtbare Nachbar war AS24499, Telenor Pakistan, wie diehistorische Nachbarantwortzeigt. Dies ist ein Beleg für eine andere öffentliche upstream-Grenze als die im Juli 2026 gesehene.

DieEin-Jahres-Ankündigungshistorieverzeichnet dann einen scharfen Bruch. Die im Sommer 2025 sichtbaren Präfixe endeten am 26. September. DerUpdate-Stream für103.77.9.0/24zeigt weit verbreitete Entzüge nach Pfaden durch AS24499. In der Mitte Oktober-Routing-Status-Momentaufnahme erscheint kein von AS135632 originiertes Präfix.

Am 22. Oktober kehrten Ankündigungen zurück. DerUpdate-Stream um die Wiederherstellung herumzeigt neue Pfade, die mitAS141421 AS135632enden. Bis zum15. April 2026waren sieben IPv4-/24er durch einen beobachteten Nachbarn, AS141421, sichtbar. Vier dieser sieben hörten am 16. April auf zu erscheinen.103.77.9.0/24verschwand ebenfalls und kehrte am 12. Mai zurück. DieMomentaufnahme vom 13. Maihatte sich auf die aktuelle Gesamtzahl von drei eingependelt.

Diese Zeitstempel belegen drei Dinge.

Erstens hat AS135632 seine sichtbare upstream-Grenze geändert. Zweitens hat sich sein öffentlicher Routensatz im beobachteten Zeitraum von acht auf sieben auf drei verringert. Drittens gab es eine Zeitspanne von etwa 26 Tagen zwischen dem September-Entzug und der Oktober-Wiederherstellung, in der RIPE keine Ankündigung von AS135632 sah.

Sie belegen nicht, warum. Eine für den Collector sichtbare Abwesenheit könnte mit einer Anbietermigration, einer absichtlichen Routing-Änderung, der Nutzung von providerzugewiesenen Adressen, einem Richtlinienfehler, ausgesetztem Dienst oder einem anderen Zustand zusammenfallen. Sie sagt uns nicht, ob Einzelhandelskunden offline waren, hinter anderen öffentlichen Raum verschoben, über ein anderes ASN bedient wurden, private Konnektivität nutzten oder noch nicht aktiv waren. Ebenso beweist der Entzug von vier /24ern im April 2026 nicht, dass Cactus Kunden verloren oder Ausrüstung stillgelegt hat.

Diese Adressen könnten ungenutzt, gehalten, anders geroutet sein oder auf einen anderen Zweck warten.

Die Geschichte ist dennoch für einen Käufer relevant. Sie beweist, dass die öffentliche Konfiguration nicht statisch ist und dass ein Nachbarwechsel stattgefunden hat. Eine glaubwürdige Resilienzerklärung sollte daher nicht nur beantworten „wer ist heute upstream?“, sondern auch „wie lief der Verkehr während des letzten upstream-Übergangs weiter, welche Präfixe wanderten, wie lange dauerte die Konvergenz und was erlebten die Kunden?“

Ein Nachbar kann mehrere Schaltungen verbergen, aber nicht einen zweiten AS-Pfad

AS141421 wird von APNICsautonomen Systemeintragals MUX Broadband (Private) Limited in Pakistan identifiziert. Zum gleichen Redaktionsschluss zeigte MUX'RIPE-Routing-Statusfünf originierte IPv4-Präfixe, drei IPv6-Präfixe und sieben beobachtete Nachbarn. SeineNachbaransichtenthielt drei autonome Systeme, die vor MUX auf beobachteten Pfaden erschienen, und vier, die danach erschienen, eines davon AS135632.

MUX' breitere Konnektivität könnte den von ihr verkauften Dienst widerstandsfähiger machen als eine einzelne externe Verbindung. Diese Widerstandsfähigkeit kann nicht automatisch auf Cactus übertragen werden. Die fragliche Fehlergrenze ist die Grenze zwischen AS135632 und AS141421. Wenn MUX exzellente Routen zum weiteren Internet unterhält, aber Cactus seine Präfixe nicht an MUX liefern kann, helfen diese upstream-Optionen den Cactus-Adressen nicht. Dasselbe gilt, wenn ein gemeinsamer Cactus-Edge-Router, eine lokale Übergabe, eine Stromversorgung oder eine Konfiguration ausfällt, bevor der Verkehr MUX erreicht.

Gleichzeitig rechtfertigt das Ein-Nachbar-Ergebnis nicht, eine Linie auf einer Stadtkarte zu ziehen. Cactus könnte zwei Schaltungen zu MUX an verschiedenen Standorten, zwei Router auf einer Schaltung, zwei Sitzungen über einen geschützten Dienst oder eine ungeschützte Übergabe haben. MUX könnte Verkehr intern über redundante Infrastruktur leiten. Keines dieser Designs ist im AS-Pfad sichtbar. Der genaue physische Weg zwischen den Unternehmen, einschließlich der Frage, ob er Lahore, Multan oder eine benannte Einrichtung kreuzt, ist unbekannt.

Eine offizielle pakistanische Gesundheitsbeschaffungsbewertung erzeugt eine nützliche Spannung. Dertechnische Angebotsbericht vom 19. Juli 2023markierte Cactus mit „Ja“ gegen eine Anforderung, dass ein Bieter zwei upstream-Anbieter haben muss, geschrieben als PIE und TW1. Dieselbe Tabelle markierte es als konform für LL/CVAS-Lizenzierung und letztlich reagierend.

Dieses Dokument ist ein starkes Indiz dafür, was die Beschaffungsprüfer im Jahr 2023 akzeptierten. Es ist kein aktuelles BGP-Diagramm. Es identifiziert nicht die Schaltungen, ASNs, Standorte, Routenanzeigen, Vertragslaufzeiten oder das Failover-Verhalten hinter der Zwei-Upstream-Antwort. Die Anforderung könnte einen bestimmten verwalteten Dienst, Großhandelslieferanten hinter einem anderen Anbieter, damalige kommerzielle Kapazität oder Beweise betroffen haben, die nicht in der zweiseitigen Bewertung wiedergegeben sind.

Die gegenwärtige RIPE-Ansicht beantwortet dagegen eine engere Frage: Welches autonome System erschien direkt vor AS135632 in öffentlichen Pfaden am 16. Juli 2026? Die Antwort war nur AS141421.

Das Beschaffungs-„Ja“ und der Routing-Snapshot schließen sich daher nicht gegenseitig aus. Zusammen definieren sie die Sorgfaltspflicht-Frage. Cactus kann sie lösen, indem es die beiden aktuellen Fehlerdomänen identifiziert, zeigt, welche öffentlichen Präfixe jede trägt, und demonstriert, dass ein kontrollierter Verlust der einen dazu führt, dass die andere nutzbare Routen innerhalb eines angegebenen Intervalls ankündigt und weiterleitet.

IPv6 fehlt, aber es wäre kein magisches Backup

Das aktuelle Cactus-Routeninventar hat keine sichtbare zweite Adressfamilie. RIPE zählte null originierte IPv6-Präfixe im Juli 2025, April 2026, Mai 2026 und zum Redaktionszeitpunkt. IPinfo und bgp.tools berichten unabhängig dieselbe Abwesenheit. Cacti öffentliche Domain gab auch keine Adresse in derGoogle Public DNS AAAA-Antwortzurück.

IPv6 ist ein separates Netzwerkschichtprotokoll, spezifiziert inRFC 8200, mit einem viel größeren Adressraum als IPv4. In einem ordnungsgemäß entwickelten Dual-Stack-Dienst können ein Kunde und eine Anwendung sowohl IPv4- als auch IPv6-Erreichbarkeit haben. Client-Techniken, die vonHappy Eyeballs Version 2beschrieben werden, können die verfügbaren Familien auf eine Weise ausprobieren, die darauf abzielt, die für den Benutzer sichtbare Verzögerung zu reduzieren, wenn ein Pfad schlecht ist.

Aber IPv6 ist kein automatischer Ersatz für eine fehlgeschlagene IPv4-Route. Das Kundengerät muss eine funktionierende IPv6-Konfiguration erhalten. Das Zugangsnetz muss es tragen. DNS muss gegebenenfalls ein IPv6-Ziel veröffentlichen. Das Ziel muss über IPv6 erreichbar sein. Cactus muss ein IPv6-Präfix ankündigen, und die upstream-Beziehung muss es tragen. Keiner dieser öffentlichen Routenbelege existiert für AS135632 zum Redaktionsschluss.

Selbst wenn Cactus morgen IPv6 hinzufügen würde, würde die Adressfamilienvielfalt nicht unbedingt physische Vielfalt schaffen. IPv4 und IPv6 können denselben Router, dasselbe Funkgerät, dieselbe Faser, dieselbe Übergabe und dieselbe upstream-ASN durchlaufen. Ein Stromausfall oder eine Unterbrechung an dieser gemeinsamen Stelle würde beide entfernen. Umgekehrt könnte IPv6, das über einen unabhängig mit Strom versorgten und gerouteten Pfad geliefert wird, einige Dual-Stack-Anwendungen während eines IPv4-spezifischen Routing-Fehlers bewahren. Der Nutzen hängt von der Implementierung ab, nicht allein vom Vorhandensein einer IPv6-Zuweisung.

MUX' eigener Routenstatus beweist, dass der sichtbare Nachbar in der Lage ist, IPv6 zu originieren. Es beweist nicht, dass MUX Cactus einen IPv6-Dienst anbietet, dass Cactus einen angefordert hat oder dass die Kundengeräte bereit sind. Die Abwesenheit zum Veröffentlichungszeitpunkt ist daher spezifisch: Keine von Cactus originierte IPv6-Route war sichtbar. Der Grund, der Bereitstellungsplan und der Kundeneffekt sind unbekannt.

Dies ist sowohl wirtschaftlich als auch technisch relevant. Ein kleiner IPv4-Pool kann Adressfreigabe fördern, was eingehende Dienste, Missbrauchsbehandlung und Kundenattribution erschwert. IPv6 kann Adressknappheit reduzieren und die End-to-End-Erreichbarkeit für kompatible Dienste verbessern. Doch die Bereitstellung erfordert Unterstützung am Kundenstandort, Überwachung, Sicherheitsrichtlinien, Mitarbeiterpraxis und Helpdesk-Bereitschaft. Für einen regionalen Anbieter lautet der Test nicht „unterstützt der Upstream IPv6?“, sondern „kann ein Kunde es nutzen, kann der Betrieb es diagnostizieren und überlebt es einen definierten Fehler?“

Die letzte Meile wird angedeutet, nicht kartiert

Cactus präsentiert sich als lokaler Zugangsanbieter und nicht als reine Routing-Hülle. SeineServiceseitetrennt Residential-, Business- und individuelle Konnektivität. DieBusiness-Services-Seitespricht über dediziertes Breitband, Netzwerkmanagement und sichere Konnektivität. Die Homepage bezieht sich auf ein reines IP-Wireless-Netzwerk und bittet Benutzer, auf Türme in ihrer Umgebung zu prüfen.

Diese Beschreibungen unterstützen eine breite Schlussfolgerung, dass Cactus Last-Mile- und Unternehmenszugang, einschließlich drahtloser Lieferung, vermarktet hat. Sie legen keine aktuelle Turmzahl, Glasfaserroute, Pole-Grundstück, lizenzierte Spektrumsnutzung, Kundenstandortinventar oder Servicegrenze fest. Der Bestand an Stock-Theme-Rückständen der Site macht ihre Prozentsätze, Teilnehmerzahlen und breite Abdeckungssprache besonders schwach.

Ein konkreteres, aber historisches Dokument ist einCactus-Angebot vom 25. September 2020, das öffentlich auf Scribd hochgeladen wurde. Es schlug eine 20-Mbit/s-Punkt-zu-Punkt-Verbindung mit garantierter Informationsrate in Lahore vor, unter Verwendung zweier 34-dBi-Antennen und zweier 5-GHz-AirFiber-Einheiten. Es erlaubte zwei Tage für die Installation, beinhaltete wiederkehrende Verbindungs- und Turmwartung, bezog sich auf Frequenzregistrierung und wies ordnungsgemäße Stromversorgung und Erdung am Kundenstandort dem Kunden zu.

Das Angebot ist nützlich, weil es ein tatsächliches kommerzielles Design unter dem Namen Cactus beschreibt. Es ist begrenzt, weil es sechs Jahre alt ist, auf einen vorgeschlagenen Schaltkreis spezifisch ist, von einem Dritten gehostet wird und kein Beweis dafür ist, dass die Verbindung bestellt, installiert oder noch aktiv ist. Es kann nicht in eine aktuelle Karte von Cactus-Türmen extrapolatiert werden.

Es identifiziert jedoch Fehlerflächen, die für feste drahtlose Verbindungen technisch plausibel bleiben: Sichtlinie, Antennenausrichtung, Dachzugang, Funkgesundheit, Interferenzen, Stromversorgung am Kundenstandort, Erdung und Verfügbarkeit von Ersatzgeräten.

Keine geprüfte Quelle liefert Koordinaten für ein aktives Cactus-Relay oder einen Turm. Die Garden Town-Adressen in den Firmen- und APNIC-Einträgen sind Verwaltungskontaktadressen. Die Al-Qadir-Adresse im Angebot von 2020 ist eine historische Büroadresse. Keine sollte ohne separate Belege als Netzwerkknoten eingezeichnet werden.

Glasfaser ist ähnlich ungeklärt. Die Live-Site verwendet Glasfasersprache, und ein Anbieter kann Glasfaserzugang liefern, ohne jedes Kabel, jeden Leerrohr oder Mast zu besitzen. Öffentliches Material identifiziert nicht, ob Cactus Zugangsfasern besitzt, Stichleitungen least, einen anderen Carrier weiterverkauft, drahtlose und Glasfaser kombiniert oder Kunden an die Infrastruktur Dritter übergibt. Ein BGP-Pfad über MUX kann diese Frage nicht beantworten. Die logische Nachbarschaft könnte über jeder dieser physischen Anordnungen sitzen.

Strom und Feldreparatur entscheiden, ob eine Route nutzbar ist

Routing-Vielfalt ist nur wertvoll, wenn die Ausrüstung, die sie nutzt, mit Strom versorgt und reparierbar bleibt.

Betrachten Sie vier Fehler. Wenn ein Dachfunkgerät den Strom verliert, aber der Cactus-Edge weiterhin alle drei Präfixe ankündigt, kann die globale Routing-Tabelle gesund aussehen, während Kunden hinter diesem Relay offline sind. Wenn die Edge-Sitzung zu MUX ausfällt, während das Zugangsnetz mit Strom versorgt bleibt, können lokale Verbindungen bestehen bleiben, aber externe Ziele können verschwinden. Wenn sowohl die nominelle als auch die alternative Schaltung in dasselbe Gebäude führen und ein lokales Stromereignis den gemeinsamen Router deaktiviert, erzeugen zwei Verträge keine nutzbare Vielfalt.

Wenn ein Sturm eine Punkt-zu-Punkt-Antenne bewegt, stellt zusätzliche upstream-Kapazität die Sichtlinie nicht wieder her.

Das drahtlose Angebot von 2020 machte Stromversorgung und Erdung am Kundenstandort explizit zu einer Inbetriebnahmebedingung und schloss Schäden durch Überspannungen, Schwankungen oder unzureichende Erdung aus. Diese vertragliche Grenze ist betrieblich wichtig. Sie deutet auf mindestens ein historisches Cactus-Design hin, bei dem die Serviceverfügbarkeit teilweise von kundenkontrollierten elektrischen Bedingungen abhing. Sie offenbart nicht, ob Cactus unterbrechungsfreie Stromversorgung, Batterien oder Überspannungsschutz anderswo bereitgestellt hat oder welche Laufzeit ein Backup-System hatte.

Eine separateSupport-Services-Vereinbarung vom Dezember 2020, ebenfalls öffentlich hochgeladen, beschrieb zunächst Ferndiagnose und einen Vor-Ort-Besuch, wenn die Fernarbeit fehlschlug. Sie listete eine Support-Nummer, mehrere technische Kontakte und eine Management-Eskalationssequenz auf. Dies ist ein Beleg dafür, dass Cactus zu dieser Zeit eine Feld-Eskalationspraxis für einen Kunden dokumentierte. Es ist keine aktuelle Personalbesetzungsliste, Netzwerkfehlerverpflichtung oder Nachweis, dass dieselben Leute, Stunden und Reaktionszeiten 2026 Breitbandkunden abdecken.

Die aktuelleCactus-Kontaktseitelistet eine Awami Complex-Adresse in Garden Town, eine Telefonnummer, E-Mail und Bürozeiten von 9 bis 17 Uhr. Die Website behauptet an anderer Stelle umfangreichen oder rund um die Uhr Support. Da dieselben Seiten nicht verwandten Lagerbestand enthalten, erfordert das genaue Support-Versprechen eine Bestätigung in einem aktuellen Kundenvertrag.

Für einen kleinen Betreiber kann lokale Arbeitskraft die effektive Reserve sein. Ein Ersatzfunkgerät in einem Schrank ist nur nützlich, wenn jemand das ausgefallene Gerät identifizieren, Dachzugang erhalten, durch Lahore reisen, den Ersatz sicher ausrichten und den Fehler schließen kann. Eine zweite Transitsitzung ist nur nützlich, wenn jemand sie überwacht, die Richtlinienparität beibehält und bemerkt, wenn sie stillschweigend aufgehört hat, ein Präfix zu akzeptieren. Die Anzahl der Techniker ist weniger wichtig als die getestete Abdeckung von Fähigkeiten, Schichten, Zugriffsberechtigungen und Ersatzteilen.

Keine dieser Größen ist für Cactus öffentlich. Es gibt keine aktuelle mittlere Reparaturzeitreihe, Bereitschaftsplan, Ersatzteilbestand, Dachzugangsplan, Batterielaufzeit, Generatorrichtlinie, Kraftstoffreserve, Wartungsfenster, Überwachungsabdeckung oder Vorfallbericht. Ihre Abwesenheit im öffentlichen Material ist kein Beweis für schwachen Betrieb. Es bedeutet, dass ein Kunde die Widerstandsfähigkeit nicht allein aus der Website und der BGP-Tabelle bepreisen kann.

Route-Origin-Sicherheit ist ein anderer Test

Alle drei aktuellen Präfixe gaben einunbekanntesErgebnis von RIPEs Routen-Origin-Validierungsdienst zurück:103.77.9.0/24,116.206.164.0/24und116.206.167.0/24. Es wurden keine validierenden Route-Origin-Autorisierungen zurückgegeben.

Origin-Validierung, beschrieben inRFC 6811, erlaubt einem Router, ein angekündigtes Präfix und die Ursprungs-ASN mit kryptografisch verifizierbaren Autorisierungsdaten zu vergleichen. Ein unbekannter Zustand ist keine ungültige Route. Es bedeutet, dass das Validierungssystem keine abdeckende Autorisierung gefunden hat, die die Ankündigung gültig oder ungültig macht.

Das Veröffentlichen korrekter Autorisierungen könnte eine Klasse von Routing-Risiken reduzieren: Ein anderes Netzwerk, das versehentlich oder böswillig Cactus-Raum originieren könnte. Es würde keine zweite upstream schaffen, Bandbreite hinzufügen, ein Funkgerät mit Strom versorgen oder eine Reparaturreise verkürzen. Verfügbarkeit und Routen-Ursprungssicherheit sollten daher getrennt gemessen werden. Ein widerstandsfähiges Netzwerk kann dennoch schwachen Origin-Schutz haben, und eine vollständig autorisierte Route kann immer noch verschwinden, wenn ihre einzige nutzbare Übergabe ausfällt.

Eine testbare Resilienzbehauptung besteht aus fünf Teilen

Cactus muss keine sensiblen Diagramme offenlegen, um seine Widerstandsfähigkeit bewertbar zu machen. Es muss verifizierbare Antworten an den Grenzen veröffentlichen oder bereitstellen, an denen Fehler propagieren.

1. Exportieren Sie dieselben Routen über eine tatsächlich nutzbare Alternative

Identifizieren Sie für jedes der drei aktuellen /24er die normalen und alternativen externen Routing-Vorkehrungen. Wenn beide Sitzungen mit AS141421 sind, geben Sie an, ob sie auf verschiedenen Cactus-Routern, verschiedenen MUX-Geräten, verschiedenen Übergabestandorten und physisch unabhängigen Zugangsschaltungen enden. Wenn ein zweites autonomes System existiert, zeigen Sie, dass jedes Präfix davon akzeptiert und verbreitet wird.

Führen Sie dann einen kontrollierten Entzug der normalen Sitzung durch. Messen Sie die Zeit, bis externe Sonden durch die Alternative wieder stabile Erreichbarkeit erlangen. Testen Sie alle drei Routen, nicht eine repräsentative Adresse. Aufzeichnen Sie, ob zustandsbehaftete Kundensitzungen überleben, ob sich Übersetzungspools ändern und ob Rückwege nutzbar bleiben.

Die Beschaffungsantwort von 2023 zu zwei Upstreams macht diesen Test besonders angemessen. Ein Käufer sollte aktuelle Belege anfordern, anstatt anzunehmen, dass eine drei Jahre alte Angebotsantwort immer noch die Produktionskante beschreibt.

2. Trennen Sie logische Vielfalt von physischer Vielfalt

Dokumentieren Sie Übergabestandorte und gemeinsame Fehlerpunkte auf einem für den Kunden geeigneten Niveau. Zwei BGP-Sitzungen auf einem Router sind keine Router-Vielfalt. Zwei Schaltungen in einem Leerrohr sind keine Wegvielfalt. Zwei Funkgeräte an einer ungeschützten Stromversorgung sind keine Stromversorgungsvielfalt. Zwei Lieferanten, die beide von derselben Großhandelsverlängerung abhängen, sind möglicherweise keine Lieferantenvielfalt an dem Punkt, der zählt.

Der öffentliche AS-Pfad kann keine dieser Bedingungen auflösen. Cactus und seine Lieferanten können dies durch Schaltungskennungen, Abgrenzungsaufzeichnungen, diverse Eintrittserklärungen und eine kontrollierte Fehlerübung tun.

3. Behandeln Sie IPv6 als operativen Dienst

Ein IPv6-Plan sollte zugewiesenen Raum, Routenautorisierung, upstream-Beförderung, Kundenübergabe, Resolver-Verhalten, Firewall-Richtlinie, Überwachung und Support umfassen. Ein Pilot sollte beweisen, dass Dual-Stack-Kunden unabhängige Testziele über beide Familien erreichen und dass ein familienspezifischer Fehler keine inakzeptable Anwendungsverzögerung verursacht.

Wenn IPv4 und IPv6 dieselbe physische Übergabe teilen, sagen Sie es. Die zweite Familie verbessert immer noch die Adressverfügbarkeit und den Protokollzugang, aber sie sollte nicht als Schutz vor einem gemeinsamen Schaltungs- oder Stromausfall verkauft werden.

4. Messen Sie die Stromversorgung an jeder Abhängigkeit

Geben Sie die Backup-Laufzeit unter Last für den Edge-Router, die upstream-Übergabe, den Zugangsswitch, das Relaisfunkgerät und die im Dienst enthaltene Kundenstandortausrüstung an. Testen Sie Batterien, anstatt die Nennkapazität zu zitieren. Identifizieren Sie, welche Seite für Erdung, Überspannungsschutz und Ersatz verantwortlich ist. Wenn ein Generator verwendet wird, zeichnen Sie das Startverhalten, die Kraftstoffverfügbarkeit und die tatsächlich unterstützbare Last auf.

Das historische Angebot zeigt, warum diese Grenze wichtig ist: Ein Dienst kann technisch in Betrieb genommen werden, während eine entscheidende elektrische Abhängigkeit beim Kunden verbleibt.

5. Integrieren Sie die Feldwiederherstellung in das Serviceversprechen

Definieren Sie, wann die Reparaturuhr beginnt, welcher Beleg einen Fehler eröffnet, welche Stunden abgedeckt sind und welche Ereignisse die Uhr anhalten. Halten Sie kompatible Funkgeräte, Netzteile, Optiken und Router in bekannten Mengen vor. Überprüfen Sie den Zugang zu Dächern und Kundenstandorten außerhalb der Bürozeiten. Üben Sie die Eskalation, wenn die Ferndiagnose fehlschlägt.

Eine aktuelle Supportverpflichtung sollte die Rückschlüsse aus der Vereinbarung von 2020 und der gemischten Website ersetzen. Kunden benötigen die auf ihre Schaltung anwendbare Antwort, nicht eine alte Kontaktmatrix für einen anderen Dienst.

Wer trägt den Fehler

Die Auswirkung eines schmalen Rands unterscheidet sich je nach Kunde.

Ein Residential-Nutzer hinter Adressübersetzung kann möglicherweise jede externe Anwendung auf einmal ausfallen sehen, wenn die öffentlichen Routen verschwinden, während ein Nachbar in einem Mobilfunknetz die Cactus-Support-Seite noch laden kann. Ein Unternehmen, das eine öffentliche Cactus-Adresse verwendet, kann möglicherweise das Inbound-VPN, gehostete Dienste oder Remote-Kameras verlieren, sobald die Route zurückgezogen wird. Ein Managed-Connectivity-Kunde kann möglicherweise eine Zugangsverbindung und lokales Netzwerkmanagement behalten, verliert aber den im Vertrag enthaltenen Internetpfad.

Eine Institution, die einen Punkt-zu-Punkt-Dienst kauft, könnte zwischen zwei lokalen Standorten verbunden bleiben, selbst wenn der globale Transit ausfällt, abhängig davon, wo diese Schaltung vermittelt wird. Keines dieser Servicedesigns ist für einen benannten aktuellen Kunden bestätigt.

Der Betreiber trägt auch ein eigenartiges Kommunikationsrisiko. Da seine Website und Mail extern gehostet sind, kann die öffentliche Statusfläche einen AS135632-Ausfall überleben. Das ist potenziell nützlich: Cactus kann Updates von einer nicht betroffenen Verbindung aus posten. Es kann auch irreführend sein, wenn keine Statusseite zwischen „unsere Website ist online“ und „unsere Teilnehmerrouten sind erreichbar“ unterscheidet. Ein einfacher extern gehosteter Statusdienst mit unabhängigen Sonden für alle drei Präfixe würde diese Trennung in einen betrieblichen Vorteil verwandeln.

Die Wirtschaftlichkeit ist ebenso asymmetrisch. Die Unterhaltung einer zweiten upstream, von Ersatzroutern, Batterien und Feldbestand kostet Geld, auch wenn nichts ausfällt. Ein kleines öffentliches Adressinventar offenbart nicht, ob die Einnahmebasis diese Reserve unterstützen kann. Es beweist auch nicht, dass Cactus in Bezug auf die Teilnehmerzahl klein ist; Übersetzung kann viele Benutzer hinter wenige Adressen stellen. Was gesagt werden kann, ist, dass drei öffentliche Routen den beobachtbaren Fehler in eine kompakte Menge konzentrieren. Die Überwachung jedes Präfixes von mehreren externen Netzwerken ist technisch einfach.

Der Beleggrad ist Mittel, mit einer scharfen physischen Grenze

Cactus Network Solutions hat mehr öffentliche Betriebsbelege, als seine dünne Website zunächst vermuten lässt. AS135632 ist derzeit sichtbar. Drei IPv4-/24er wurden in der ersten Julihälfte durchgehend beobachtet. Hunderte von Collector-Pfaden erreichten jede Route. APNIC unterhält die Organisations- und Antwortkontaktaufzeichnungen. Die öffentliche Domain und die Kontaktkanäle funktionieren. Historische kommerzielle Dokumente zeigen, dass Cactus drahtlose Verbindungen und Vor-Ort-Support anbot, und eine offizielle Beschaffungsbewertung verzeichnet das Unternehmen als reaktionsfähigen Telekom-Bieter im Jahr 2023.

Der Routenbeleg ist stark für die enge Aussage, die er unterstützt. AS135632 originierte am 16. Juli 2026 um 08:00 UTC drei IPv4-/24er; keine IPv6-Route war sichtbar; und jeder gesammelte Pfad trat über AS141421 ein. Die Geschichte ist auch klar, dass sich sowohl der Nachbar als auch die Routenzahl geändert haben.

Der physische und Wiederherstellungsbeleg ist schwach. Es gibt keine verifizierte aktuelle Karte von Zugangsfasern, Türmen, Dachrelais, Übergabegebäuden oder diversen Eintrittswegen. Es gibt keine öffentliche Transitvereinbarung, Auslastungsstufe, Kundenzahl, Backup-Laufzeit, Ersatzteillager oder Reparaturleistung. Das alte Angebot und die Supportvereinbarung identifizieren plausible Abhängigkeiten, ohne das gegenwärtige Design zu beweisen.

Diese Kombination ist genau der Grund, warum der Titel eher ein Test als ein Urteil ist. Ein sichtbarer Nachbar beweist kein Kabel. Drei /24er beweisen kein winziges Unternehmen. Kein IPv6 beweist keinen bevorstehenden Fehler. Aber wenn die Sitzung, die diese Routen trägt, stoppt und keine alternative Ankündigung erscheint, hat der öffentliche Cactus-Adressraum keinen anderen sichtbaren Ort, an den er gehen kann. Die Website kann in einer anderen ASN online bleiben; das Schicksal des Kundennetzwerks wird durch Schaltungen, Router, Funkgeräte, Strom und Menschen entschieden, die Cactus nicht öffentlich überprüfbar gemacht hat.

Der entscheidende Beleg wäre ein von außen beobachteter kontrollierter Failover: Jedes /24 bleibt über einen unabhängig nutzbaren Alternativweg erreichbar, der Kundenverkehr wird innerhalb eines angegebenen Wiederherstellungsintervalls fortgesetzt, Dual-Stack-Dienst wird, wenn angeboten, getestet, und die Ausrüstung unter beiden Pfaden überlebt dieselbe Übung. Bis dahin ist Cactus' Widerstandsfähigkeit nicht widerlegt. Es ist einfach eine Betriebsbehauptung, die auf den einen Test wartet, den seine öffentliche Routing-Tabelle unmöglich zu vermeiden macht.