Zusammenfassung

  • Indiens Department of Telecommunications führte Cloudnet Internet Service Private Limited als Inhaber einer Category B Internetdienstanbieter-Genehmigung für Tamil Nadu mit Wirkung zum 10. April 2023 auf. Unternehmensdatenseiten verbinden dieselbe Adresse und Kontaktdaten mit einem 2021 in Chennai gegründeten Unternehmen. Dies belegt eine regulierte ISP-Identität, kein Cloud-Computing-Produktportfolio.
  • AS150069 war am 10. Juli 2026 aktiv und kündigte103.21.6.0/23, beide/24-Komponentenrouten sowie2001:df1:66c0::/48an. Das IPv4-Aggregat war seit Oktober 2022 sichtbar, die IPv6-Route seit November 2022. Die aktuelle Routenautorisierung war unter RPKI gültig und die Registerdaten wurden kürzlich gepflegt.
  • Öffentliche Routenkollektoren zeigten nur einen unmittelbaren Nachbarn für AS150069: AS132774 von Niss Internet Services Private Limited. Dies ist ein Beleg für einen sichtbaren externen Routingpfad, nicht der Beweis, dass Cloudnet über keine private Verbindung oder Backup-Leitung verfügt. Es ist auch kein Beleg für physische Routendiversität, automatisches Failover oder Reservekapazität.
  • IPinfo charakterisiert AS150069 als Consumer-ISP mit ausgeprägtem Tag-Nacht-Verkehrsmuster und meldet nur eine gehostete Domain im Adressraum. Dies sind nützliche Signale, keine geprüften Kunden- oder Produktzahlen. Es wurden kein öffentlicher Cloudnet-Servicekatalog, kein Rechenzentrumsstandort, keine Rack-Bestandsliste, kein Angebot für virtuelle Maschinen, kein Bare-Metal-Angebot, kein Speicherdienst, keine Verfügbarkeitszusage, keine Backup-Richtlinie und kein Migrationsverfahren gefunden.
  • Die verantwortungsvolle Herabstufung erfolgt daher von einem vermuteten Cloud-Service-Betreiber zu einem kleinen, derzeit gerouteten Tamil Nadu ISP, dessen genaue Einzelhandelsabdeckung und physisches Netzwerk nicht offengelegt sind. Seine Ausfallsicherheit hängt von der lokalen Zugangsinfrastruktur, stromversorgten Aggregationsgeräten, der Übergabe an Niss, der Weiterleitungskonnektivität von Niss und dem Supportpersonal ab. Belege für tatsächlich gehostete Workloads wären erforderlich, bevor Cloudnet als Cloud-Anbieter diskutiert werden kann.

Die Cloud-Hypothese scheitert an der ersten Produktfrage

Das Wort „Cloudnet“ kann zu viel Arbeit leisten, wenn man es zulässt. Es kombiniert zwei modische Vokabeln der Netzwerkwelt, und das Unternehmen kontrolliert Internet-Nummernressourcen. Beides zeigt nicht, dass ein Kunde eine virtuelle Maschine, eine verwaltete Datenbank, einen Storage-Bucket, einen Bare-Metal-Server oder auch nur ein herkömmliches Webhosting-Konto kaufen kann. Die Unterscheidung ist wichtig, weil ein Cloud-Dienst Ausfall- und Wiederherstellungsverpflichtungen mit sich bringt, die ein Zugangsanbieter möglicherweise nie eingegangen ist.

Das aussagekräftigste unternehmensspezifische öffentliche Dokument ist kein Cloud-Katalog. Es ist dieListe der Internetdienstanbieter-Genehmigungen des Department of Telecommunications zum 31. Januar 2025. Der Eintrag weist Cloudnet Internet Service Private Limited, LizenznummerDS-11/401/2022-DS-III, Category B, Dienstgebiet Tamil Nadu, mit einem Gültigkeitsdatum 10. April 2023 aus. Der autorisierte Kontakt, die eingetragene Geschäftsadresse und die Telefonnummer stimmen mit den Unternehmens- und Internetregisterdaten des Unternehmens überein.

DieInternetdienst-Seite des Departmenterklärt, was Category B bedeutet. Es ist die Genehmigung, Internetdienste in einem lizenzierten Dienstgebiet anzubieten, das als Telekommunikationskreis oder Metropolregion definiert ist. DasUnified Licence Compendiumbeschreibt Internetzugang, IPTV und bestimmte Formen der Internettelefonie im Rahmen der Genehmigung. Die Lizenz ist ein materieller Beleg dafür, dass Cloudnet als ISP in Tamil Nadu tätig sein kann. Sie bescheinigt nicht, dass das Unternehmen landesweite Abdeckung aufgebaut hat, und sie macht aus einer Zugangsgenehmigung keinen Beleg für gehostete Rechenleistung.

Der Netzwerkdatensatz weist in dieselbe Richtung. DieIPinfo-Übersicht zu AS150069klassifiziert das Netzwerk als Consumer-ISP und stellt einen ausgeprägten täglichen Aktivitätsrhythmus fest, wie er mit Personen verbunden ist, die während der Wachstunden eine Verbindung nutzen. Es wird eine gehostete Domain gemeldet, verglichen mit 512 IPv4-Adressen. Die Anzahl gehosteter Domains unterliegt Messgrenzen: Eine Domain kann hinter einem Content-Delivery-Netzwerk sitzen, eine Adresse kann viele Namen hosten, ein privater Dienst ist möglicherweise nicht erkennbar und Zugangskunden können Server betreiben. Selbst mit diesen Einschränkungen ist eine beobachtete Domain kein positiver Beleg für eine Hosting-Infrastruktur.

Die öffentliche Präsenz von Cloudnet enthält keine Preise oder Spezifikationen für Rechenleistung, Speicher, Backup, Colocation oder verwaltete Infrastruktur. Es wird keine Adresse eines Rechenzentrums genannt. Es werden kein Server-Hersteller, keine Rack-Anzahl, kein Stromversorgungsdesign, keine Zertifizierung, keine Verfügbarkeitszone, kein Kundenportal, kein Service-Level-Agreement, kein Datenverarbeitungsnachtrag, keine Vorfallhistorie, kein Wiederherstellungsziel und kein Exportformat beschrieben. Ein Unternehmen kann privat verkaufen, ohne jeden Dienst im offenen Web zu dokumentieren, aber die Beweislast kehrt sich nicht um.

In Ermangelung eines Produkts und einer Betriebsfläche muss die Cloud-Behauptung verworfen und nicht ausgeschmückt werden.

Damit bleibt eine andere, fundiertere Geschichte. Cloudnet verfügt über ein lebendes autonomes System, eine ISP-Genehmigung für Tamil Nadu, eine kleine IPv4-Zuteilung, eine IPv6-Zuteilung und eine sichtbare Upstream-Abhängigkeit. Dies sind die Knochen eines Zugangsnetzwerks. Die physische Infrastruktur dahinter ist weitgehend nicht offengelegt, was die Bewertung der Ausfallsicherheit erschwert, das Netzwerk aber nicht imaginär macht.

Ein Unternehmen in Chennai und eine Genehmigung für Tamil Nadu

Unternehmensdatenaggregatoren identifizieren Cloudnet Internet Service Private Limited mit der Corporate Identification NumberU64120TN2021PTC142654. DieTofler-Unternehmensseitedatiert die Gründung auf den 8. April 2021, nennt ein genehmigtes Aktienkapital von 1 Mio. Rupien und ein eingezahltes Kapital von 100.000 Rupien und führt Logasundari und Gopikrishnan als Direktoren. DerZaubaCorp-Eintragliefert dieselbe CIN, Registrierung in Chennai und die Adresse in Kottivakkam, obwohl einige Datumsfelder in seinen gerenderten Zusammenfassungen inkonsistent sind und nicht als Ersatz für einen aktuellen Handelsregisterauszug betrachtet werden sollten.

Die Adresse ist für die Identitätsauflösung ungewöhnlich nützlich. Die Lizenzliste platziert das Unternehmen im dritten Stock von Plot 11/236A, Vivekanandar Third Street, Kottivakkam, Chennai. DieAPNIC-Registrierung für AS150069verwendet den abgekürzten Rechtsnamen CLOUDNET INTERNET SERVICE PVT LTD, und seine administrative Rolle wiederholt dieselbe Adresse und Telefonnummer. DerIPv4-Zuteilungseintragund derIPv6-Zuteilungseintragtragen denselben NetzwerknamenCNISPLund dieselbe Kontaktkette. Es handelt sich nicht nur um ähnliche Unternehmen mit einem generischen Namen; die Aufzeichnungen konvergieren auf ein Unternehmen.

Diese Konvergenz hält auch mehrere Namensvetter aus dem Bild. Ein separates Unternehmen Cloudnet Broadband Services Private Limited erscheint in älterem Lizenzmaterial aus Haryana, und Cloudnet Communications Private Limited erscheint in Teilnehmertabellen. Andere Unternehmen anderswo verwenden Cloud Net oder Cloudnet als Handelsnamen. Sie sollten nicht verwendet werden, um Lücken im Servicekatalog, der Kundenzahl oder der Geschichte dieses Unternehmens zu füllen. Der Identitätsanker ist hier die Tamil Nadu Lizenz, CIN, Kottivakkam-Adresse und AS150069.

Die DoT-Liste von 2025 ist ein Beleg für eine Genehmigung zu diesem Berichtsdatum. Sie ist kein tägliches Betriebszertifikat für Juli 2026. Andererseits liefern die aktiven Routen und kürzlich gepflegten Internetregisterobjekte viel aktuellere technische Beweise. Das Unternehmen sollte daher nicht nur als registriert oder historisch lizenziert beschrieben werden. Sein autonomes System trug zum Beobachtungszeitpunkt eine global sichtbare Ankündigung.

Die Adresse beantwortet immer noch nicht, wo sich die Netzwerkausrüstung befindet. Ein eingetragener Firmensitz kann ein Verwaltungsbüro, ein Point of Presence, beides oder keines von beidem sein. Der IPv4-Eintrag enthält die Koordinaten13.427804, 80.14154212, aber die Register-Geolokalisierung besteht aus vom Betreiber bereitgestellten Metadaten und ist keine Vermessung eines Routerraums. IPinfo platziert mehrere beobachtete Adressen oder Router in und um Chennai und Nagari, während seine jüngsten Sonden antwortende Adressen von Messpunkten im Raum Chennai erreichten. Eine solche Geolokalisierung ist probabilistisch. Sie kann kein optisches Leitungsendgerät identifizieren, den Besitz einer Glasfaserstrecke nachweisen oder belegen, dass ein Kunde in einer bestimmten Straße versorgt wird.

Die vertretbare geografische Aussage ist daher eng. Cloudnet ist für das Dienstgebiet Tamil Nadu autorisiert, in Chennai registriert und betreibt Adressraum, den unabhängige Messungen mit Indien und der Region Chennai verbinden. Die öffentlichen Beweise zeigen weder seine Einzelhandelsabdeckung innerhalb Tamil Nadus, noch dass es ganz Chennai versorgt, noch offenbaren sie einen Point of Presence außerhalb der registrierten Adresse.

AS150069 liefert aktuelle Betriebsbeweise

Ein autonomes System ist eine Einheit der Routing-Politik, kein vollständiges Geschäft. Dennoch ist AS150069 der klarste Beweis, dass Cloudnet jetzt etwas betreibt. DieAS-Übersicht von RIPEstatmeldete die ASN am 10. Juli 2026 als angekündigt. IhreAntwort zu angekündigten Präfixenlistete das IPv4-Aggregat103.21.6.0/23, die beiden spezifischeren Routen103.21.6.0/24und103.21.7.0/24sowie das IPv6-Präfix2001:df1:66c0::/48auf.

Das IPv4-Aggregat enthält 512 Adressen. Deraktuelle Routing-Statuszeigte AS150069 als einzigen sichtbaren Ursprung für das/23, gesehen von 326 der 327 meldenden IPv4-Peers. Er zeigte auch beide/24unter dem Aggregat. Separate Statusantworten für103.21.6.0/24und103.21.7.0/24verzeichneten denselben Ursprung und Sichtbarkeit. Dies war keine Spur, die nur für einen Beobachter sichtbar war.

Die Chronologie ist substanziell. DerRouting-Verlauf für das/23beginnt Cloudnets Aggregat-Ankündigung im Oktober 2022 und setzt sie bis zum Recherchedatum fort. Die beiden/24erschienen erstmals im Dezember 2022. Ihre Sichtbarkeit fiel für einen Zeitraum ab März 2025 stark ab, während das abdeckende/23weithin sichtbar blieb, und kehrte dann im Mai 2026 zu breiter Sichtbarkeit zurück. Dies ist eine Änderung der Routengranularität und -propagierung, kein Beleg dafür, dass der Kundendienst unterbrochen war. Verkehr zu den beiden Blöcken konnte weiterhin dem abdeckenden Aggregat folgen, wenn keine spezifischere Route sichtbar war.

IPv6 ist nicht nur eine Registerreservierung. DerRouting-Status für2001:df1:66c0::/48zeigte AS150069, das das Präfix am 10. Juli an alle 321 meldenden IPv6-Peers kündigte. Die Route wurde erstmals im November 2022 gesehen. Das Route-Objekt von APNIC wurde am 8. Juli 2026, zwei Tage vor der Beobachtung, geändert, und der zugehörige Kontaktdatensatz wurde ebenfalls im Juni aktualisiert. Diese Daten zeigen eine fortgesetzte Ressourcenverwaltung. Sie sagen uns nicht, wie viel Kundenverkehr IPv6 nutzt oder wie viele Nutzer es empfangen.

Die Unterscheidung zwischen installierter und nutzbarer Kapazität ist wesentlich. Ein/23ist ein Adresspool, kein Bandbreiteneinkauf. Fünfhundertzwölf IPv4-Adressen bedeuten nicht 512 Kunden, Server, Ports oder Megabits. Ein Anbieter kann Adressen für Router-Schnittstellen, Carrier-Grade-NAT-Pools, Geschäftsanschlüsse, Infrastruktur oder Reservebestände verwenden. Ein Haushalt kann mehrere öffentliche Adressen nutzen; viele Haushalte können eine Adresse teilen. Die fast unvorstellbar größere Anzahl numerischer Adressen in einem IPv6-/48ist als Kapazitätsmaß noch weniger nützlich.

Noch verdreifachen drei gleichzeitige IPv4-Ankündigungen das Netzwerk. Das/23und seine beiden/24-Komponenten decken denselben Adressraum ab. Spezifischere Ankündigungen können der Routing-Politik, dem Traffic-Engineering oder betrieblichen Übergängen dienen, aber die sichtbaren Routing-Daten geben nicht preis, welcher Zweck zutrifft. Das Aggregat und die Komponenten als 1.024 eindeutige IPv4-Adressen zu zählen, würde dieselben 512 Adressen doppelt zählen.

Die aktuellen Routen stützen ein reales, aktives Netzwerk. Sie zeigen keine Teilnehmerzugangstechnologie, Portanzahl, aggregierten Transit, Spitzenauslastung, Überbuchung, Backhaul, Cache-Kapazität oder Dienstgeschwindigkeit. Diese Größen bestimmen, ob eine verkaufte Verbindung während der abendlichen Spitze nutzbar ist. Keine kann aus der ASN berechnet werden.

Ein unmittelbarer Nachbar ist die sichtbare externe Grenze

DieAS-Nachbar-Ansicht von RIPEstatfand am 10. Juli 2026 einen unmittelbaren Nachbarn: AS132774. APNIC identifiziert diese ASN alsNiss Internet Services Private Limited, ein Netzwerk in Tamil Nadu, registriert in Tirunelveli. DerCIDR Report zu AS150069zeigt unabhängig dieselbe Adjazenz und keine Downstream-ASN.

Routenkollektoren sehen Topologie, keine Verträge. Eine AS, die Cloudnet in beobachteten Pfaden direkt vorausgeht, ist konsistent mit der Annahme, dass Niss Transit, verwaltetes Routing oder eine andere Form der Upstream-Erreichbarkeit bereitstellt. Sie verrät weder Preis, zugesagte Bandbreite, Burst-Bedingungen, physische Übergabe, Glasfaserlieferant, Kündigungsfrist, Wiederherstellungsverpflichtung noch ob Cloudnet die Dienstleistung direkt einkauft. Das kommerzielle Label „Upstream“ ist hier eine sinnvolle Schlussfolgerung, aber das öffentliche Ergebnis ist streng genommen ein sichtbarer externer BGP-Nachbar.

Die Unterscheidung wird wichtig, wenn es um Redundanz geht. Ein sichtbarer Nachbar ist ein Beleg gegen die Behauptung öffentlich nachgewiesener Upstream-Diversität. Es ist kein Beweis, dass Cloudnet nur ein Kabel hat. Cloudnet könnte zwei physisch getrennte Leitungen in verschiedene Router von Niss haben, während es denselben ASN-Pfad präsentiert. Es könnte eine Backup-Session haben, die zum Beobachtungszeitpunkt inaktiv war. Es könnte eine Default-Route über eine Verbindung erhalten, die für Kollektoren nicht sichtbar ist.

Umgekehrt könnten mehrere BGP-Sessions zu einem Anbieter auf einen einzigen Kabelkanal, ein Gebäude, einen Router oder eine Stromdomäne zusammenlaufen. Sitzungsanzahl und physische Diversität sind verschiedene Dinge.

Niss selbst hat eine breitere Topologie. SeinPeeringDB-Eintraglistet NIXI Chennai Peering und Einrichtungen in Chennai und Tirunelveli auf, währendbgp.toolsmehrere Upstreams für AS132774 auflistet. Dies sind selbst gemeldete und beobachtete Fakten über Niss, keine vererbten Eigenschaften von Cloudnet. Ein Cloudnet-Paket kann von den Weiterleitungsoptionen von Niss profitieren, nachdem es AS132774 erreicht hat, aber dass Niss mehrere Upstreams hat, beweist nicht, dass Cloudnet zwei unabhängige Wege zu Niss hat.

Die Live-Looking-Glass-Ansicht des/23von RIPEstatplatzierte AS132774 wiederholt unmittelbar vor AS150069 in gesammelten Pfaden. Viele Pfade passierten dann Bharti Airtels AS9498 jenseits von Niss. Dies deutet auf die sichtbare Kette in diesem Moment hin: Cloudnet, Niss und dann größere Transitnetzwerke. Es bedeutet nicht, dass Cloudnet einen direkten Airtel-Vertrag hat, und es bestimmt nicht, wo die physische Übergabe stattfindet.

Diese Grenze schafft einen klaren Fehlermechanismus. Wenn die einzige aktive Übergabe von Cloudnet an Niss ausfällt oder eine Routing-Session ohne funktionierende Alternative zurückgezogen wird, können alle global gerouteten Cloudnet-Adressen unerreichbar werden, selbst während Kunden-Glasfaser und lokale Switches weiterhin mit Strom versorgt werden. Wenn die Niss-Verbindung aufrechterhalten wird, aber ihre zugesagte Kapazität erschöpft ist, können Nutzer eher eine Überlastung als einen sauberen Ausfall erleben.

Wenn ein Routenfilter oder eine Autorisierung falsch ist, kann eine Adressfamilie oder eine Präfixlänge ausfallen, während andere weiter funktionieren.

Die Wiederherstellung hängt von Fakten ab, die nicht öffentlich sind: ob Cloudnet eine zweite Leitung hat; ob sie auf einem anderen Edge-Gerät endet; ob diese Leitung einem separaten Pfad folgt; ob das Failover automatisch erfolgt; ob das Backup genügend Kapazität für die normale Spitze hat; ob sowohl IPv4 als auch IPv6 übertragen werden; und welches Unternehmen die erste Reaktion übernimmt. Ein Diagramm mit zwei Linien würde nichts davon beweisen, wenn es nicht die physischen und vertraglichen gemeinsamen Punkte identifiziert.

Das physische Netzwerk beginnt dort, wo BGP aufhört zu erklären

BGP kann zeigen, dass AS150069 einen Adressblock erreichbar macht. Es kann nicht das Kabel von den Räumlichkeiten eines Kunden zum ersten aktiven Gerät zeigen. Zwischen diesen Punkten können sich ein optischer Netzwerkabschluss, Drop-Faser, Splitter, oberirdische oder erdverlegte Verteilungsfaser, ein optisches Leitungsendgerät, Ethernet-Aggregation, gemieteter Backhaul, Patchpanels, Stromversorgungen und Kühlung befinden. Die öffentlichen Beweise identifizieren nicht, welche dieser Komponenten Cloudnet nutzt oder besitzt.

Die Category B Genehmigung des Unternehmens erlaubt den Dienst im lizenzierten Dienstgebiet Tamil Nadu; sie bescheinigt kein bestimmtes Zugangsdesign. Cloudnet könnte Fiber-to-the-Home, Business-Ethernet, Funkstrecken, Dienste über lokale Kabelpartner oder eine Mischung betreiben. Es wurde keine öffentliche Abdeckungskarte, kein Plan, keine Spezifikation für ein optisches Netzwerk, kein Turm-Datensatz und keine lokale Kabelpartnerschaft gefunden. Die Präsenz von zwei antwortenden IP-Adressen in einemkürzlichen IPinfo-Scanzeigt, dass Endpunkte auf Messungen antworteten, nicht wie die letzte Meile aufgebaut wurde.

Diese unbekannte Eigentumsgrenze ändert, wer einen Ausfall repariert. Ein gekappter Kundenanschluss kann in der Verantwortung von Cloudnet oder eines lokalen Betreibers liegen. Ein Fehler in der Feeder-Faser kann eine Mastmannschaft, einen Tiefbauunternehmer oder den Eigentümer der gemieteten Faser erfordern. Ein Aggregationsfehler kann Ersatzoptiken, einen Switch, eine OLT-Karte oder eine Stromversorgung erfordern. Ein Backhaul-Fehler kann bei einem anderen Anbieter liegen. Der Kunde sieht einen nicht verfügbaren Dienst, während die Reparatur mehrere Organisationen durchläuft.

Die Stromversorgung bildet ihre eigene Kette. Kundengeräte benötigen Strom. Straßenverteiler, Funkstandorte, optische Leitungsendgeräte, Aggregationsswitchs und Edge-Router benötigen Strom. Dass ein eingetragener Firmensitz Strom hat, sagt nichts über einen entfernten Verteilerknoten aus. Eine USV kann eine kurze Unterbrechung überbrücken, hat aber eine endliche Laufzeit und Batterien, die altern. Ein Generator hilft nur, wenn er installiert, betankt, gewartet und mit dem betroffenen Standort verbunden ist.

Keine öffentliche Erklärung von Cloudnet gibt Auskunft über Backup-Laufzeit, Generatorabdeckung, Batteriewartung, doppelte Einspeisungen oder die Stromversorgungsarchitektur der Standorte.

Das Hardware-Inventar ist für ein kleines Netzwerk wichtig, da das ausgefallene Teil billig, aber betrieblich spezifisch sein kann. Ein Ersatzoptikmodul kann eine Verbindung schnell wiederherstellen, wenn es kompatibel und vorrätig ist. Eine ausgefallene Line Card, eine Stromversorgung oder ein Zugangschassis kann länger dauern, wenn es bestellt werden muss. Konfigurationssicherungen müssen aktuell und auf Ersatzgeräten verwendbar sein. Die öffentliche Aufzeichnung enthält keine Daten zur mittleren Reparaturzeit, keine Lagerrichtlinie, keine Herstellerliste und kein Wartungsfenster.

Das Support-Personal ist daher Teil der Kapazität. Ein Netzwerk kann ungenutzte Bandbreite haben und dennoch nicht verfügbar bleiben, weil kein Techniker eine Unterbrechung erreichen kann, kein Ingenieur eine Route ändern kann oder kein autorisierter Kontakt beim Upstream eskalieren kann. Cloudnets Register- und Lizenzdatensätze veröffentlichen eine einzige administrative Kontaktkette, aber diese Datensätze beschreiben kein besetztes Netzwerkbetriebszentrum, keine 24-Stunden-Feldabdeckung, kein Ticketsystem und keinen Bereitschaftsplan. Es wäre falsch, eine Kontaktnummer in ein Service-Level-Versprechen umzuwandeln.

Die Frage nach dem physischen Standort muss offen bleiben. Kottivakkam ist die Adresse des eingetragenen Firmensitzes. Registerkoordinaten deuten auf einen anderen Punkt im Norden Tamil Nadus hin, und Messungen von Drittanbietern assoziieren Adressen mit Chennai, Nagari und anderen Ortsbezeichnungen in Tamil Nadu. IP-Geolokalisierungsdatenbanken können die Adressregistrierung, abgeleitete Nutzerstandorte oder Messverzerrungen widerspiegeln. Nichts beweist, dass Cloudnet ein Rack in einem benannten Rechenzentrum hat oder Geräte an einem bestimmten Standort besitzt.

Abrechnung, Support und Verträge können ein intaktes Netzwerk unterbrechen

Nicht jeder Dienstausfall beginnt mit einem gekappten Kabel. Ein Zugangsanbieter muss Kunden identifizieren, Sitzungen autorisieren, Rechnungen ausstellen, Zahlungen akzeptieren, Tarifänderungen anwenden und einen säumigen Kunden von einem Netzwerkfehler unterscheiden. Je nach Design kann die Authentifizierung auf einer Teilnehmerdatenbank, einem RADIUS-Server, einem Breitband-Netzwerk-Gateway, einem optischen Netzwerkmanagementsystem oder der Plattform eines Wiederverkäufers beruhen. Die öffentliche Aufzeichnung gibt nicht preis, welche dieser Komponenten Cloudnet nutzt.

Sie belegt jedoch, dass die Kundenverwaltung eine separate Betriebsebene von BGP ist.

Diese Unterscheidung ist von außen leicht zu erkennen. AS150069 kann global sichtbar bleiben, während ein Konto keine Verbindung herstellen kann. Eine Zahlung, die dem falschen Konto zugeordnet wurde, eine abgelaufene Zugangsberechtigung, ein ausgefallener Authentifizierungsserver oder ein falsches Sperrflag kann sich als Ausfall am Router des Kunden darstellen. Das Außendienstpersonal stellt möglicherweise gesunde Lichtpegel und einen intakten Upstream-Pfad fest, doch der Dienst bleibt nicht verfügbar, bis die Kontosteuerung korrigiert ist. Ein Routenkollektor wird nichts davon aufzeichnen.

Die Kontinuität der Abrechnung ist auch während eines größeren Vorfalls wichtig. Kunden benötigen einen erreichbaren Kanal, um Störungen zu melden und festzustellen, ob eine Zahlung, ein Gerät oder ein Gebietsausfall verantwortlich ist. Das Personal benötigt aktuelle Kunden- und Netzwerkdatensätze. Wenn derselbe Strom-, Server- oder Konnektivitätsausfall sowohl den Zugangsdienst als auch seine Supportsysteme außer Kraft setzt, verlangsamt sich die Diagnose.

Cloudnets veröffentlichte regulatorische und Registerkontakte zeigen nicht, ob es über eine separate Kundenservice-Plattform, externe Aufzeichnungen, eine Notrufweiterleitung oder einen getesteten manuellen Prozess verfügt.

Der Großhandelsvertrag mit dem sichtbaren Nachbarn ist ein weiterer möglicher Kontrollpunkt. Eine Glasfaser und ein Router können technisch einwandfrei sein, während ein Anbieterstreit, eine abgelaufene Bestellung, eine unbezahlte Rechnung, eine Kapazitätsobergrenze oder eine abgelaufene Routenautorisierung den Dienst unterbricht. Es gibt keinen Beleg dafür, dass ein solcher Streit zwischen Cloudnet und Niss aufgetreten ist. Der Punkt ist strukturell: Wo die Erreichbarkeit von einem anderen Betreiber abhängt, gehört die kommerzielle Kontinuität zusammen mit Optik und Strom in die Bewertung der Ausfallsicherheit.

Ein Fehler im Anbietervertrag wird folgenreicher, wenn es keine nachgewiesene Alternative gibt. Einen Upstream zu wechseln erfordert mehr als die Bestellung einer Leitung. Der neue Anbieter muss eine Übergabe erreichen, Cloudnets Routen akzeptieren, Filter anwenden, IPv4 und IPv6 übertragen, gültige Routenautorisierungen unterstützen und ausreichend Kapazität bereitstellen. Der Kundenverkehr benötigt möglicherweise neue Defaults, DNS-Pfade oder Adressrichtlinien. Wenn die Migration überstürzt erfolgt, nachdem ein bestehender Dienst endet, kann das Netzwerk offline sein, obwohl Cloudnet weiterhin seine ASN und Präfixe kontrolliert.

Die Migration einzelner Zugangskunden wirft ein anderes Migrationsproblem auf. Wenn Cloudnet die Versorgung eines Gebiets einstellt oder Teilnehmer an einen anderen Betreiber übergibt, hängt die Kontinuität vom Eigentum an der Drop-Faser und den Kundengeräten, der Übertragbarkeit der Kontodatensätze, den Kündigungsfristen, Rückerstattungen und der Fähigkeit des Ersatzanbieters ab, den Dienst bereitzustellen. Öffentliches BGP zeigt möglicherweise keine Änderung, wenn die Adressen und der Ursprung gleich bleiben, oder eine große Änderung, wenn Kunden umnummeriert werden.

Keines der Ergebnisse allein erklärt, wer die Einzelhandelsverpflichtung übernommen hat.

Für einen echten gehosteten Dienst wäre die Migration noch schwieriger: Kunden bräuchten Datenexport, Maschinenimages, DNS-Kontrolle und Zeit für den Wiederaufbau. Dies ist ein Grund, warum die unbelegte Cloud-Hypothese nicht beiläufig behandelt werden darf. Sie impliziert Verpflichtungen zur Datenverwahrung und zum Datenausstieg, die in den Beweisen fehlen.

Für das Zugangsnetzwerk, das tatsächlich sichtbar ist, sind die unmittelbaren Fragen einfacher, aber immer noch unbeantwortet: Wem gehört die Teilnehmerbeziehung, wer kann die Authentifizierung wiederherstellen, wer eskaliert bei Niss und wie wird ein Kunde migriert, wenn diese Beziehung endet.

Installierte Kapazität ist keine Einzelhandelskapazität

Es gibt keine öffentliche Preisliste oder Geschwindigkeitstabelle von Cloudnet, die man mit dem Netzwerk vergleichen könnte. Selbst wenn es eine gäbe, wäre die beworbene Zugangsgeschwindigkeit immer noch nur die äußere Kante der Kapazitätsfrage. Ein 100-Mbit/s-Teilnehmertarif reserviert nicht zu jeder Stunde 100 Mbit/s durch jeden Aggregationsswitch, Backhaul und Transitlink. Anbieter bündeln Kapazität in der Annahme, dass die Kunden nicht alle gleichzeitig ihre maximale Rate abrufen.

Die relevanten Betriebsgrößen fehlen. Cloudnet veröffentlicht nicht die Anzahl aktiver Abonnements, den Geschwindigkeitsmix, den zugesagten Transit, die Peering-Kapazität, das Backhaul-Design, die Portauslastung, den Durchsatz in der Hauptverkehrszeit, das Überbuchungsverhältnis oder die Überlastungshistorie. Der 512-Adressen-IPv4-Pool füllt diese Lücken nicht. Carrier-Grade-NAT kann es weit mehr als 512 Kundengeräten ermöglichen, den Pool zu teilen; statische Geschäftsdienste können mehrere Adressen pro Konto verbrauchen; und IPv6 ändert die Adressierungsberechnung, ohne selbst ein Bit an Transitkapazität hinzuzufügen.

Cloudflare Radar hat einegeschätzte Population für AS150069im Bereich von Hunderten angezeigt, wobei die angezeigte Schätzung über Schnappschüsse und Unterseiten hinweg variierte. Solche Schätzungen verwenden Verkehrs- und Messsignale und nicht das Abrechnungssystem des Anbieters. Sie deuten auf eine kleine beobachtbare Nutzerpopulation hin und untermauern die Einstufung als Consumer-ISP, sollten aber nicht als Teilnehmerbuch zitiert werden. Ein Abonnement kann einen Haushalt oder ein Unternehmen mit vielen Personen versorgen, während einige Nutzer in den zugrunde liegenden Messungen möglicherweise nicht erscheinen.

Dieselbe Vorsicht gilt für gemessene Leistung. DieCloudflare-Seite zur Internetqualität für AS150069aggregiert verfügbare Geschwindigkeitstests und Netzwerkbeobachtungen. Eine Messung von einer antwortenden Adresse kann zeigen, dass ein Pfad zu einer bestimmten Zeit und an einem bestimmten Ort funktioniert hat. Sie kann keine Tarifgeschwindigkeit für jeden Teilnehmer zertifizieren, die Ausfallhäufigkeit über die Zugangsabdeckung quantifizieren oder offenbaren, ob die getestete Leitung repräsentativ ist. Kleine Stichproben sind besonders anfällig für Veränderungen in der Zusammensetzung.

TRAIsBreitbandqualitätsregulierung von 2024legt Benchmarks und Meldepflichten für Zugangs- und Breitbandanbieter fest, einschließlich Dienstbereitstellung, Netzwerkleistung, Störungsreparatur und Beschwerdebearbeitung. Dervierteljährliche Leistungsbericht vom Dezember 2024erläutert, dass die veröffentlichte Breitbandleistungsübersicht Anbieter mit mehr als 10.000 Teilnehmern abdeckte. Cloudnet ist in der öffentlichen Übersicht nicht als einer dieser großen Anbieter identifiziert. Diese Auslassung bestimmt nicht seine Größe oder befreit es von anwendbaren Verpflichtungen; sie bedeutet, dass die nationale Übersicht nicht als Cloudnet-spezifischer Leistungsbeleg verwendet werden kann.

Nutzbare Kapazität ist das, was nach Überlastung, Ausfall und Richtlinien übrig bleibt. Wenn ein Backup-Pfad nur einen Bruchteil des normalen Verkehrs trägt, kann nominelle Redundanz dennoch zu schwerer Überlastung führen. Wenn IPv4-Spezifikationen zurückgezogen werden, aber das Aggregat bestehen bleibt, kann die Erreichbarkeit mit geändertem Traffic-Engineering fortbestehen. Wenn IPv6 ausfällt, während IPv4 aktiv bleibt, können Nutzer Verzögerungen und anwendungsspezifische Fehler anstelle einer vollständigen Trennung erfahren.

Eine glaubwürdige Kapazitätsaussage würde Messungen zur Hauptverkehrszeit für beide Adressfamilien erfordern, nicht die Größe der zugewiesenen Präfixe.

Ein Cloud-Dienst würde einen anderen Beweissatz erfordern

Ein Zugangsanbieter und ein Cloud-Anbieter können Router, Adressen und Personal teilen, aber sie verkaufen unterschiedliche Versprechen. Der Zugangsdienst transportiert den Verkehr eines Kunden zu anderen Systemen. Gehostete Rechenleistung hält die Anwendung, Daten oder den Server eines Kunden auf der eigenen oder gemieteten Infrastruktur des Anbieters am Laufen. Das zweite Versprechen wirft Fragen auf, die der AS150069-Datensatz nicht beantworten kann.

Die erste ist der Vermögenswert. Ein glaubwürdiges Virtual-Server-Angebot sollte eine Rechenplattform identifizieren oder zumindest CPU, Arbeitsspeicher, Speicher, Netzwerk und Mandantenfähigkeit offenlegen. Bare Metal sollte Serverklassen und Bereitstellungsbedingungen identifizieren. Colocation sollte Einrichtung, Rack-Strom und Remote-Hands-Arrangements identifizieren. Managed Hosting sollte definieren, welche Betriebsaufgaben der Anbieter übernimmt. Kein hier gefundenes unternehmensspezifisches Material beschreibt eines dieser Produkte.

Die zweite ist der Standort. „Gehostet in Indien“ oder „gehostet in Chennai“ würde einen Beleg für die Einrichtung erfordern, in der sich Daten und Rechenleistung befinden. Eine in Indien registrierte ASN lokalisiert keinen Server. Verkehr kann durch ein indisches Netzwerk zu Geräten in einer anderen Einrichtung oder Gerichtsbarkeit geleitet werden; umgekehrt könnte Cloudnet indische Drittanbieter-Infrastruktur nutzen, die nicht in seinem eigenen Adressraum erscheint. Registerstaat und Datenresidenz sind getrennte Behauptungen.

Die dritte ist die Kontrolle. Wenn Cloudnet virtuelle Maschinen eines anderen Anbieters weiterverkauft, könnte Cloudnet Abrechnung und Support kontrollieren, während der zugrunde liegende Anbieter Racks, Hypervisoren, Strom und Teile kontrolliert. Wenn Cloudnet Colocation mietet, besitzt es möglicherweise Server, aber nicht die Gebäudesysteme. Wenn es einen eigenen Raum betreibt, könnte es dennoch von Vermietern und Anbietern abhängig sein. Kunden müssen wissen, wer die Stromversorgung wiederherstellen, eine Festplatte ersetzen, ein Backup wiederherstellen und Notfallzugang genehmigen kann. Kein öffentliches Dokument zieht diese Grenze.

Die vierte ist die Redundanz. Ein Cloud-Dienst kann Daten über Laufwerke, Hosts, Racks, Räume, Gebäude oder Regionen replizieren, wobei jedes gegen einen anderen Ausfall schützt. Zwei Kopien auf einem Host überstehen keinen Host-Ausfall. Zwei Hosts in einem Rack können sich eine Stromverteilungseinheit teilen. Zwei Racks in einem Gebäude können sich die Netzstromversorgung, Kühlung und die vorgelagerte Glasfaser teilen. Zwei Gebäude können dennoch von einem U-Bahn-Kabelkanal oder der Steuerebene abhängen. Ohne eine offengelegte Architektur und einen getesteten Wiederherstellungspfad sagt das Wort „Cloud“ nichts über die Fehlerdomäne aus.

Die fünfte ist der Ausstieg. Ein Kunde, der sich von einem Anbieterausfall erholt, benötigt ein exportierbares Image, einen Datenbank-Dump, eine Objektkopie, DNS-Kontrolle und genügend Zeit und Bandbreite für die Migration. Vertragskündigung, Abrechnungsstreit oder Unternehmensausfall können ebenso störend sein wie ein Hardwarefehler, wenn Zugangsdaten oder Daten an ein Konto gebunden sind. Es wurden keine Cloudnet-Bedingungen gefunden, die Datenrückgabe, -löschung, Migrationsunterstützung, Backup-Aufbewahrung oder Kontosperrung beschreiben.

Dies sind keine Behauptungen, dass Cloudnet die Fähigkeiten fehlen. Es sind die Mindestfragen, die die öffentlichen Beweise beantworten müssten, bevor diese Fähigkeiten zugewiesen werden. Ein privates Angebot, ein Vertrag oder ein technischer Anhang könnte die Schlussfolgerung für einen bestimmten Kunden ändern. Bis solche Beweise auftauchen, sollte AS150069 als Nachweis des Netzwerkbetriebs gelesen werden, nicht als Cloud-Produkt.

RPKI ist nützliche Routing-Hygiene, aber keine Ausfallsicherheit an sich

Cloudnet hat einen konkreten Schritt in der Routing-Sicherheit unternommen. DieRIPEstat-Validierung für das IPv4-Aggregatstellte eine gültige Route-Origin-Autorisierung fest, die AS150069 abdeckt und Ankündigungen bis zu/24erlaubt. Die Komponentenrouten sind daher unter derselben Autorisierung gültig. DieValidierung für das IPv6-/48war ebenfalls gültig.

RPKI hilft anderen Netzwerken, eine Ursprungsankündigung zurückzuweisen, die mit der signierten Autorisierung kollidiert. Es reduziert eine Klasse von Routing-Fehlern oder -Hijacks. Es verifiziert nicht jeden AS im Pfad, verschlüsselt keinen Verkehr, stoppt keinen Glasfaserbruch, bietet keinen zweiten Upstream, verhindert keine Überlastung und hält keinen Router am Laufen. Eine gültige Route kann zu einem nicht verfügbaren Dienst führen, wenn das ursprüngliche Netzwerk keinen funktionierenden Pfad zum Kunden hat.

Die aktuelle Kombination ist dennoch bedeutsam: registrierte Ressourcen, aktive IPv4- und IPv6-Ursprünge, Route-Objekte und gültige Ursprungsautorisierungen. Sie zeigt mehr betriebliche Reife als ein ruhender Firmenname. Sie schärft auch die Frage der Ausfallsicherheit, da die sichtbare Topologie eng bleibt. Korrekterweise autorisierte Erreichbarkeit über einen beobachteten Nachbarn ist immer noch ein beobachteter Nachbar.

Die spezifischeren IPv4-Ankündigungen fügen eine weitere betriebliche Besonderheit hinzu. Während des Zeitraums, in dem die/24eine geringe Sichtbarkeit hatten, blieb das/23-Aggregat weitgehend sichtbar. Das Ankündigen sowohl des Aggregats als auch der Spezifikationen kann eine abdeckende Route bewahren, wenn eine Spezifikation verschwindet. Es kann auch für Richtlinien oder zur Schadensbegrenzung verwendet werden. Öffentliche Kollektoren können das beabsichtigte Design nicht enthüllen, und das Aggregat schafft keinen zweiten physischen Pfad. Routing-Redundanz und Leitungsredundanz sollten nicht gleichgesetzt werden.

Auch IPv6 verdient eine begrenzte Schlussfolgerung. Das/48wird seit Jahren global angekündigt und sein Route-Objekt wurde kürzlich aktualisiert. Dies spricht für lebendes IPv6-Routing am Netzwerkrand. Es beweist nicht, dass jeder Privatkunde ein IPv6-Präfix erhält, dass die Kundengeräte es unterstützen oder dass das Support-Personal beide Protokolle gleichermaßen behebt. Eine anbieterspezifische Offenlegung oder kundenseitige Messung wäre nötig, um die Einsatztiefe zu ermitteln.

Die betroffenen Personen sind wahrscheinlich Zugangskunden, keine gehosteten Workloads

Der Tagesrhythmus von IPinfo, die ISP-Lizenz und das Fehlen eines Hosting-Katalogs deuten auf ein Zugangsnetzwerk hin. Cloudflares Schätzungen beobachtbarer Nutzer und antwortende Adressen im Raum Chennai stützen diese Richtung. Sie offenbaren weder Namen, genaue Standorte noch Kundentypen. Die wahrscheinlich betroffene Population ist daher bedingt: Haushalte, kleine Unternehmen oder institutionelle Nutzer, die Konnektivität über AS150069 oder den Zugangsdienst von Cloudnet beziehen.

Für einen Haushalt unterbricht ein Ausfall Messaging, Streaming, Fernarbeit, Bildung, Zahlungen und verbundene Geräte. Für ein kleines Unternehmen kann derselbe Ausfall Cloud-Anwendungen, Kartenzahlungen, Lieferantenkontakt und Kundenkommunikation stoppen. Ein Unternehmen, das eine statische Cloudnet-Adresse nutzt, kann auch die eingehende Erreichbarkeit zu einer Kamera, einem VPN-Endpunkt oder einem selbst gehosteten Dienst verlieren. Dies sind Mechanismen, keine Behauptungen, dass irgendeine namentlich genannte Organisation Cloudnet-Dienste kauft.

Die Abhängigkeit erstreckt sich über den Kontoinhaber hinaus. Ein lokaler Betreiber oder Wiederverkäufer kann Kunden hinter Cloudnets geroutetem Platz platzieren. Es war keine Downstream-ASN sichtbar, aber nachgelagerte Einzelhandelsvereinbarungen erfordern keine separate ASN. Wenn Cloudnet Kapazität an ein anderes Zugangsunternehmen liefert, könnte ein Fehler an der Cloudnet-Niss-Grenze Nutzer betreffen, die keinen der beiden Firmennamen kennen. Öffentliches Routing kann diese Vereinbarungen nicht zählen.

Verschiedene Fehler erzeugen unterschiedliche Symptome. Ein durchtrennter Anschluss betrifft ein Grundstück. Ein Splitter- oder Zugangsportfehler betrifft ein Cluster. Ein Aggregations- oder Backhaul-Fehler betrifft ein größeres Gebiet. Der Verlust der Niss-Übergabe kann die gesamte geroutete Fläche betreffen. DNS- oder Authentifizierungsfehler können Verbindungen aufrechterhalten, während Sitzungen fehlschlagen. Abrechnungs- oder Kontosystemfehler können einen einzelnen Teilnehmer ohne einen Netzwerkfehler trennen. Die öffentliche Aufzeichnung identifiziert nicht, welche Systeme Cloudnet selbst betreibt.

Die Wiederherstellung sollte vom Kundenrand aus gemessen werden. Eine BGP-Ankündigung wiederherzustellen reicht nicht, wenn die Feeder-Faser weiterhin unterbrochen ist. Glasfaser zu reparieren reicht nicht, wenn die Authentifizierung ausgefallen ist. Einen Switch mit Strom zu versorgen reicht nicht, wenn die Upstream-Session immer noch nicht verfügbar ist. Ein fundierter Vorfallsbericht würde die ausgefallene Schicht, den verantwortlichen Betreiber, die Beginn- und Wiederherstellungszeiten, das betroffene Gebiet, die Übergangslösung und ob die Kapazität vollständig wiederhergestellt wurde, identifizieren.

Das Fehlen einer öffentlichen Störungsseite oder einer Historie des Dienststatus verhindert ein Leistungsurteil. Schweigen beweist keine perfekte Zuverlässigkeit, und vereinzelte Nutzerberichte würden ohne Überprüfung keine netzwerkweite Rate belegen. Die aktuellen Beweise unterstützen die Abbildung der Fehlerkette, nicht die Bewertung der historischen Betriebszeit von Cloudnet.

Was ein stärkeres Betriebsbild etablieren würde

Das erste fehlende Element ist eine aktuelle kundenorientierte Dienstbeschreibung. Für den Zugangsdienst sollte sie Abdeckung, Zugangstechnologie, Tarifgeschwindigkeiten, Überlastungs- oder Fair-Use-Regeln, Installationsbedingungen, Störungskontakt und Dienstziele benennen. Für jeden gehosteten Dienst sollte sie Merkmale wie Rechenleistung, Speicher, Netzwerk, Backup und Migration angeben. Ein Logo und ein generisches Versprechen eines schnellen Dienstes wären nicht genug.

Das zweite ist eine physische und vertragliche Netzkarte auf einer angemessenen Abstraktionsebene. Cloudnet muss keine sensiblen straßengenauen Routen veröffentlichen. Es könnte die Anzahl aktiver Points of Presence, die abgedeckten Städte oder Dienstzonen, ob der Backhaul eigen oder gemietet ist und ob Upstream-Leitungen an getrennten Standorten enden und diversen Pfaden folgen, offenlegen. Der Schlüssel liegt darin, gemeinsame Fehlerdomänen zu identifizieren, ohne Betriebsgeheimnisse preiszugeben.

Das dritte sind Kapazitätsnachweise. Nützliche Messgrößen umfassen das gesamte und das Verkehrsaufkommen in der Hauptverkehrszeit, die Portauslastung, den zugesagten und Burst-Transit, die Failover-Kapazität, die Sättigung der Zugangsknoten und die IPv4/IPv6-Kundenadoption. Eine Momentaufnahme sollte ein Datum tragen. Designkapazität, installierte Schnittstellen, bestromte Kapazität und kundenverfügbarer Durchsatz sollten getrennt ausgewiesen werden.

Das vierte sind Wiederherstellungsnachweise. Cloudnet könnte die Backup-Stromversorgungslaufzeit pro Standortklasse, die Ersatzteilrichtlinie, die Eskalationsverantwortung, Wartungsfenster und die jüngste Wiederherstellungsleistung angeben. Eine Resilienzbehauptung wird glaubwürdig, wenn ein Fehler getestet wurde: Routenrückzug, Upstream-Verlust, Stromunterbrechung, Hardwareaustausch und Konfigurationswiederherstellung. Das Ergebnis sollte zeigen, ob der Dienst tatsächlich gewechselt ist und wie viel Kapazität verblieb.

Das fünfte ist eine unabhängige Bestätigung der Topologie. Ein zweiter sichtbarer Nachbar würde den Fall für Routing-Diversität stärken, würde aber dennoch einen physischen Pfadnachweis erfordern. Eine Backup-Leitung zur gleichen AS kann wertvoll sein, wenn sie in eine andere Einrichtung eintritt und gemeinsame Kabelkanäle vermeidet. Umgekehrt können zwei Anbieternamen denselben Letzte-Meile-Anbieter teilen. Verträge, Übergabeorte und Routenvermessungen klären, was BGP allein nicht kann.

Das sechste ist ein Nachweis für jede Cloud-Behauptung. Ein Einrichtungsname oder ein unabhängig überprüfbarer Standort, Kundenbedingungen, Infrastrukturspezifikationen, eine Angabe zum Datenstandort, Backup-Architektur, eine Verantwortungsmatrix für die Sicherheit und ein Ausstiegsverfahren würden die Diskussion von der Schlussfolgerung zur Produktanalyse bewegen. Eine einzelne gehostete Domain oder ein Server, der aus dem/23antwortet, würde keine kommerzielle Cloud-Plattform beweisen.

Bis diese Elemente existieren, bleiben Cloudnets stärkste Belege seine regulierte ISP-Identität und das lebende Routing. Die Unbekannten sind keine dekorativen Lücken. Sie sind genau die Stellen, an denen der Dienst ausfallen kann: Zugangsleitung, Aggregationsstromversorgung, Backhaul, Niss-Übergabe, Weiterleitungstransit, Support-Eskalation und Kundenwiederherstellung.

Ein lebendes kleines Netzwerk, mit einer engeren Geschichte als sein Name

CLOUDNET INTERNET SERVICE PVT LTD ist keine leere Unternehmenshülle. Es verfügt über eine Category B Internetdienstanbieter-Genehmigung für Tamil Nadu, eine konsistente Identität in Chennai in öffentlichen Aufzeichnungen, ein aktives autonomes System, eine 512-Adressen-IPv4-Zuteilung, ein angekündigtes IPv6-/48und gültige Route-Origin-Autorisierungen. Seine Routen sind seit 2022 sichtbar und seine Registerdaten wurden nahe am Beobachtungsdatum gepflegt.

Dieselben Beweise setzen eine feste Grenze. Ein unmittelbarer Routing-Nachbar war sichtbar. Kein öffentliches Material etablierte Upstream- oder physische Diversität, eine kartierte Zugangsabdeckung, installierte Bandbreite, Backup-Stromlaufzeit, Reparaturleistung vor Ort oder einen personell besetzten Support-Betrieb. Vor allem wurde durch nichts ein kommerzieller Cloud-, VPS-, Bare-Metal-, Colocation-, Speicher- oder Managed-Hosting-Dienst belegt.

Das ist kein enttäuschendes Ergebnis. Es ist ein nützlicheres. Der Name verschleiert nicht länger die Betriebsfläche, die tatsächlich beobachtet werden kann. Cloudnet scheint Zugangsverkehr in Tamil Nadu über AS150069 und Niss Internet Services zu transportieren. Seine Ausfallsicherheit wird durch gewöhnliche Infrastruktur bestimmt: Kabel, bestromte Elektronik, Backhaul, Routenkonfiguration, Ersatzteile und Menschen, die sie wiederherstellen können.

Der Netzwerkbeweisgrad ist Schwach für eine vollständige Infrastrukturbewertung, trotz starker Belege dafür, dass die ASN aktiv ist. Das Routing ist sichtbar; das physische und kommerzielle System dahinter nicht. Ein stärkerer Grad erfordert Nachweise, wo Kunden angebunden sind, wie der Verkehr ausgeht, was umschaltet, wie sich die Kapazität unter Stress verhält und wer jede Schicht repariert. Jede zukünftige Cloud-Dienst-Behauptung muss einen Schritt früher beginnen, indem bewiesen wird, dass es einen zu bewertenden gehosteten Dienst gibt.