Zusammenfassung
- Die indische Telekommunikationsbehörde hat Cloudnet Internet Service Private Limited als Inhaber einer Internetdienstlizenz der Kategorie B für Tamil Nadu eingetragen, gültig ab 10. April 2023. Unternehmensdatenseiten verknüpfen dieselbe Adresse und Kontaktdaten mit einer 2021 gegründeten Firma in Chennai. Dies etabliert eine regulierte ISP-Identität, kein Cloud-Computing-Produktportfolio.
- AS150069 war am 10. Juli 2026 aktiv und kündigte
103.21.6.0/23, die beiden/24-Teilrouten und2001:df1:66c0::/48an. Das IPv4-Aggregat war seit Oktober 2022 sichtbar, die IPv6-Route seit November 2022. Die aktuelle Routenautorisierung war laut RPKI gültig, und die Registereinträge wurden kürzlich aktualisiert. - Öffentliche Routenkollektoren zeigten nur einen unmittelbaren Nachbarn für AS150069: AS132774 von Niss Internet Services Private Limited. Dies belegt einen einzelnen sichtbaren externen Routing-Pfad, nicht den Nachweis, dass Cloudnet keine private Interkonnektion oder Ersatzschaltung hat. Es ist auch kein Beleg für physische Routing-Diversität, automatisches Failover oder Überkapazität.
- IPinfo charakterisiert AS150069 als Endkunden-ISP mit ausgeprägtem Tag-Nacht-Verkehrsrhythmus und meldet nur eine gehostete Domain im Adressraum. Dies sind nützliche Signale, keine geprüften Kunden- oder Produktzahlen. Es wurde kein öffentliches Dienstleistungsverzeichnis, Rechenzentrumsstandort, Rack-Inventar, VM-Angebot, Bare-Metal-Angebot, Speicherdienst, Verfügbarkeitsgarantie, Sicherungsrichtlinie oder Migrationsverfahren von Cloudnet gefunden.
- Die verantwortungsvolle Herabstufung besteht daher darin, von einem vermeintlichen Cloud-Betreiber zu einem kleinen, derzeit gerouteten ISP in Tamil Nadu zu wechseln, dessen genauer kommerzieller Fußabdruck und physisches Netzwerk nicht offengelegt sind. Seine Widerstandsfähigkeit hängt von der lokalen Zugangsinfrastruktur, versorgten Aggregationsgeräten, der Anbindung an Niss, der vorgelagerten Konnektivität von Niss und der Support-Mannschaft ab. Es wären Belege für tatsächlich gehostete Arbeitslasten 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 lässt. Es kombiniert zwei trendige Netzwerkvokabeln, und das Unternehmen kontrolliert Internetnummernressourcen. Weder das eine noch das andere zeigt, dass ein Kunde eine virtuelle Maschine, eine verwaltete Datenbank, einen Speicher-Container, einen Bare-Metal-Server oder auch nur ein einfaches Webhosting-Konto kaufen kann. Die Unterscheidung ist wichtig, denn ein Cloud-Dienst hat Ausfall- und Wiederherstellungsverpflichtungen, die ein Zugangsanbieter möglicherweise nie übernommen hat.
Das solideste unternehmensspezifische öffentliche Dokument ist kein Cloud-Katalog. Es ist dieListe der Internetdienstanbieter-Lizenzen des Department of Telecommunications vom 31. Januar 2025. Der Eintrag identifiziert Cloudnet Internet Service Private Limited, LizenznummerDS-11/401/2022-DS-III, Kategorie B, Dienstbereich Tamil Nadu, mit Wirkung zum 10. April 2023. Der autorisierte Kontakt, die Geschäftsadresse und die Telefonnummer stimmen mit den Unternehmensregistern und Internetregistern überein.
DieSeite „Internetdienste“ der Behördeerläutert, was Kategorie B bedeutet. Es ist die Genehmigung, Internetdienste in einem lizenzierten Dienstbereich bereitzustellen, definiert als Telekom-Kreis oder Metropolregion. DasKompendium der Unified-Lizenzbeschreibt Internetzugang, IPTV und bestimmte Formen der Internet-Telefonie im Rahmen der Lizenz. Die Lizenz ist ein handfester Beweis dafür, dass Cloudnet als ISP in Tamil Nadu operieren kann. Sie bescheinigt weder eine landesweite Abdeckung noch verwandelt sie eine Zugangsgenehmigung in einen Nachweis für Rechenzentrumsdienste.
Die Netzwerkaufzeichnungen gehen in die gleiche Richtung. DieIPinfo-Übersicht für AS150069bezeichnet das Netzwerk als Endkunden-ISP und findet einen ausgeprägten täglichen Aktivitätsrhythmus, der mit Personen verbunden ist, die während der Wachstunden eine Verbindung nutzen. Es meldet eine gehostete Domain bei 512 IPv4-Adressen. Die Anzahl der gehosteten Domains hat Messgrenzen: Eine Domain kann sich hinter einem Content Delivery Network verstecken, eine Adresse kann viele Namen beherbergen, ein privater Dienst kann unentdeckt bleiben, und Zugangskunden können Server betreiben. Selbst mit diesen Vorbehalten ist eine beobachtete Domain kein positiver Beweis für einen Hosting-Bestand.
Der öffentliche Fußabdruck von Cloudnet enthält keine Preise oder Spezifikationen für Rechenleistung, Speicher, Backup, Colocation oder verwaltete Infrastruktur. Es wird kein Rechenzentrumsstandort genannt. Es werden kein Serveranbieter, keine Rack-Anzahl, kein elektrisches Design, keine Zertifizierung, keine Verfügbarkeitszone, kein Kundenportal, keine Service-Level-Vereinbarung, kein Datenverarbeitungsanhang, kein Vorfallverlauf, 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.
Ohne ein Produkt und eine Betriebsoberfläche muss die Behauptung „Cloud“ aufgegeben und nicht ausgeschmückt werden.
Dies hinterlässt eine andere, besser belegte Geschichte. Cloudnet hat ein aktives autonomes System, eine ISP-Lizenz für Tamil Nadu, eine kleine IPv4-Zuteilung, eine IPv6-Zuteilung und eine sichtbare upstream-Abhängigkeit. Das sind die Knochen eines Zugangsnetzwerks. Die physische Infrastruktur dahinter ist weitgehend unbekannt, was die Bewertung der Widerstandsfähigkeit erschwert, aber das Netzwerk nicht imaginär macht.
Eine Firma in Chennai und eine Lizenz für Tamil Nadu
Unternehmensaggregatoren identifizieren Cloudnet Internet Service Private Limited mit der Firmen-IdentifikationsnummerU64120TN2021PTC142654.Die Tofler-Unternehmensseitedatiert die Gründung auf den 8. April 2021, gibt ein genehmigtes Kapital von 1 Million Rupien und ein eingezahltes Kapital von 100.000 Rupien an und nennt Logasundari und Gopikrishnan als Direktoren.Der ZaubaCorp-Eintragliefert dieselbe CIN, die Registrierung in Chennai und die Adresse in Kottivakkam, obwohl einige Datumsfelder in seinen Zusammenfassungen inkonsistent sind und nicht als Ersatz für eine aktuelle Einreichung behandelt werden sollten.
Die Adresse ist besonders nützlich für die Identitätsauflösung. Die Lizenzliste platziert das Unternehmen im dritten Stock von Parzelle 11/236A, Vivekanandar Third Street, Kottivakkam, Chennai.Der APNIC-Eintrag für AS150069verwendet den abgekürzten legalen Namen CLOUDNET INTERNET SERVICE PVT LTD, und seine administrative Rolle wiederholt dieselbe Adresse und Telefonnummer. DerEintrag der IPv4-Zuteilungundder der IPv6-Zuteilungtragen denselben NetzwerknamenCNISPLund dieselbe Kontaktkette. Es handelt sich nicht nur um ähnliche Unternehmen, die einen generischen Namen teilen; die Einträge konvergieren auf ein einzelnes Unternehmen.
Diese Konvergenz schließt auch mehrere Namensvetter aus. Ein weiteres Cloudnet Broadband Services Private Limited taucht in älteren Lizenzdokumenten aus Haryana auf, und Cloudnet Communications Private Limited erscheint in Teilnehmerlisten. Andere Unternehmen anderswo verwenden Cloud Net oder Cloudnet als Handelsnamen. Sie sollten nicht verwendet werden, um Lücken im Dienstleistungskatalog, der Kundenzahl oder der Historie dieses Unternehmens zu füllen. Der Identitätsanker ist hier die Tamil-Nadu-Lizenz, die CIN, die Adresse in Kottivakkam und AS150069.
Die DOT-Liste von 2025 ist ein Beleg für eine Genehmigung zu diesem Berichtsdatum. Sie ist kein Zertifikat für den täglichen Betrieb im Juli 2026. Im Gegensatz dazu liefern die aktiven Routen und kürzlich gepflegten Internetregister-Objekte viel aktuellere technische Beweise. Das Unternehmen sollte daher nicht als lediglich registriert oder historisch lizenziert beschrieben werden. Sein autonomes System trug zum Zeitpunkt der Beobachtung eine weltweit sichtbare Ankündigung.
Die Adresse beantwortet immer noch nicht die Frage, wo sich die Netzwerkausrüstung befindet. Ein Geschäftssitz kann ein Verwaltungsbüro, ein Präsenzpunkt, beides oder keines von beidem sein. Der IPv4-Eintrag enthält die Koordinaten13.427804, 80.14154212, aber die Register-Geolokalisierung sind vom Betreiber bereitgestellte Metadaten, keine Untersuchung eines Routerraums. IPinfo platziert mehrere beobachtete Adressen oder Router in und um Chennai und Nagari, während seine neuesten Sonden antwortende Adressen von Viewpoints in der Region Chennai erreichten. Eine solche Geolokalisierung ist probabilistisch. Sie kann kein optisches Leitungsendgerät identifizieren, Eigentum an einer Glasfaserstrecke nachweisen oder feststellen, dass ein Kunde an einer bestimmten Straße bedient wird.
Die vertretbare geografische Aussage ist daher eng. Cloudnet ist für den Dienstbereich Tamil Nadu lizenziert, in Chennai registriert und betreibt einen Adressraum, den unabhängige Messungen mit Indien und der Region Chennai verbinden. Die öffentlichen Beweise kartieren seinen kommerziellen Fußabdruck innerhalb von Tamil Nadu nicht, zeigen nicht, dass es ganz Chennai bedient, und legen keinen Präsenzpunkt außerhalb der eingetragenen Adresse offen.
AS150069 liefert aktuelle Betriebsnachweise
Ein autonomes System ist eine Routing-Policy-Einheit, kein vollständiges Unternehmen. Dennoch ist AS150069 der klarste Beweis dafür, dass Cloudnet derzeit etwas betreibt.Die AS-Übersicht von RIPEstatmeldete die ASN am 10. Juli 2026 als angekündigt. SeineAntwort der angekündigten Präfixelistete 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::/48.
Das IPv4-Aggregat enthält 512 Adressen.Der aktuelle Routing-Statuszeigte AS150069 als einzige sichtbare Herkunft für das/23, gesehen von 326 der 327 meldenden IPv4-Peers. Es zeigte auch die beiden/24unter dem Aggregat. Separate Statusantworten für103.21.6.0/24und103.21.7.0/24verzeichneten dieselbe Herkunft und Sichtbarkeit. Dies war keine von einem einzigen Beobachter gesehene Spur.
Die Zeitachse ist substanziell.Der Routing-Verlauf für das/23beginnt mit der Ankündigung des Cloudnet-Aggregats im Oktober 2022 und setzt sich bis zum Suchdatum fort. Die beiden/24erschienen erstmals im Dezember 2022. Ihre Sichtbarkeit fiel in einem Zeitraum ab März 2025 stark ab, während das übergeordnete/23weitgehend sichtbar blieb, und kehrte im Mai 2026 zu breiter Sichtbarkeit zurück. Dies ist eine Änderung der Routengranularität und -verbreitung, kein Beweis dafür, dass der Kundendienst eingestellt wurde. Verkehr, der an die beiden Blöcke adressiert war, konnte dem übergeordneten Aggregat folgen, wenn eine spezifischere Route nicht sichtbar war.
IPv6 ist nicht nur eine Registerreservierung.Der Routing-Status für2001:df1:66c0::/48zeigte AS150069, das das Präfix am 10. Juli an alle 321 meldenden IPv6-Peers ankündigt. Die Route wurde erstmals im November 2022 gesehen. Das APNIC-Routenobjekt wurde am 8. Juli 2026, zwei Tage vor der Beobachtung, geändert, und der zugehörige Kontakteintrag wurde ebenfalls im Juni aktualisiert. Diese Daten zeigen eine kontinuierliche Verwaltung der Ressourcen. Sie sagen uns nicht, wie viel Kundenverkehr IPv6 nutzt oder wie viele Benutzer es erhalten.
Die Unterscheidung zwischen installierter und nutzbarer Kapazität ist entscheidend. Ein/23ist ein Adresspool, kein Bandbreitenkauf. Fünfhundertzwölf IPv4-Adressen bedeuten nicht 512 Kunden, Server, Ports oder Megabit. Ein Anbieter kann Adressen für Router-Schnittstellen, Carrier-Grade NAT-Pools, Geschäftskreise, Infrastruktur oder Reserveinventar verwenden. Ein Haushalt kann mehrere öffentliche Adressen verwenden; viele Haushalte können sich eine Adresse teilen. Die fast unverständlich größere Anzahl digitaler Adressen innerhalb eines/48IPv6 ist noch weniger als Kapazitätsmaß geeignet.
Drei gleichzeitige IPv4-Ankündigungen verdreifachen auch nicht das Netzwerk. Das/23und seine beiden/24-Komponenten decken denselben Adressraum ab. Spezifischere Ankündigungen können eine Routing-Policy, Traffic-Engineering oder einen Betriebsübergang unterstützen, 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 bedeuten, dieselben 512 Adressen doppelt zu zählen.
Die aktuellen Routen stützen ein reales und aktives Netzwerk. Sie zeigen nicht die Teilnehmerzugangstechnologie, die Anzahl der Ports, den aggregierten Transit, die Spitzenauslastung, die Überbuchung, das Backhaul, die Cache-Kapazität oder die Dienstgeschwindigkeit. Diese Größen bestimmen, ob eine verkaufte Verbindung zur abendlichen Spitzenzeit nutzbar ist. Keine kann aus der ASN berechnet werden.
Ein einziger unmittelbarer Nachbar als sichtbare externe Grenze
DieAS-Nachbarn-Ansicht von RIPEstatfand am 10. Juli 2026 einen einzigen unmittelbaren Nachbarn: AS132774. APNIC identifiziert diese ASN alsNiss Internet Services Private Limited, ein Netzwerk in Tamil Nadu, registriert in Tirunelveli. DieAS150069-Ansicht des CIDR-Reportszeigt unabhängig dieselbe Adjazenz und keine nachgelagerten ASNs.
Routensammler sehen die Topologie, nicht die Verträge. Eine AS, die Cloudnet in beobachteten Pfaden unmittelbar vorausgeht, ist damit vereinbar, dass Niss Transit, verwaltetes Routing oder eine andere Form der vorgelagerten Anbindung bereitstellt. Dies gibt den Preis, die gebuchte Bandbreite, die Burst-Bedingungen, den physischen Anschluss, den Glasfaseranbieter, die Kündigungsfrist, die Wiederherstellungsverpflichtung oder ob Cloudnet den Dienst direkt einkauft, nicht preis.
Die kommerzielle Bezeichnung „Upstream“ ist hier eine vernünftige Schlussfolgerung, aber das öffentliche Ergebnis ist strikt ein einziger sichtbarer externer BGP-Nachbar.
Die Unterscheidung wird wichtig, wenn es um Redundanz geht. Ein einziger sichtbarer Nachbar ist ein Beweis gegen die Behauptung einer öffentlich nachgewiesenen Upstream-Diversität. Es ist kein Beweis dafür, dass Cloudnet nur ein Kabel hat. Cloudnet könnte zwei physisch getrennte Schaltungen in verschiedenen Routern von Niss haben, während es denselben ASN-Pfad präsentiert. Es könnte eine Ersatz-Sitzung haben, die zum Zeitpunkt der Beobachtung inaktiv war. Es könnte eine Default-Route über eine Verbindung erhalten, die von den Sammlern nicht sichtbar ist.
Umgekehrt könnten mehrere BGP-Sitzungen zu einem einzigen Anbieter auf einer einzigen Leitung, einem Gebäude, einem Router oder einem Stromversorgungsbereich konvergieren. Die Anzahl der Sitzungen und die physische Diversität sind unterschiedliche Dinge.
Niss selbst hat eine breitere Topologie. SeinPeeringDB-Eintraglistet NIXI Chennai-Peering und Einrichtungen in Chennai und Tirunelveli, währendbgp.toolsmehrere Upstreams für AS132774 auflistet. Dies sind selbst gemeldete und beobachtete Fakten über Niss, keine geerbten Eigenschaften von Cloudnet. Ein Paket von Cloudnet kann von den Optionen von Niss profitieren, nachdem es AS132774 erreicht hat, aber die Tatsache, dass Niss mehrere Upstreams hat, beweist nicht, dass Cloudnet zwei unabhängige Wege hat, um Niss zu erreichen.
DieEchtzeitansicht von RIPEstat für das/23platzierte AS132774 wiederholt unmittelbar vor AS150069 in den gesammelten Pfaden. Viele Pfade gingen dann über AS9498 von Bharti Airtel hinaus zu Niss. Dies zeigt die zu diesem Zeitpunkt sichtbare Kette: Cloudnet, Niss, dann größere Transitnetze. Es bedeutet nicht, dass Cloudnet einen direkten Vertrag mit Airtel hat, und es legt nicht fest, wo die physische Verbindung stattfindet.
Diese Grenze schafft einen klaren Ausfallmechanismus. Wenn die einzige aktive Verbindung von Cloudnet zu Niss ausfällt oder eine Routing-Sitzung ohne funktionierende Alternative zurückgezogen wird, können alle weltweit gerouteten Cloudnet-Adressen unerreichbar werden, selbst wenn die Kundenglasfaser und die lokalen Switches weiterhin mit Strom versorgt werden. Wenn die Niss-Verbindung aktiv bleibt, aber ihre gebuchte Kapazität erschöpft ist, können Benutzer Überlastung statt eines Totalausfalls erleben.
Wenn ein Routenfilter oder eine Autorisierung falsch ist, kann eine Adressfamilie oder eine Präfixlänge ausfallen, während andere fortbestehen.
Die Wiederherstellung hängt von Fakten ab, die nicht öffentlich sind: ob Cloudnet eine zweite Schaltung hat; ob sie auf einem anderen Edge-Gerät endet; ob diese Schaltung einem getrennten Pfad folgt; ob das Failover automatisch ist; ob die Sicherung genug Kapazität für die normale Spitze hat; ob IPv4 und IPv6 beide transportiert werden; und welches Unternehmen die erste Antwort hält. Ein Diagramm mit zwei Linien würde nichts davon beweisen, es sei denn, es identifiziert die physischen und vertraglichen Gemeinsamkeiten.
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 des Kunden bis zum ersten aktiven Gerät zeigen. Zwischen diesen Punkten können sich ein optisches Netzabschlussgerät, eine Abzweigfaser, ein Koppler, eine Freileitungs- oder Erdverteilerfaser, ein optischer Leitungsabschluss, Ethernet-Aggregation, gemietetes Backhaul, Patchpanels, Stromversorgungen und Kühlung befinden. Die öffentlichen Beweise identifizieren nicht, welche dieser Elemente Cloudnet verwendet oder besitzt.
Die Kategorie-B-Lizenz des Unternehmens erlaubt den Dienst im lizenzierten Dienstbereich Tamil Nadu; sie bescheinigt kein bestimmtes Zugangsdesign. Cloudnet könnte Glasfaser bis zum Haus, Geschäfts-Ethernet, drahtlose Verbindungen, Dienst über lokale Kabelbetreiber oder eine Mischung betreiben. Es wurde keine öffentliche Abdeckungskarte, kein Bauplan, keine optische Netzwerkspezifikation, kein Turmeintrag oder keine lokale Kabelpartnerschaft gefunden. Das Vorhandensein von zwei antwortenden IP-Adressen imaktuellen Scan von IPinfozeigt, dass Endpunkte auf Messungen geantwortet haben, nicht wie die letzte Meile gebaut wurde.
Diese Grenze unbekannten Eigentums ändert, wer einen Ausfall behebt. Ein durchtrenntes Kundenabzweigkabel kann in der Verantwortung von Cloudnet oder einem lokalen Betreiber liegen. Ein Ausfall der Zuführungsfaser kann ein Mastteam, einen Bauunternehmer oder den Eigentümer der gemieteten Glasfaser erfordern. Ein Aggregationsausfall kann Ersatzoptiken, einen Switch, eine OLT-Karte oder eine Stromversorgung erfordern. Ein Backhaul-Ausfall kann von einem anderen Betreiber abhängen. Der Kunde sieht einen Dienstausfall, während die Reparatur mehrere Organisationen durchläuft.
Die Stromversorgung schafft ihre eigene Kette. Kundengeräte benötigen Strom. Straßenschränke, drahtlose Standorte, optische Leitungsabschlüsse, Aggregationsswitches und Edge-Router benötigen Strom. Die Tatsache, dass ein Geschäftssitz Strom hat, sagt nichts über einen entfernten Verteilungsknoten aus. Eine USV kann eine kurze Unterbrechung überbrücken, hat aber eine begrenzte Autonomie und alternde Batterien. Ein Generator hilft nur, wenn er installiert, betankt, gewartet und mit dem betroffenen Standort verbunden ist.
Keine öffentliche Aussage von Cloudnet gibt die Reserveautonomie, Generatorabdeckung, Batteriewartung, doppelten Stromversorgungen oder die elektrische Architektur des Standorts an.
Das Hardware-Inventar ist für ein kleines Netzwerk wichtig, weil das ausgefallene Teil billig, aber betrieblich spezifisch sein kann. Ein Ersatz-Optikmodul kann eine Verbindung schnell wiederherstellen, wenn es kompatibel und verfügbar ist. Eine ausgefallene Linecard, Stromversorgung oder ein Zugangs-Chassis kann länger dauern, wenn es bestellt werden muss. Konfigurations-Backups müssen aktuell und auf der Ersatzhardware verwendbar sein. Die öffentliche Akte enthält keine Daten zur mittleren Reparaturzeit, Bestandspolitik, Lieferantenliste oder zum Wartungsfenster.
Die Support-Mannschaft ist daher Teil der Kapazität. Ein Netzwerk kann ungenutzte Bandbreite haben und dennoch nicht verfügbar sein, weil kein Techniker einen Bruch erreichen kann, kein Ingenieur eine Route ändern kann oder kein autorisierter Kontakt eine Eskalation bei einem Upstream durchführen kann. Die Register- und Lizenzaufzeichnungen von Cloudnet veröffentlichen eine einzige administrative Kontaktkette, aber diese Aufzeichnungen beschreiben kein besetztes Netzbetriebszentrum, keine 24-Stunden-Feldabdeckung, kein Ticketsystem oder keine Eskalationsbereitschaft. Es wäre falsch, eine Kontaktnummer in ein Serviceversprechen umzuwandeln.
Die Frage des physischen Standorts muss offen bleiben. Kottivakkam ist ein eingetragener Geschäftssitz. Die Registerkoordinaten deuten auf einen anderen Punkt im nördlichen Tamil Nadu hin, und Messungen Dritter verbinden Adressen mit Chennai, Nagari und anderen Labels in Tamil Nadu. IP-Geolokalisierungsdatenbanken können die Adressregistrierung, abgeleitete Benutzerstandorte oder einen Messbias widerspiegeln. Es gibt keine Beweise dafür, dass Cloudnet ein Rack in einem benannten Rechenzentrum hat oder dass es Ausrüstung an einem bestimmten Standort besitzt.
Rechnungsstellung, Support und Verträge können ein intaktes Netzwerk unterbrechen
Nicht jeder Dienstausfall beginnt mit einem durchtrennten Kabel. Ein Zugangsanbieter muss Kunden identifizieren, Sitzungen autorisieren, Rechnungen ausstellen, Zahlungen annehmen, Tarifänderungen anwenden und ein überfälliges Konto von einem Netzwerkausfall 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 Akte gibt nicht preis, welche dieser Elemente Cloudnet verwendet.
Sie stellt fest, dass die Kundenverwaltung eine separate Betriebsschicht von BGP ist.
Diese Unterscheidung ist von außen leicht zu erkennen. AS150069 kann weltweit sichtbar bleiben, während ein Konto keine Verbindung herstellen kann. Eine dem falschen Hauptbuch zugeordnete Zahlung, ein abgelaufener Berechtigungsnachweis, ein ausgefallener Authentifizierungsserver oder eine falsche Sperrflagge können sich als Ausfall auf dem Router des Kunden darstellen. Feldpersonal kann gesunde optische Pegel und einen intakten Upstream-Pfad vorfinden, doch der Dienst bleibt nicht verfügbar, bis die Kontensteuerung korrigiert ist. Ein Routensammler wird nichts davon aufzeichnen.
Die Kontinuität der Rechnungsstellung ist auch während eines größeren Vorfalls wichtig. Kunden benötigen einen zugänglichen Kanal, um Ausfälle zu melden und festzustellen, ob eine Zahlung, ein Gerät oder ein Gebietsausfall verantwortlich ist. Das Personal benötigt aktuelle Konto- und Netzwerkaufzeichnungen. Wenn derselbe Strom-, Server- oder Konnektivitätsausfall sowohl den Zugangsdienst als auch seine Supportsysteme lahmlegt, verlangsamt sich die Diagnose.
Die von Cloudnet veröffentlichten Regulierungs- und Registerkontakte geben nicht preis, ob es eine separate Kundenplattform, externe Aufzeichnungen, Notrufumleitung oder einen getesteten manuellen Prozess gibt.
Der Großhandelsvertrag mit dem sichtbaren Nachbarn ist ein weiterer möglicher Kontrollpunkt. Eine Faser und ein Router können technisch gesund sein, während ein Streit mit dem Anbieter, eine abgelaufene Bestellung, eine unbezahlte Rechnung, ein Kapazitätsdeckel oder eine abgelaufene Routenautorisierung den Dienst unterbricht. Es gibt keine Hinweise darauf, dass ein solcher Streit zwischen Cloudnet und Niss aufgetreten ist. Der Punkt ist strukturell: Wenn die Reichweite von einem anderen Betreiber abhängt, gehört die Geschäftskontinuität ebenso zur Bewertung der Widerstandsfähigkeit wie Optiken und Strom.
Der Ausfall eines Lieferantenvertrags wird folgenreicher, wenn es keine nachgewiesene Alternative gibt. Der Wechsel des Upstreams erfordert mehr als die Bestellung einer Leitung. Der neue Anbieter muss einen Anschlusspunkt erreichen, Cloudnets Routen akzeptieren, Filter anwenden, IPv4 und IPv6 transportieren, gültige Routenautorisierungen unterstützen und ausreichend Kapazität bereitstellen. Der Kundenverkehr benötigt möglicherweise neue Default-Routen, DNS-Pfade oder Adressrichtlinien.
Wenn die Migration nach dem Ende eines bestehenden Dienstes überstürzt wird, kann das Netzwerk offline sein, selbst wenn Cloudnet weiterhin seine ASN und Präfixe kontrolliert.
Das Verschieben einzelner Zugangskunden wirft ein anderes Migrationsproblem auf. Wenn Cloudnet die Bedienung eines Gebiets einstellt oder Teilnehmer an einen anderen Betreiber übergibt, hängt die Kontinuität vom Eigentum an der Abzweigfaser und der Kundengeräte, der Übertragbarkeit von Kontenaufzeichnungen, Kündigungsfristen, Rückerstattungen und der Fähigkeit des Ersatzanbieters ab, den Dienst zu erbringen. Das öffentliche BGP kann keine Änderung zeigen, wenn die Adressen und die Herkunft gleich bleiben, oder eine große Änderung, wenn die Kunden umnummeriert werden.
Keines dieser Ergebnisse erklärt allein, wer die Einzelhandelsverpflichtung übernommen hat.
Bei einem echten Hosting-Dienst wäre die Migration noch schwieriger: Kunden benötigten Datenexport, Maschinenimages, DNS-Kontrolle und Zeit zum Wiederaufbau. Dies ist einer der Gründe, warum die unbelegte Cloud-Annahme nicht leichtfertig behandelt werden darf. Sie bringt Datenverwahrungs- und Ausstiegsverpflichtungen mit sich, die in den Beweisen nicht vorhanden sind.
Für das Zugangsnetz, das tatsächlich sichtbar ist, sind die unmittelbaren Fragen einfacher, aber immer noch unbeantwortet: Wer besitzt die Teilnehmerbeziehung, wer kann die Authentifizierung wiederherstellen, wer eskaliert mit Niss und wie wird ein Kunde umgesiedelt, wenn diese Beziehung endet?
Installierte Kapazität ist nicht kommerzielle Kapazität
Es gibt keine öffentliche Preisliste oder Geschwindigkeitstabelle von Cloudnet, die mit dem Netzwerk verglichen werden könnte. Selbst wenn es eine gäbe, wäre die angekündigte Zugangsgeschwindigkeit immer noch nur die äußere Kante der Kapazitätsfrage. Ein 100-Mbit/s-Teilnehmerplan reserviert nicht 100 Mbit/s durch jeden Aggregations-Switch, jedes Backhaul und jede Transitverbindung zu jeder Stunde. Anbieter teilen die Kapazität in der Annahme, dass nicht alle Kunden gleichzeitig ihre Spitzengeschwindigkeit anfordern.
Die relevanten Betriebsgrößen fehlen. Cloudnet veröffentlicht nicht die Anzahl aktiver Abonnements, die Geschwindigkeitsmischung, den gebuchten Transit, die Peering-Kapazität, das Backhaul-Design, die Portauslastung, den Spitzendurchsatz, die Überbuchungsrate oder das Überlastungsprotokoll. Der IPv4-Pool mit 512 Adressen füllt diese Lücken nicht. Carrier-Grade NAT kann weit mehr als 512 Kundengeräten die gemeinsame Nutzung des Pools ermöglichen; statische Geschäftsdienste können mehrere Adressen pro Konto verbrauchen; und IPv6 ändert die Adressierungsrechnung, ohne selbst ein einziges Bit Transitkapazität hinzuzufügen.
Cloudflare Radar zeigte einegeschätzte Bevölkerung für AS150069in der Größenordnung von einigen Hundert, wobei die angezeigte Schätzung je nach Snapshot und Unterseite variiert. Diese Schätzungen verwenden Verkehrs- und Messsignale anstelle des Abrechnungssystems des Anbieters. Sie deuten auf eine kleine beobachtbare Benutzerpopulation hin und verstärken die Interpretation als Endkunden-ISP, aber sie sollten nicht als Teilnehmerregister zitiert werden. Ein Abonnement kann einen Haushalt oder ein Unternehmen mit vielen Personen bedienen, während einige Benutzer möglicherweise nicht in den zugrunde liegenden Messungen erscheinen.
Die gleiche Vorsicht gilt für gemessene Leistung.Cloudflares Internetqualitätsseite für AS150069aggregiert verfügbare Geschwindigkeitstests und Netzwerkbeobachtungen. Eine Messung von einer antwortenden Adresse kann zeigen, dass ein Pfad zu einer bestimmten Zeit an einem bestimmten Ort funktioniert hat. Sie kann nicht die Planungsgeschwindigkeit für jeden Teilnehmer bescheinigen, die Häufigkeit von Ausfällen über den Zugangsfußabdruck quantifizieren oder offenbaren, ob die getestete Leitung repräsentativ ist. Kleine Stichproben sind besonders anfällig für Änderungen in der Zusammensetzung.
DieTRAI-Qualitätsvorschriften 2024legen Benchmarks und Meldepflichten für Zugangs- und Breitbandanbieter fest, einschließlich Dienstbereitstellung, Netzwerkleistung, Fehlerbehebung und Beschwerdebearbeitung. Dervierteljährliche Leistungsbericht Dezember 2024erklärt, dass seine veröffentlichte Breitbandleistungszusammenfassung Anbieter mit mehr als 10.000 Abonnenten abdeckte. Cloudnet wird in der öffentlichen Zusammenfassung nicht als einer dieser größeren Anbieter identifiziert. Diese Auslassung begründet weder seine Größe noch befreit sie ihn von geltenden Verpflichtungen; sie bedeutet, dass die nationale Zusammenfassung nicht als Beleg für die Cloudnet-spezifische Leistung verwendet werden kann.
Die nutzbare Kapazität ist das, was nach Überlastung, Ausfall und Richtlinie übrig bleibt. Wenn ein Ersatzpfad nur einen Bruchteil des normalen Verkehrs transportiert, kann die nominelle Redundanz dennoch zu schwerer Überlastung führen. Wenn die IPv4-Spezifiken zurückgezogen werden, aber das Aggregat bestehen bleibt, kann die Reichweite mit geändertem Traffic-Engineering fortgesetzt werden. Wenn IPv6 ausfällt, während IPv4 aktiv bleibt, können Benutzer anwendungsspezifische Verzögerungen und Ausfälle erleiden, anstatt eine vollständige Trennung.
Eine glaubwürdige Kapazitätsaussage würde Spitzenmessungen für beide Adressfamilien erfordern, nicht die Größe der zugewiesenen Präfixe.
Ein Cloud-Dienst würde einen anderen Beweisumfang erfordern
Ein Zugangsanbieter und ein Cloud-Anbieter können sich Router, Adressen und Personal teilen, aber sie verkaufen unterschiedliche Versprechen. Der Zugangsdienst transportiert den Datenverkehr eines Kunden zu anderen Systemen. Das Hosting 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 die AS150069-Akte nicht beantworten kann.
Die erste ist der Vermögenswert. Ein glaubwürdiges virtuelles Serverangebot sollte eine Rechenplattform identifizieren oder zumindest CPU-, Speicher-, Netzwerk- und Standortmerkmale offenlegen. Bare-Metal sollte Serverklassen und Bereitstellungsbedingungen identifizieren. Colocation sollte die Einrichtung, die Rack-Leistung und die Remote-Hand-Vereinbarungen identifizieren. Managed Hosting sollte definieren, welche Betriebsaufgaben der Anbieter ausführt. Keine hier gefundene unternehmensspezifische Hardware beschreibt eines dieser Produkte.
Die zweite ist der Standort. „Gehostet in Indien“ oder „gehostet in Chennai“ würde einen Nachweis der Einrichtung erfordern, in der sich Daten und Rechenleistung befinden. Eine in Indien registrierte ASN lokalisiert keinen Server. Der Verkehr kann über ein indisches Netzwerk zu Geräten in einer anderen Einrichtung oder Gerichtsbarkeit geleitet werden; umgekehrt könnte Cloudnet indische Infrastruktur von Dritten nutzen, die nicht in seinem eigenen Adressraum erscheint. Das Registrierungsland und der Datenaufenthaltsort sind unterschiedliche Aussagen.
Die dritte ist die Kontrolle. Wenn Cloudnet die virtuellen Maschinen eines anderen Anbieters weiterverkaufen würde, könnte Cloudnet die Abrechnung und den Support kontrollieren, während der zugrunde liegende Anbieter die Racks, Hypervisoren, Strom und Teile kontrolliert. Wenn Cloudnet Colocation mietet, könnte es Server besitzen, aber nicht die Gebäudesysteme. Wenn es einen eigenen Raum betreibt, könnte es dennoch von Eigentümern und Betreibern abhängig sein. Kunden müssen wissen, wer Strom wiederherstellen, eine Festplatte ersetzen, ein Backup wiederherstellen und den Notzugriff genehmigen kann.
Kein öffentliches Dokument zeichnet diese Grenze nach.
Die vierte ist Redundanz. Ein Cloud-Dienst kann Daten über Festplatten, Hosts, Racks, Räume, Gebäude oder Regionen replizieren, die jeweils vor einem anderen Ausfall schützen. Zwei Kopien auf einem einzelnen Host überleben keinen Host-Ausfall. Zwei Hosts in einem Rack können sich eine Stromverteilungseinheit teilen. Zwei Racks in einem Gebäude können sich die Stromversorgung, Kühlung und Upstream-Faser teilen. Zwei Gebäude können immer noch von einem einzelnen städtischen Kabel oder einer Steuerungsebene abhängen.
Ohne eine offengelegte Architektur und einen getesteten Wiederherstellungspfad sagt das Wort „Cloud“ nichts über die Ausfallzone 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 den Umzug. Die Kündigung des Vertrags, ein Abrechnungsstreit oder ein Unternehmensausfall können ebenso störend sein wie ein Hardwareausfall, wenn die Anmeldeinformationen oder Daten auf einem einzigen Konto gesperrt sind. Es wurden keine Bedingungen von Cloudnet gefunden, die die Datenrückgabe, Löschung, Migrationsunterstützung, Backup-Aufbewahrung oder Kontosperrung beschreiben.
Dies sind keine Behauptungen, dass Cloudnet die Fähigkeiten nicht besitzt. Es sind die Mindestfragen, die die öffentlichen Beweise beantworten sollten, bevor diese Fähigkeiten zugeschrieben werden. Ein privates Angebot, ein Vertrag oder eine technische Spezifikation könnte die Schlussfolgerung für einen bestimmten Kunden ändern. Bis solche Beweise auftauchen, muss AS150069 als Beleg für den Netzwerkbetrieb gelesen werden, nicht als Cloud-Produkt.
RPKI ist nützliche Routing-Hygiene, aber keine Widerstandsfähigkeit an sich
Cloudnet hat eine konkrete Routing-Sicherheitsmaßnahme ergriffen. DieRIPEstat-Validierung für das IPv4-Aggregatfand eine gültige Routenherkunftsautorisierung, die AS150069 abdeckt und Ankündigungen bis zu/24erlaubt. Die Teilrouten sind daher unter derselben Autorisierung gültig. DieValidierung für das/48IPv6war ebenfalls gültig.
RPKI hilft anderen Netzwerken, eine Herkunftsankündigung abzulehnen, die mit der signierten Autorisierung in Konflikt steht. Es reduziert eine Klasse von Routing-Fehlern oder -Entführungen. Es verifiziert nicht jede AS im Pfad, verschlüsselt keinen Verkehr, verhindert keinen Glasfaserbruch, stellt keinen zweiten Upstream bereit, verhindert keine Überlastung und hält einen Router nicht mit Strom versorgt. Eine gültige Route kann zu einem nicht verfügbaren Dienst führen, wenn das Herkunftsnetzwerk keinen funktionierenden Pfad zum Kunden hat.
Die aktuelle Kombination ist dennoch bedeutsam: registrierte Ressourcen, aktive IPv4- und IPv6-Herkünfte, Routenobjekte und gültige Herkunftsautorisierungen. Sie zeigt mehr betriebliche Reife als ein ruhender Firmenname. Sie schärft auch die Frage der Widerstandsfähigkeit, da die sichtbare Topologie eng bleibt. Eine ordnungsgemäß autorisierte Reichweite über einen einzigen beobachteten Nachbarn bleibt ein einziger beobachteter Nachbar.
Die spezifischeren IPv4-Ankündigungen fügen eine weitere betriebliche Komplikation hinzu. Während des Zeitraums, in dem die/24eine geringe Sichtbarkeit hatten, blieb das/23-Aggregat weitgehend sichtbar. Die gleichzeitige Ankündigung des Aggregats und der Spezifiken kann eine Deckungsroute bewahren, wenn eine Spezifik verschwindet. Es kann auch für Richtlinien oder Behebung verwendet werden. Öffentliche Sammler können den beabsichtigten Entwurf nicht preisgeben, und das Aggregat schafft keinen zweiten physischen Pfad. Routing-Redundanz und Schaltungsredundanz sollten nicht verwechselt werden.
IPv6 verdient ebenfalls eine begrenzte Schlussfolgerung. Das/48wird seit Jahren weltweit angekündigt und sein Routenobjekt wurde kürzlich aktualisiert. Dies unterstützt ein aktives IPv6-Routing am Netzwerkrand. Es beweist nicht, dass jeder Einzelhandelskunde ein IPv6-Präfix erhält, dass die Kundengeräte es unterstützen oder dass das Support-Personal beide Protokolle gleichermaßen behandelt. Eine anbieterspezifische Offenlegung oder eine kundenseitige Messung wäre erforderlich, um die Tiefe des Einsatzes zu bestimmen.
Betroffene Personen sind wahrscheinlich Zugangskunden, nicht gehostete Arbeitslasten
Der tägliche Rhythmus von IPinfo, die ISP-Lizenz und das Fehlen eines Hosting-Katalogs deuten auf ein Zugangsnetzwerk hin. Die beobachteten Benutzerschätzungen von Cloudflare und die antwortenden Adressen in der Region Chennai unterstützen diese Richtung. Sie geben keine Namen, genauen Standorte oder Kundentypen preis. Die wahrscheinlich betroffene Bevölkerung ist daher bedingt: Haushalte, kleine Unternehmen oder institutionelle Nutzer, die Konnektivität über AS150069 oder über den Zugangsdienst von Cloudnet erhalten.
Für einen Haushalt unterbricht ein Ausfall E-Mail, Streaming, Remote-Arbeit, Bildung, Zahlungen und vernetzte Geräte. Für ein kleines Unternehmen kann derselbe Ausfall Cloud-Anwendungen, Kartenautorisierung, Lieferantenkontakt und Kundenkommunikation stoppen. Ein Unternehmen, das eine statische Adresse von Cloudnet verwendet, kann auch die eingehende Erreichbarkeit einer Kamera, eines VPN-Endpunkts oder eines selbst gehosteten Dienstes verlieren. Dies sind Mechanismen, keine Behauptungen, dass eine benannte Organisation den Dienst von Cloudnet kauft.
Die Abhängigkeit erstreckt sich über den Kontoinhaber hinaus. Ein lokaler Betreiber oder Wiederverkäufer kann Kunden hinter den gerouteten Raum von Cloudnet stellen. Es war keine nachgelagerte ASN sichtbar, aber nachgelagerte Einzelhandelsvereinbarungen erfordern keine separate ASN. Wenn Cloudnet Kapazität für ein anderes Zugangsunternehmen bereitstellt, könnte ein Ausfall an der Cloudnet-Niss-Grenze Benutzer betreffen, die keinen der beiden Firmennamen erkennen. Das öffentliche Routing kann diese Vereinbarungen nicht zählen.
Verschiedene Ausfälle erzeugen unterschiedliche Symptome. Ein durchtrennter Abzweig betrifft einen einzelnen Standort. Ein Koppler- oder Zugangsportausfall betrifft eine Gruppe. Ein Aggregations- oder Backhaul-Ausfall betrifft eine größere Zone. Der Verlust der Niss-Verbindung kann den gesamten gerouteten Fußabdruck betreffen. Ein DNS- oder Authentifizierungsausfall kann die Verbindungen aktiv lassen, während Sitzungen fehlschlagen. Abrechnungs- oder Kontosystemfehler können eine Person trennen, ohne dass ein Netzwerkausfall vorliegt. Die öffentliche Akte identifiziert nicht, welche Systeme Cloudnet selbst betreibt.
Die Wiederherstellung muss vom Kundenrand aus gemessen werden. Die Wiederherstellung einer BGP-Ankündigung reicht nicht aus, wenn die Zuführungsfaser weiterhin unterbrochen ist. Die Reparatur der Faser reicht nicht aus, wenn die Authentifizierung ausgefallen ist. Die Stromversorgung eines Switches reicht nicht aus, wenn die Upstream-Sitzung immer noch nicht verfügbar ist. Eine solide Vorfallberichterstattung würde die ausgefallene Schicht, den verantwortlichen Betreiber, die Start- und Wiederherstellungszeiten, das betroffene Gebiet, die Problemumgehung und ob die Kapazität vollständig wiederhergestellt wurde, identifizieren.
Das Fehlen einer öffentlichen Vorfallseite oder einer Dienststatus-Historie verhindert ein Leistungsurteil. Schweigen beweist keine perfekte Zuverlässigkeit, und verstreute Benutzerberichte würden ohne Überprüfung keine netzwerkweite Rate begründen. Die aktuellen Beweise unterstützen die Kartierung der Ausfallkette, nicht die Bewertung der historischen Verfügbarkeit von Cloudnet.
Was ein solideres Betriebsbild schaffen würde
Das erste fehlende Element ist eine aktuelle, kundenorientierte Dienstbeschreibung. Für den Zugangsdienst sollte sie die Abdeckung, Zugangstechnologie, Tarifgeschwindigkeiten, Überbuchung oder Fair-Use-Regeln, Installationsbedingungen, Störungskontakt und Serviceziele nennen. Für einen Hosting-Dienst sollte sie Rechen-, Speicher-, Netzwerk-, Backup- und Migrationsmerkmale spezifizieren. Ein Logo und ein generisches Versprechen schnellen Dienstes würden nicht ausreichen.
Das zweite ist eine physische und vertragliche Netzwerkkarte auf einem angemessenen Abstraktionsniveau. Cloudnet muss keine sensiblen Routen auf Straßenebene veröffentlichen. Es könnte die Anzahl der aktiven Präsenzpunkte, die Städte oder Dienstbereiche, die sie abdecken, ob das Backhaul besessen oder gemietet ist und ob die Upstream-Schaltungen an getrennten Standorten enden und diversen Pfaden folgen, offenlegen. Der Schlüssel ist, gemeinsame Ausfallzonen zu identifizieren, ohne Betriebsgeheimnisse preiszugeben.
Das dritte ist der Kapazitätsnachweis. Nützliche Messungen umfassen den Gesamt- und Spitzenverkehr, die Portauslastung, den gebuchten und Burst-Transit, die Failover-Kapazität, die Auslastung der Zugangsknoten und die IPv4/IPv6-Kundenakzeptanz. Ein Snapshot sollte ein Datum tragen. Die Entwurfskapazität, die installierten Schnittstellen, die aktivierte Kapazität und der für den Kunden verfügbare Durchsatz sollten getrennt gemeldet werden.
Das vierte ist der Wiederherstellungsnachweis. Cloudnet könnte die Autonomie der Notstromversorgung nach Standortklasse, die Ersatzteilpolitik, das Eskalationseigentum, die Wartungsfenster und die aktuellen Wiederherstellungsleistungen angeben. Eine Widerstandsbehauptung wird glaubwürdig, wenn ein Ausfall getestet wurde: Routenrückzug, Upstream-Verlust, Stromausfall, Hardware-Austausch und Konfigurationswiederherstellung. Das Ergebnis sollte zeigen, ob der Dienst tatsächlich umgeschaltet hat und wie viel Kapazität übrig blieb.
Das fünfte ist eine unabhängige topologische Bestätigung. Ein zweiter sichtbarer Nachbar würde den Fall für Routing-Diversität stärken, würde aber immer noch einen physischen Pfadnachweis erfordern. Eine Ersatzschaltung zur selben AS kann wertvoll sein, wenn sie in einer anderen Einrichtung endet und gemeinsame Leitungswege vermeidet. Umgekehrt können zwei Anbieternamen denselben Letzte-Meile-Betreiber teilen. Verträge, Anschlusspunkte und Routenuntersuchungen klären, was BGP allein nicht kann.
Das sechste ist der Nachweis einer Cloud-Behauptung. Ein unabhängig überprüfbarer Einrichtungsname oder eine Website, Kundenbedingungen, Infrastrukturspezifikationen, eine Datenstandorterklärung, eine Backup-Architektur, eine Sicherheitsverantwortungsmatrix und ein Ausstiegsverfahren würden die Diskussion von der Schlussfolgerung zur Produktanalyse verschieben. Eine einzelne gehostete Domain oder ein Server, der vom/23antwortet, würde keine kommerzielle Cloud-Plattform beweisen.
Bis diese Elemente existieren, bleiben die stärksten Beweise von Cloudnet seine regulierte ISP-Identität und sein aktives Routing. Die Unbekannten sind keine dekorativen Lücken. Sie sind genau die Stellen, an denen der Dienst ausfallen kann: Zugangsleitung, Aggregationsstromversorgung, Backhaul, Niss-Anschluss, nachgelagerter Transit, Support-Eskalation und Kundenwiederherstellung.
Ein kleines aktives Netzwerk, mit einer engeren Geschichte als sein Name
CLOUDNET INTERNET SERVICE PVT LTD ist keine leere Unternehmenshülle. Sie hat eine Internetdienstlizenz der Kategorie B für Tamil Nadu, eine konsistente Identität in Chennai in öffentlichen Registern, ein aktives autonomes System, eine IPv4-Zuteilung von 512 Adressen, ein angekündigtes/48IPv6 und gültige Routenherkunftsautorisierungen. Ihre Routen sind seit 2022 sichtbar, und ihre Registerdaten wurden kurz vor dem Beobachtungsdatum gepflegt.
Dieselben Beweise setzen eine harte Grenze. Ein einziger unmittelbarer Routing-Nachbar war sichtbar. Kein öffentliches Material hat eine Upstream- oder physische Diversität, einen kartierten Zugangsfußabdruck, eine installierte Bandbreite, eine Notstromautonomie, eine Feldreparaturleistung oder einen besetzten Support-Betrieb nachgewiesen. Am wichtigsten ist, dass nichts einen kommerziellen Cloud-, VPS-, Bare-Metal-, Colocation-, Speicher- oder Managed-Hosting-Dienst lokalisiert hat.
Dies ist kein enttäuschendes Ergebnis. Es ist ein nützlicheres Ergebnis. Der Name verschleiert nicht länger die Betriebsoberfläche, die tatsächlich beobachtet werden kann. Cloudnet scheint Zugangsverkehr in Tamil Nadu über AS150069 und Niss Internet Services zu transportieren. Seine Widerstandsfähigkeit wird durch gewöhnliche Infrastruktur bestimmt: Kabel, stromversorgte Elektronik, Backhaul, Routenkonfiguration, Ersatzteile und Personen, die sie wiederherstellen können.
Der Beweisgrad Netz ist Niedrig für eine vollständige Infrastrukturbewertung, trotz solider Beweise, dass die ASN aktiv ist. Das Routing ist sichtbar; das physische und kommerzielle System dahinter ist es nicht. Ein stärkerer Grad erfordert den Nachweis, wo Kunden verbinden, wie der Verkehr abfließt, was umschaltet, wie sich die Kapazität unter Last verhält und wer jede Schicht repariert. Jede zukünftige Cloud-Dienstbehauptung muss einen Schritt früher beginnen, indem sie beweist, dass es einen zu bewertenden Hosting-Dienst gibt.