Resumen
- El Departamento de Telecomunicaciones de la India incluyó a Cloudnet Internet Service Private Limited como titular de una autorización de servicios de Internet de Categoría B para Tamil Nadu, con efecto el 10 de abril de 2023. Las páginas de datos corporativos conectan la misma dirección y detalles de contacto con una empresa de Chennai constituida en 2021. Esto establece una identidad de ISP regulado, no una cartera de productos de computación en la nube.
- AS150069 estaba activo el 10 de julio de 2026, originando
103.21.6.0/23, ambas rutas componentes/24y2001:df1:66c0::/48. El agregado IPv4 había sido visible desde octubre de 2022 y la ruta IPv6 desde noviembre de 2022. La autorización de ruta actual era válida bajo RPKI, y los registros del registro se habían mantenido recientemente. - Los recolectores de rutas públicas mostraron solo un vecino inmediato para AS150069: AS132774 de Niss Internet Services Private Limited. Eso es evidencia de una ruta de enrutamiento externa visible, no prueba de que Cloudnet no tenga interconexión privada o circuito de respaldo. Tampoco es evidencia de diversidad de rutas físicas, conmutación por error automática o capacidad sobrante.
- IPinfo caracteriza AS150069 como un ISP de consumo con un ritmo de tráfico día-noche pronunciado y reporta solo un dominio alojado en el espacio de direcciones. Esas son señales útiles, no cifras auditadas de clientes o productos. No se encontró ningún catálogo público de servicios de Cloudnet, ubicación de centro de datos, inventario de racks, oferta de máquinas virtuales, oferta de bare metal, servicio de almacenamiento, compromiso de tiempo de actividad, política de respaldo o procedimiento de migración.
- La degradación responsable es, por lo tanto, de un presunto operador de servicios en la nube a un pequeño ISP de Tamil Nadu actualmente enrutado, cuya huella minorista exacta y red física permanecen sin revelar. Su resiliencia depende de la planta de acceso local, el equipo de agregación con energía, la entrega a Niss, la conectividad posterior de Niss y la mano de obra de soporte. Se requeriría evidencia de cargas de trabajo alojadas reales antes de hablar de Cloudnet como proveedor de nube.
La hipótesis de la nube falla en la primera pregunta sobre el producto
La palabra "Cloudnet" puede hacer demasiado trabajo si se lo permitimos. Combina dos piezas de moda del vocabulario de redes, y la empresa controla recursos de numeración de Internet. Ninguno de esos hechos muestra que un cliente pueda comprar una máquina virtual, una base de datos gestionada, un bucket de almacenamiento, un servidor bare metal o incluso una cuenta de alojamiento web convencional. La distinción importa porque un servicio en la nube tiene obligaciones de fallo y recuperación que un proveedor de acceso puede no haber asumido nunca.
El documento público más sólido específico de la empresa no es un catálogo de nube. Es lalista del Departamento de Telecomunicaciones de autorizaciones de servicios de Internet a 31 de enero de 2025. La entrada identifica a Cloudnet Internet Service Private Limited, número de licenciaDS-11/401/2022-DS-III, Categoría B, área de servicio Tamil Nadu, con fecha de vigencia el 10 de abril de 2023. El contacto autorizado, la dirección de la oficina registrada y el número de teléfono coinciden con los registros corporativos y de registros de Internet de la empresa.
Lapágina de servicios de Internet del Departamentoexplica lo que significa la Categoría B. Es la autoridad para proporcionar servicio de Internet en un área de servicio licenciada, definida como un círculo de telecomunicaciones o área metropolitana. ElCompendio de Licencia Unificadadescribe el acceso a Internet, IPTV y formas especificadas de telefonía por Internet dentro del alcance de la autorización. La licencia es evidencia material de que Cloudnet puede operar como ISP en Tamil Nadu. No certifica que la empresa haya construido cobertura en todo el estado, y no convierte una autorización de acceso en evidencia de computación alojada.
El registro de red apunta en la misma dirección. Lavisión general de AS150069 de IPinfoclasifica la red como un ISP de consumo y encuentra un ritmo de actividad diaria pronunciado del tipo asociado con personas que usan una conexión durante las horas de vigilia. Reporta un dominio alojado, en comparación con 512 direcciones IPv4. Los recuentos de dominios alojados tienen límites de medición: un dominio puede estar detrás de una red de entrega de contenido, una dirección puede alojar muchos nombres, un servicio privado puede no ser detectable y los clientes de acceso pueden ejecutar servidores. Incluso con esas salvedades, un dominio observado no es evidencia afirmativa de una finca de alojamiento.
La huella pública de Cloudnet no da precios ni especificaciones para computación, almacenamiento, copia de seguridad, colocación o infraestructura gestionada. No se nombra ninguna dirección de centro de datos. No se describe ningún proveedor de servidores, número de racks, diseño de energía, certificación, zona de disponibilidad, portal de clientes, acuerdo de nivel de servicio, anexo de procesamiento de datos, historial de incidentes, objetivo de restauración o formato de exportación. Una empresa puede vender en privado sin documentar cada servicio en la web abierta, pero la carga de la prueba no se invierte. En ausencia de un producto y una superficie operativa, la afirmación de nube debe ser descartada en lugar de embellecida.
Eso deja una historia diferente y más fundamentada. Cloudnet tiene un sistema autónomo activo, una autorización de ISP de Tamil Nadu, una pequeña asignación IPv4, una asignación IPv6 y una dependencia ascendente visible. Estos son los huesos de una red de acceso. La planta física detrás de ellos está en gran parte sin exponer, lo que dificulta evaluar la resiliencia pero no hace que la red sea imaginaria.
Una empresa de Chennai y una autorización de Tamil Nadu
Los agregadores corporativos identifican a Cloudnet Internet Service Private Limited por el Número de Identificación CorporativaU64120TN2021PTC142654.La página de la empresa en Toflerfecha la constitución el 8 de abril de 2021, indica un capital social autorizado de 1 millón de rupias y un capital desembolsado de 100.000 rupias, y nombra a Logasundari y Gopikrishnan como directores.El registro de ZaubaCorpproporciona el mismo CIN, registro en Chennai y dirección de Kottivakkam, aunque algunos campos de fecha en sus resúmenes renderizados son inconsistentes y no deben tratarse como sustituto de una presentación actual.
La dirección es inusualmente útil para la resolución de identidad. La lista de licencias sitúa a la empresa en el tercer piso de la parcela 11/236A, Vivekanandar Third Street, Kottivakkam, Chennai.El registro AS150069 de APNICutiliza el nombre legal abreviado, CLOUDNET INTERNET SERVICE PVT LTD, y su rol administrativo repite la misma dirección y número de teléfono. Elregistro de la asignación IPv4y elregistro de la asignación IPv6llevan el mismo nombre de red,CNISPL, y la misma cadena de contacto. No son simplemente negocios similares que comparten un nombre genérico; los registros convergen en una sola empresa.
Esa convergencia también mantiene fuera del cuadro a varios homónimos. Una Cloudnet Broadband Services Private Limited separada aparece en material de licencias anterior de Haryana, y Cloudnet Communications Private Limited aparece en tablas de suscriptores. Otros negocios en otros lugares usan Cloud Net o Cloudnet como nombre comercial. No deben usarse para llenar vacíos en el catálogo de servicios, el número de clientes o el historial de esta empresa. El ancla de identidad aquí es la licencia de Tamil Nadu, el CIN, la dirección de Kottivakkam y AS150069.
La lista del DoT de 2025 es evidencia de una autorización en esa fecha de informe. No es un certificado operativo diario para julio de 2026. Por otro lado, las rutas activas y los objetos del registro de Internet mantenidos recientemente proporcionan evidencia técnica mucho más fresca. Por lo tanto, la empresa no debe describirse como meramente registrada o con licencia histórica. Su sistema autónomo estaba llevando un anuncio globalmente visible en el momento de la observación.
La dirección aún no responde dónde se encuentra el equipo de red. Una oficina registrada puede ser una oficina administrativa, un punto de presencia, ambos o ninguno. El registro IPv4 incluye las coordenadas13.427804, 80.14154212, pero la geolocalización del registro son metadatos proporcionados por el operador, no un estudio de una sala de routers. IPinfo coloca varias direcciones observadas o routers en y alrededor de Chennai y Nagari, mientras que sus sondas recientes alcanzaron direcciones que respondían desde puntos de observación en el área de Chennai. Tal geolocalización es probabilística. No puede identificar un terminal de línea óptica, probar la propiedad de una ruta de fibra o establecer que un cliente es servido en una calle en particular.
La declaración geográfica defendible es, en consecuencia, estrecha. Cloudnet está autorizado para el área de servicio de Tamil Nadu, registrado en Chennai y opera espacio de direcciones que las mediciones independientes asocian con India y la región de Chennai. La evidencia pública no mapea su huella minorista dentro de Tamil Nadu, no muestra que sirva a todo Chennai ni revela un punto de presencia más allá de la dirección registrada.
AS150069 proporciona evidencia operativa actual
Un sistema autónomo es una unidad de política de enrutamiento, no un negocio completo. Aún así, AS150069 es la evidencia más clara de que Cloudnet opera algo ahora.La visión general de AS de RIPEstatinformó que el ASN estaba anunciado el 10 de julio de 2026. Surespuesta de prefijos anunciadosenumeró el agregado IPv4103.21.6.0/23, las dos rutas más específicas103.21.6.0/24y103.21.7.0/24, y el prefijo IPv62001:df1:66c0::/48.
El agregado IPv4 contiene 512 direcciones.El estado de enrutamiento actualmostró a AS150069 como el único origen visible para el/23, visto por 326 de 327 pares IPv4 informantes. También mostró ambos/24bajo el agregado. Respuestas de estado separadas para103.21.6.0/24y103.21.7.0/24registraron el mismo origen y visibilidad. Esto no fue un rastro visible solo para un observador.
La cronología es sustancial.El historial de enrutamiento para el/23comienza el anuncio del agregado de Cloudnet en octubre de 2022 y lo continúa hasta la fecha de investigación. Los dos/24aparecieron por primera vez en diciembre de 2022. Su visibilidad cayó bruscamente durante un período a partir de marzo de 2025 mientras que el/23de cobertura permaneció ampliamente visible, luego regresó a una visibilidad amplia en mayo de 2026. Eso es un cambio en la granularidad y propagación de rutas, no evidencia de que el servicio al cliente se detuviera. El tráfico dirigido a los dos bloques aún podía seguir el agregado de cobertura cuando una ruta más específica no era visible.
IPv6 no es solo una reserva de registro.El estado de enrutamiento para2001:df1:66c0::/48mostró a AS150069 originando el prefijo a los 321 pares IPv6 informantes el 10 de julio. La ruta se vio por primera vez en noviembre de 2022. El objeto de ruta de APNIC fue modificado el 8 de julio de 2026, dos días antes de la observación, y el registro de contacto asociado también se había actualizado en junio. Esas fechas muestran una administración continua de recursos. No nos dicen cuánto tráfico de clientes usa IPv6 o cuántos usuarios lo reciben.
La distinción entre capacidad instalada y utilizable es esencial. Un/23es un conjunto de direcciones, no una compra de ancho de banda. Quinientas doce direcciones IPv4 no significan 512 clientes, servidores, puertos o megabits. Un proveedor puede usar direcciones para interfaces de enrutador, pools de NAT de calidad de operador, circuitos empresariales, infraestructura o inventario de repuesto. Un hogar puede usar múltiples direcciones públicas; muchos hogares pueden compartir una dirección. El recuento casi incomprensiblemente mayor de direcciones numéricas dentro de un/48IPv6 es aún menos útil como medida de capacidad.
Tampoco tres anuncios IPv4 simultáneos triplican la red. El/23y sus dos/24componentes cubren el mismo espacio de direcciones. Los anuncios más específicos pueden apoyar la política de enrutamiento, la ingeniería de tráfico o la transición operativa, pero los datos de enrutamiento visibles no revelan qué propósito se aplica. Contar el agregado y los componentes como 1.024 direcciones IPv4 únicas contaría dos veces las mismas 512 direcciones.
Las rutas actuales respaldan una red real y activa. No muestran la tecnología de acceso del suscriptor, el número de puertos, el tránsito agregado, la utilización pico, la contención, el backhaul, la capacidad de caché o la velocidad del servicio. Esas cantidades determinan si una conexión vendida es utilizable en el pico de la tarde. Ninguna puede calcularse a partir del ASN.
Un vecino inmediato es el límite externo visible
La vista de vecinos AS de RIPEstatencontró un vecino inmediato el 10 de julio de 2026: AS132774. APNIC identifica ese ASN comoNiss Internet Services Private Limited, una red de Tamil Nadu registrada en Tirunelveli.La vista de AS150069 en CIDR Reportmuestra de forma independiente la misma adyacencia y ningún ASN descendente.
Los recolectores de rutas ven topología, no contratos. Un AS que precede directamente a Cloudnet en las rutas observadas es consistente con que Niss suministre tránsito, enrutamiento gestionado u otra forma de alcance ascendente. No revela el precio, el ancho de banda comprometido, los términos de ráfaga, la entrega física, el proveedor de fibra, el período de preaviso, la obligación de restauración o si Cloudnet compra el servicio directamente. La etiqueta comercial "ascendente" es una inferencia sensata aquí, pero el resultado público es estrictamente un vecino BGP externo visible.
La distinción se vuelve importante al discutir la redundancia. Un vecino visible es evidencia en contra de afirmar una diversidad ascendente demostrada públicamente. No es prueba de que Cloudnet tenga solo un cable. Cloudnet podría tener dos circuitos físicamente separados hacia diferentes routers de Niss mientras presenta la misma ruta ASN. Podría tener una sesión de respaldo que estaba inactiva en el momento de la observación. Podría recibir una ruta por defecto a través de una conexión no visible para los recolectores. Por el contrario, varias sesiones BGP hacia un proveedor podrían converger en un solo conducto, edificio, router o dominio de energía. El recuento de sesiones y la diversidad física son cosas diferentes.
Niss mismo tiene una topología más amplia. Suentrada en PeeringDBenumera peering en NIXI Chennai e instalaciones en Chennai y Tirunelveli, mientras quebgp.toolsenumera varios ascendentes para AS132774. Estos son hechos autoinformados y observados sobre Niss, no propiedades heredadas de Cloudnet. Un paquete de Cloudnet puede beneficiarse de las opciones posteriores de Niss después de alcanzar AS132774, pero que Niss tenga múltiples ascendentes no prueba que Cloudnet tenga dos formas independientes de llegar a Niss.
La vista en tiempo real delespejo de RIPEstat del/23colocó repetidamente a AS132774 inmediatamente antes de AS150069 en las rutas recolectadas. Muchas rutas luego pasaron a través de AS9498 de Bharti Airtel más allá de Niss. Eso indica la cadena visible en ese momento: Cloudnet, Niss y luego redes de tránsito más grandes. No significa que Cloudnet tenga un contrato directo con Airtel, y no establece dónde ocurre la entrega física.
Este límite crea un mecanismo de falla claro. Si la única entrega activa de Cloudnet a Niss falla, o si una sesión de enrutamiento se retira sin una alternativa funcional, todas las direcciones de Cloudnet enrutadas globalmente pueden volverse inalcanzables incluso mientras la fibra del cliente y los conmutadores locales permanecen encendidos. Si la conexión con Niss se mantiene pero su capacidad comprometida se agota, los usuarios pueden ver congestión en lugar de una interrupción limpia. Si un filtro de ruta o autorización es incorrecto, una familia de direcciones o una longitud de prefijo puede fallar mientras otras continúan.
La recuperación depende de hechos que no son públicos: si Cloudnet tiene un segundo circuito; si termina en un dispositivo de borde diferente; si ese circuito sigue una ruta separada; si la conmutación por error es automática; si la copia de seguridad tiene suficiente capacidad para el pico normal; si se transportan tanto IPv4 como IPv6; y qué empresa posee la primera respuesta. Un diagrama con dos líneas no probaría nada de esto a menos que identificara los puntos comunes físicos y contractuales.
La red física comienza donde BGP deja de explicar
BGP puede mostrar que AS150069 hace alcanzable un bloque de direcciones. No puede mostrar el cable desde las instalaciones de un cliente hasta el primer dispositivo activo. Entre esos puntos puede haber un terminal de red óptica, fibra de acometida, divisor, fibra de distribución aérea o subterránea, un terminal de línea óptica, agregación Ethernet, backhaul arrendado, paneles de parcheo, fuentes de alimentación y refrigeración. La evidencia pública no identifica cuáles de estos usa o posee Cloudnet.
La autoridad de Categoría B de la empresa permite el servicio en todo el área de servicio licenciada de Tamil Nadu; no certifica un diseño de acceso particular. Cloudnet podría operar fibra hasta el hogar, Ethernet empresarial, enlaces inalámbricos, servicio a través de socios de cable locales o una mezcla. No se encontró ningún mapa de cobertura público, hoja de plan, especificación de red óptica, registro de torres o asociación de cable local. La presencia de dos direcciones IP que respondieron enel escaneo reciente de IPinfomuestra que los puntos finales respondieron a las mediciones, no cómo se construyó la última milla.
Este límite de propiedad desconocido cambia quién repara una interrupción. Una acometida de cliente cortada puede ser responsabilidad de Cloudnet o de un operador local. Una falla en la fibra de alimentación puede requerir una cuadrilla de postes, un contratista civil o el propietario de la fibra arrendada. Una falla de agregación puede necesitar ópticas de repuesto, un conmutador, una tarjeta OLT o una fuente de alimentación. Una falla de backhaul puede recaer en otro operador. El cliente ve un servicio no disponible, mientras que la reparación cruza varias organizaciones.
La energía crea su propia cadena. El equipo del cliente necesita electricidad. Los armarios de calle, los sitios inalámbricos, los terminales de línea óptica, los conmutadores de agregación y los enrutadores de borde necesitan electricidad. Que una oficina registrada tenga energía no dice nada sobre un nodo de distribución remoto. Un SAI (UPS) puede salvar una interrupción corta pero tiene una autonomía finita y baterías que envejecen. Un generador ayuda solo si está instalado, alimentado, mantenido y conectado al sitio afectado. Ninguna declaración pública de Cloudnet proporciona autonomía de respaldo, cobertura de generadores, mantenimiento de baterías, alimentación dual o arquitectura de energía del sitio.
El inventario de hardware importa para una red pequeña porque la pieza fallada puede ser barata pero operativamente específica. Un módulo óptico de repuesto puede restaurar un enlace rápidamente si es compatible y está disponible. Una tarjeta de línea, fuente de alimentación o chasis de acceso fallados pueden tardar más si deben pedirse. Las copias de seguridad de configuración deben ser actuales y utilizables en equipos de reemplazo. El registro público no contiene datos de tiempo medio de reparación, política de existencias, lista de proveedores o ventana de mantenimiento.
La mano de obra de soporte es, por lo tanto, parte de la capacidad. Una red puede tener ancho de banda no utilizado y aún así permanecer indisponible porque ningún técnico puede llegar a un corte, ningún ingeniero puede cambiar una ruta o ningún contacto autorizado puede escalar con un ascendente. Los registros de Cloudnet en registros y licencias publican una sola cadena de contacto administrativo, pero esos registros no describen un centro de operaciones de red con personal, cobertura de campo 24 horas, sistema de tickets o lista de escalado. Sería incorrecto convertir un número de contacto en una promesa de nivel de servicio.
La cuestión de la ubicación física debe permanecer abierta. Kottivakkam es una ubicación de oficina registrada. Las coordenadas del registro sugieren otro punto en el norte de Tamil Nadu, y las mediciones de terceros asocian direcciones con Chennai, Nagari y otras etiquetas de Tamil Nadu. Las bases de datos de geolocalización IP pueden reflejar el registro de direcciones, ubicaciones inferidas de usuarios o sesgos de medición. Nada prueba que Cloudnet tenga un rack en un centro de datos nombrado o posea equipos en algún sitio en particular.
La facturación, el soporte y los contratos pueden interrumpir una red intacta
No toda falla de servicio comienza con un cable cortado. Un proveedor de acceso tiene que identificar clientes, autorizar sesiones, emitir facturas, aceptar pagos, aplicar cambios de plan y distinguir una cuenta morosa de una falla de red. Dependiendo del diseño, la autenticación puede depender de una base de datos de suscriptores, un servidor RADIUS, una puerta de enlace de red de banda ancha, un sistema de gestión de red óptica o la plataforma de un revendedor. El registro público no revela cuáles de estos usa Cloudnet. Sí establece que la administración de clientes es una capa operativa separada de BGP.
Esa distinción es fácil de ver desde fuera. AS150069 puede permanecer globalmente visible mientras una cuenta no puede conectarse. Un pago publicado en el libro mayor equivocado, una credencial caducada, un servidor de autenticación fallido o una bandera de suspensión incorrecta pueden presentarse como una interrupción en el enrutador del cliente. El personal de campo puede encontrar niveles de luz saludables y una ruta ascendente intacta, pero el servicio permanece indisponible hasta que se corrija el control de cuenta. Un recolector de rutas no registrará nada de eso.
La continuidad de la facturación también importa durante un incidente más amplio. Los clientes necesitan un canal accesible para informar fallas y determinar si un pago, dispositivo o interrupción de área es responsable. El personal necesita registros de cuentas y red actualizados. Si la misma falla de energía, servidor o conectividad deja fuera tanto el servicio de acceso como sus sistemas de soporte, el diagnóstico se ralentiza. Los contactos regulatorios y de registro publicados de Cloudnet no revelan si tiene una plataforma de atención al cliente separada, registros fuera de sitio, enrutamiento telefónico de emergencia o un proceso manual probado.
El contrato mayorista con el vecino visible es otro posible punto de control. Una fibra y un enrutador pueden estar técnicamente sanos mientras que una disputa de proveedor, pedido vencido, factura impaga, límite de capacidad o autorización de ruta caducada interrumpe el servicio. No hay evidencia de que tal disputa haya ocurrido entre Cloudnet y Niss. El punto es estructural: donde el alcance depende de otro operador, la continuidad comercial pertenece a la evaluación de resiliencia junto con la óptica y la energía.
La falla del contrato con el proveedor se vuelve más consecuente cuando no hay una alternativa probada. Cambiar de ascendente requiere más que pedir una línea. El nuevo proveedor debe alcanzar un punto de entrega, aceptar las rutas de Cloudnet, aplicar filtros, transportar IPv4 e IPv6, admitir autorizaciones de ruta válidas y proporcionar suficiente capacidad. El tráfico del cliente puede necesitar nuevos valores predeterminados, rutas DNS o política de direcciones. Si la migración se apresura después de que termina un servicio existente, la red puede estar fuera de línea aunque Cloudnet todavía controle su ASN y prefijos.
Mover clientes de acceso individuales plantea un problema de migración diferente. Si Cloudnet dejara de servir un área o entregara suscriptores a otro operador, la continuidad dependería de la propiedad de la fibra de acometida y el equipo del cliente, la portabilidad de los registros de cuenta, los períodos de preaviso, los reembolsos y la capacidad del proveedor de reemplazo para aprovisionar el servicio. El BGP público puede no mostrar cambios si las direcciones y el origen siguen siendo los mismos, o un gran cambio si los clientes son renumerados. Ningún resultado por sí solo explica quién asumió la obligación minorista.
Para un servicio alojado genuino, la migración sería aún más difícil: los clientes necesitarían exportación de datos, imágenes de máquina, control DNS y tiempo para reconstruir. Esa es una razón por la que la hipótesis de nube no respaldada no puede tratarse casualmente. Implica obligaciones de custodia y salida de datos que están ausentes en la evidencia. Para la red de acceso que es realmente visible, las preguntas inmediatas son más simples pero aún sin respuesta: quién posee la relación con el suscriptor, quién puede restaurar la autenticación, quién escala con Niss y cómo se mueve un cliente si esa relación termina.
La capacidad instalada no es capacidad minorista
No hay una lista de precios o tabla de velocidad pública de Cloudnet para comparar con la red. Incluso si existiera, la velocidad de acceso anunciada seguiría siendo solo el borde exterior de la cuestión de capacidad. Un plan de suscripción de 100 Mbps no reserva 100 Mbps a través de cada conmutador de agregación, backhaul y enlace de tránsito a todas horas. Los proveedores agrupan capacidad asumiendo que los clientes no exigirán todos su tasa máxima simultáneamente.
Las cantidades operativas relevantes están ausentes. Cloudnet no publica el número de suscripciones activas, la mezcla de velocidades, el tránsito comprometido, la capacidad de peering, el diseño de backhaul, la utilización de puertos, el rendimiento en hora punta, la relación de sobresuscripción o el historial de congestión. El pool de 512 direcciones IPv4 no llena esos vacíos. La NAT de calidad de operador puede permitir que mucho más de 512 dispositivos de clientes compartan el pool; los servicios empresariales estáticos pueden consumir varias direcciones por cuenta; e IPv6 cambia el cálculo de direccionamiento sin agregar un bit de capacidad de tránsito por sí mismo.
Cloudflare Radar ha mostrado unapoblación estimada para AS150069en los cientos, con la estimación mostrada cambiando entre instantáneas y subpáginas. Tales estimaciones utilizan señales de tráfico y medición en lugar del sistema de facturación del proveedor. Indican una pequeña población de usuarios observable y refuerzan la interpretación de ISP de consumo, pero no deben citarse como un libro mayor de suscriptores. Una suscripción puede servir a un hogar o negocio con muchas personas, mientras que algunos usuarios pueden no aparecer en las mediciones subyacentes.
La misma precaución se aplica al rendimiento medido.La página de calidad de Internet de Cloudflare para AS150069agrega pruebas de velocidad disponibles y observaciones de red. Una medición tomada desde una dirección que responde puede mostrar que una ruta funcionó en un momento y lugar. No puede certificar una velocidad de plan para cada suscriptor, cuantificar la frecuencia de interrupciones en toda la huella de acceso o revelar si la línea probada es representativa. Las muestras pequeñas son particularmente vulnerables a cambios de composición.
Lasregulaciones de calidad de banda ancha de 2024 de TRAIestablecen puntos de referencia y deberes de informes para proveedores de acceso y banda ancha, incluyendo aprovisionamiento de servicios, rendimiento de red, reparación de fallas y manejo de quejas. Elinforme de rendimiento trimestral de diciembre de 2024explica que su resumen de rendimiento de banda ancha publicado cubrió proveedores con más de 10,000 suscriptores. Cloudnet no se identifica en el resumen público como uno de esos grandes proveedores. Esa omisión no establece su tamaño ni lo exime de obligaciones aplicables; significa que el resumen nacional no puede usarse como evidencia de rendimiento específica de Cloudnet.
La capacidad utilizable es lo que queda después de la contención, la falla y la política. Si una ruta de respaldo transporta solo una fracción del tráfico normal, la redundancia nominal aún puede producir congestión severa. Si los específicos IPv4 se retiran pero el agregado permanece, la alcanzabilidad puede continuar con ingeniería de tráfico cambiada. Si IPv6 falla mientras IPv4 permanece activo, los usuarios pueden experimentar retrasos y fallos específicos de la aplicación en lugar de una desconexión total. Una declaración de capacidad creíble necesitaría mediciones en hora punta para ambas familias de direcciones, no el tamaño de los prefijos asignados.
Un servicio en la nube requeriría un conjunto de evidencia diferente
Un proveedor de acceso y un proveedor de nube pueden compartir enrutadores, direcciones y personal, pero venden promesas diferentes. El servicio de acceso transporta el tráfico de un cliente a otros sistemas. La computación alojada mantiene la aplicación, los datos o el servidor de un cliente funcionando en la infraestructura propia o arrendada del proveedor. La segunda promesa introduce preguntas que el registro AS150069 no puede responder.
La primera es el activo. Una oferta creíble de servidor virtual debe identificar una plataforma de computación o al menos revelar CPU, memoria, almacenamiento, red y características de tenencia. El bare metal debe identificar clases de servidor y términos de aprovisionamiento. La colocación debe identificar instalación, potencia de rack y arreglos de manos remotas. El alojamiento gestionado debe definir qué tareas operativas realiza el proveedor. Ningún material específico de la empresa encontrado aquí describe alguno de esos productos.
La segunda es la ubicación. "Alojado en India" o "alojado en Chennai" necesitaría evidencia de la instalación donde residen los datos y la computación. Un ASN registrado en India no localiza un servidor. El tráfico puede enrutarse a través de una red india hacia equipos en otra instalación o jurisdicción; a la inversa, Cloudnet podría usar infraestructura india de terceros que no aparece en su propio espacio de direcciones. El país de registro y la residencia de datos son afirmaciones separadas.
La tercera es el control. Si Cloudnet revendiera máquinas virtuales de otro proveedor, Cloudnet podría controlar la facturación y el soporte mientras el proveedor subyacente controlaría racks, hipervisores, energía y piezas. Si Cloudnet arrendara colocación, podría poseer servidores pero no los sistemas del edificio. Si operara su propia sala, aún podría depender de propietarios y operadores. Los clientes necesitan saber quién puede restaurar la energía, reemplazar un disco, recuperar una copia de seguridad y aprobar el acceso de emergencia. Ningún documento público traza ese límite.
La cuarta es la redundancia. Un servicio en la nube puede replicar datos a través de unidades, hosts, racks, salas, edificios o regiones, cada uno protegiendo contra una falla diferente. Dos copias en un host no sobreviven a la falla del host. Dos hosts en un rack pueden compartir una unidad de distribución de energía. Dos racks en un edificio pueden compartir la energía de la red, la refrigeración y la fibra ascendente. Dos edificios aún pueden depender de un conducto metropolitano o plano de control. Sin una arquitectura revelada y una ruta de restauración probada, la palabra "nube" no dice nada sobre el dominio de falla.
La quinta es la salida. Un cliente que se recupera de una falla del proveedor necesita una imagen exportable, un volcado de base de datos, una copia de objeto, control DNS y suficiente tiempo y ancho de banda para moverse. La terminación del contrato, la disputa de facturación o la quiebra de la empresa pueden ser tan disruptivas como una falla de hardware si las credenciales o los datos están bloqueados en una cuenta. No se encontraron términos de Cloudnet que describan la devolución de datos, eliminación, asistencia para la migración, retención de copias de seguridad o suspensión de cuenta.
Estas no son alegaciones de que Cloudnet carezca de las capacidades. Son las preguntas mínimas que la evidencia pública necesitaría responder antes de asignar esas capacidades. Una cotización privada, un contrato o un programa técnico podrían cambiar la conclusión para un cliente en particular. Hasta que aparezca tal evidencia, AS150069 debe leerse como evidencia de operación de red, no como un producto de nube.
RPKI es una higiene de enrutamiento útil, no resiliencia por sí sola
Cloudnet ha dado un paso concreto de seguridad de enrutamiento.La validación de RIPEstat para el agregado IPv4encontró una autorización de origen de ruta válida que cubre AS150069 y permite anuncios hasta/24. Las rutas componentes son, por lo tanto, válidas bajo la misma autorización.La validación para el/48IPv6también fue válida.
RPKI ayuda a otras redes a rechazar un anuncio de origen que entre en conflicto con la autorización firmada. Reduce una clase de error de enrutamiento o secuestro. No verifica cada AS en la ruta, cifra el tráfico, detiene un corte de fibra, proporciona un segundo ascendente, previene la congestión o mantiene un enrutador encendido. Una ruta válida puede conducir a un servicio indisponible si la red de origen no tiene una ruta de trabajo hacia el cliente.
La combinación actual es, no obstante, significativa: recursos registrados, orígenes IPv4 e IPv6 activos, objetos de ruta y autorizaciones de origen válidas. Muestra más madurez operativa que un nombre de empresa inactivo. También agudiza la cuestión de la resiliencia porque la topología visible sigue siendo estrecha. La alcanzabilidad correctamente autorizada a través de un vecino observado sigue siendo un vecino observado.
Los anuncios IPv4 más específicos añaden otra arruga operativa. Durante el período en que los/24tenían baja visibilidad, el agregado/23permaneció ampliamente visible. Anunciar tanto el agregado como los específicos puede preservar una ruta de cobertura si un específico desaparece. También puede usarse para política o mitigación. Los recolectores públicos no pueden revelar el diseño previsto, y el agregado no crea un segundo camino físico. La redundancia de enrutamiento y la redundancia de circuito no deben confundirse.
IPv6 también merece una conclusión limitada. El/48ha sido anunciado globalmente durante años y su objeto de ruta se actualizó recientemente. Eso respalda el enrutamiento IPv6 activo en el borde de la red. No prueba que cada cliente minorista reciba un prefijo IPv6, que el equipo del cliente lo soporte, o que el personal de soporte solucione ambos protocolos por igual. Se necesitaría una divulgación específica del proveedor o una medición del lado del cliente para establecer la profundidad del despliegue.
Las personas afectadas probablemente son clientes de acceso, no cargas de trabajo alojadas
El ritmo diario de IPinfo, la licencia ISP y la ausencia de un catálogo de alojamiento apuntan hacia una red de acceso. Las estimaciones de usuarios observados de Cloudflare y las direcciones que responden en el área de Chennai apoyan esa dirección. No revelan nombres, ubicaciones exactas o tipos de clientes. La población probablemente afectada es, por tanto, condicional: hogares, pequeñas empresas o usuarios institucionales que reciben conectividad a través de AS150069 o mediante el servicio de acceso de Cloudnet.
Para un hogar, una interrupción interrumpe la mensajería, el streaming, el trabajo remoto, la educación, los pagos y los dispositivos conectados. Para una pequeña empresa, la misma falla puede detener aplicaciones en la nube, autorización de tarjetas, contacto con proveedores y comunicaciones con clientes. Una empresa que usa una dirección estática de Cloudnet también puede perder la alcanzabilidad entrante hacia una cámara, un punto final VPN o un servicio autoalojado. Estos son mecanismos, no afirmaciones de que alguna organización nombrada compre servicios de Cloudnet.
La dependencia se extiende más allá del titular de la cuenta. Un operador local o revendedor puede colocar clientes detrás del espacio enrutado de Cloudnet. No se vio ningún ASN descendente, pero los acuerdos minoristas descendentes no requieren un ASN separado. Si Cloudnet suministra capacidad a otro negocio de acceso, una falla en el límite Cloudnet-Niss podría afectar a usuarios que no reconocen ninguno de los nombres de empresa. El enrutamiento público no puede contar esos acuerdos.
Diferentes fallas producen diferentes síntomas. Una acometida cortada afecta a una premisa. Una falla de divisor o puerto de acceso afecta a un grupo. Una falla de agregación o backhaul afecta a un área más grande. La pérdida de la entrega a Niss puede afectar a toda la huella enrutada. Una falla de DNS o autenticación puede dejar los enlaces activos mientras las sesiones fallan. Errores de facturación o sistema de cuentas pueden desconectar a un individuo sin ninguna falla de red. El registro público no identifica qué sistemas opera Cloudnet por sí mismo.
La recuperación debe medirse desde el borde del cliente. Restaurar un anuncio BGP no es suficiente si la fibra de alimentación sigue cortada. Reparar la fibra no es suficiente si la autenticación está caída. Encender un conmutador no es suficiente si la sesión ascendente sigue indisponible. Un relato de incidente sólido identificaría la capa fallida, el operador responsable, las horas de inicio y restauración, el área afectada, la solución alternativa y si la capacidad se restauró por completo.
La ausencia de una página pública de incidentes o un historial de estado del servicio impide un juicio de rendimiento. El silencio no prueba una fiabilidad perfecta, y los informes dispersos de usuarios no establecerían una tasa a nivel de red sin verificación. La evidencia actual respalda el mapeo de la cadena de fallas, no la puntuación del tiempo de actividad histórico de Cloudnet.
Qué establecería una imagen operativa más sólida
El primer elemento faltante es una descripción actual de servicios orientada al cliente. Para el servicio de acceso, debe nombrar cobertura, tecnología de acceso, velocidades de plan, reglas de contención o uso justo, términos de instalación, contacto de fallas y objetivos de servicio. Para cualquier servicio alojado, debe especificar características de computación, almacenamiento, red, respaldo y migración. Un logotipo y una promesa genérica de servicio rápido no serían suficientes.
El segundo es un mapa de red físico y contractual a un nivel apropiado de abstracción. Cloudnet no necesita publicar rutas sensibles a nivel de calle. Podría revelar el número de puntos de presencia activos, las ciudades o zonas de servicio que cubren, si el backhaul es propio o arrendado, y si los circuitos ascendentes terminan en sitios separados y siguen rutas diversas. La clave es identificar dominios de falla comunes sin exponer secretos operativos.
El tercero es evidencia de capacidad. Las medidas útiles incluyen tráfico total y en hora punta, utilización de puertos, tránsito comprometido y de ráfaga, capacidad de conmutación por error, saturación de nodos de acceso y adopción de clientes IPv4/IPv6. Una instantánea debe llevar una fecha. La capacidad de diseño, las interfaces instaladas, la capacidad iluminada y el rendimiento disponible para el cliente deben informarse por separado.
El cuarto es evidencia de recuperación. Cloudnet podría declarar la autonomía de energía de respaldo por clase de sitio, política de hardware de repuesto, propiedad de escalamiento, ventanas de mantenimiento y rendimiento de restauración reciente. Una afirmación de resiliencia se vuelve creíble cuando se ha probado una falla: retiro de ruta, pérdida de ascendente, interrupción de energía, reemplazo de hardware y restauración de configuración. El resultado debe mostrar si el servicio realmente se movió y cuánta capacidad permaneció.
El quinto es la corroboración de topología independiente. Un segundo vecino visible fortalecería el caso de diversidad de enrutamiento pero aún requeriría evidencia de ruta física. Un circuito de respaldo hacia el mismo AS puede ser valioso si entra en una instalación diferente y evita conductos comunes. Por el contrario, dos nombres de proveedor pueden compartir el mismo operador de última milla. Los contratos, las ubicaciones de entrega y los estudios de ruta resuelven lo que BGP solo no puede.
El sexto es prueba para cualquier afirmación de nube. Un nombre de instalación o sitio verificable de forma independiente, términos del cliente, especificaciones de infraestructura, declaración de ubicación de datos, arquitectura de respaldo, matriz de responsabilidad de seguridad y procedimiento de salida moverían la discusión de la inferencia al análisis del producto. Un solo dominio alojado o un servidor que responda desde el/23no probaría una plataforma de nube comercial.
Hasta que esos elementos existan, la evidencia más sólida de Cloudnet sigue siendo su identidad de ISP regulado y el enrutamiento activo. Las incógnitas no son lagunas decorativas. Son los lugares exactos donde el servicio puede fallar: línea de acceso, energía de agregación, backhaul, entrega a Niss, tránsito posterior, escalado de soporte y restauración del cliente.
Una pequeña red activa, con una historia más concreta que su nombre
CLOUDNET INTERNET SERVICE PVT LTD no es una cáscara corporativa vacía. Tiene una autorización de servicios de Internet de Categoría B para Tamil Nadu, una identidad consistente en Chennai a través de registros públicos, un sistema autónomo activo, una asignación de 512 direcciones IPv4, un/48IPv6 anunciado y autorizaciones de origen de ruta válidas. Sus rutas han sido visibles desde 2022, y sus datos de registro se mantuvieron cerca de la fecha de observación.
La misma evidencia establece un límite firme. Se vio un vecino de enrutamiento inmediato. Ningún material público estableció diversidad ascendente o física, una huella de acceso mapeada, ancho de banda instalado, autonomía de energía de respaldo, rendimiento de reparación en campo o una operación de soporte con personal. Lo más importante, nada localizado estableció un servicio comercial de nube, VPS, bare metal, colocación, almacenamiento o alojamiento gestionado.
Ese no es un resultado decepcionante. Es uno más útil. El nombre ya no oscurece la superficie operativa que realmente se puede observar. Cloudnet parece transportar tráfico de acceso en Tamil Nadu a través de AS150069 y Niss Internet Services. Su resiliencia será decidida por infraestructura ordinaria: cables, electrónica alimentada, backhaul, configuración de rutas, piezas de repuesto y personas que puedan restaurarlos.
La calificación de la evidencia de red es Débil para una evaluación completa de infraestructura, a pesar de la fuerte evidencia de que el ASN está activo. El enrutamiento es visible; el sistema físico y comercial detrás de él no lo es. Una calificación más fuerte requiere prueba de dónde se conectan los clientes, cómo sale el tráfico, qué conmuta por error, cómo se comporta la capacidad bajo estrés y quién repara cada capa. Cualquier futura afirmación de servicio en la nube debe comenzar un paso antes, demostrando que hay un servicio alojado que evaluar.