AS60077 deja una huella clara, pero la infraestructura de

Summary

AS60077 aparece activo y ampliamente visible en IPv4: RIPEstat contabilizó 18 prefijos, 14.080 direcciones y observación desde 324 de 325 pares RIS de IPv4. Esa evidencia acredita una superficie de enrutamiento operativa, no la arquitectura física que presta cada producto de Cloud.ir.
El único vecino observado en el paquete es AS43754, asociado a Asiatech Data Transmission company. Esa relación no demuestra redundancia con proveedores independientes, mientras que la ficha pública de PeeringDB no declara conexiones a puntos de intercambio ni instalaciones.
Cloud.ir mantiene una oferta comercial vigente y publica un SLA, pero sus afirmaciones sobre centros de datos, estándares y alta disponibilidad son declaraciones del operador en este conjunto de fuentes. El SLA, además, deja fuera numerosas causas de interrupción; por eso la recuperación real y la capacidad disponible siguen siendo preguntas abiertas.

Una red visible desde fuera

El rastro más sólido comienza en los registros de numeración, no en la publicidad de producto. RIPE RDAP presenta AS60077 como un sistema autónomo activo con el nombre AT-CLOUD, vinculado a ORG-ADA42-RIPE y a Asre Dadeha Asiatech. El registro del autnum data del 27 de junio de 2022 y constaba como modificado por última vez el 23 de enero de 2026. En la consulta recogida para este análisis, el resumen de RIPEstat identificaba al titular como AT-CLOUD Asre Dadeha Asiatech y marcaba el sistema como anunciado.

La fotografía de enrutamiento recogida el 20 de julio de 2026 era concreta. RIPEstat atribuía a AS60077 18 prefijos IPv4 y 14.080 direcciones IPv4. Lo veían 324 de 325 pares RIS de IPv4, una propagación suficientemente amplia como para descartar la idea de un ASN meramente registrado y sin presencia observable. El último prefijo de la muestra, 193.151.156.0/24, figuraba como visto a las 16:00 UTC.

La lista de anuncios incluye bloques en 78.110.112.0/21, varios segmentos entre 85.198.8.0/22 y 85.198.22.0/23, y una serie de rangos en 193.151.128.0/22 hasta los prefijos más específicos próximos a 193.151.159.0/24. La vista de consistencia de RIPEstat añade una distinción útil: los prefijos IPv4 presentes en BGP también figuran en RIPE Whois, mientras que algunos rangos más amplios o componentes registrados no aparecían anunciados. Tener espacio documentado y originar espacio en ese instante no son, por tanto, la misma cosa.

La situación de IPv6 exige todavía más precisión. El estado de enrutamiento mostraba cero prefijos IPv6 originados visibles y cero observaciones entre 321 pares RIS de IPv6. La serie de prefijos anunciados sí contenía 2a05:1a30::/34, pero únicamente en una marca temporal del 13 de julio de 2026; no aparecía como espacio IPv6 originado en la fotografía actual. Eso no permite afirmar que Cloud.ir carezca de cualquier servicio IPv6. Permite decir algo más limitado: este paquete no verificó una originación IPv6 pública y sostenida desde AS60077 en el momento analizado.

Lo que cuentan dieciocho prefijos, y lo que no cuentan

El número de prefijos merece una lectura más detenida porque es fácil confundir inventario de rutas con escala de servicio. La relación observada no es una cifra abstracta. Comprende 78.110.112.0/21; 85.198.8.0/22; 85.198.12.0/22; 85.198.16.0/23; 85.198.19.0/24; 85.198.20.0/23; 85.198.22.0/23; siete bloques /22 desde 193.151.128.0/22 hasta 193.151.152.0/22; y cuatro bloques /24 desde 193.151.156.0/24 hasta 193.151.159.0/24. Esa composición explica los 18 anuncios IPv4 que RIPEstat atribuyó a AS60077 en la consulta. Da una base concreta para comprobar que la red origina espacio y que no se está describiendo sólo una inscripción administrativa.

La cifra de 14.080 direcciones añade otra medida del espacio anunciado, pero no puede convertirse en un censo de servidores. Una dirección puede estar asignada, reservada, compartida, utilizada para infraestructura o no utilizada; el paquete no desglosa esos estados. Tampoco ofrece una relación entre direcciones y máquinas virtuales, cuentas, volúmenes de almacenamiento o clientes. Incluso si se conociera la ocupación de cada dirección, seguirían faltando procesadores, memoria, almacenamiento, ancho de banda interno y límites comerciales para calcular capacidad utilizable.

El dato es sólido en el plano de numeración y silencioso en el plano de producto.

Lo mismo ocurre con la visibilidad de 324 de 325 pares RIS de IPv4. Es una señal fuerte de propagación: casi todos los observadores de esa muestra veían el origen. No es una medición de latencia, pérdida, congestión o rendimiento. Dos redes pueden ser igualmente visibles para colectores BGP y ofrecer experiencias muy distintas a una aplicación. La observación tampoco identifica el edificio desde el cual salió cada anuncio ni permite saber si varios anuncios comparten una única dependencia física. Alcance del plano de rutas y diversidad del plano de ejecución no son sinónimos.

El momento de la captura es igualmente importante. RIPEstat marcó AS60077 como anunciado a las 08:00 UTC del 20 de julio de 2026 y el estado de enrutamiento situó la última observación de 193.151.156.0/24 a las 16:00 UTC. Esas marcas permiten hablar en presente con referencia a una consulta definida. No autorizan a reconstruir por sí solas una historia de disponibilidad. Una red visible durante la captura pudo haber tenido incidencias antes o después; una red que no aparezca en otra captura podría seguir atendiendo servicios por caminos que esa observación no muestre. Este artículo trata la fotografía como fotografía, no como un registro continuo.

La diferencia entre IPv4 e IPv6 refuerza esa disciplina temporal. Para IPv4 hay un conjunto actual de anuncios, un recuento de direcciones y una visibilidad amplia. Para IPv6 hay una aparición de 2a05:1a30::/34 en una sola marca temporal del 13 de julio y ninguna originación visible en el estado actual. El expediente no permite decidir si aquella aparición fue una prueba, una transición, una observación incompleta o una actividad de otra naturaleza. Tampoco permite trasladar automáticamente el hallazgo al catálogo de Cloud.ir. La conclusión no es que IPv6 sea imposible, sino que su entrega pública actual no quedó demostrada por AS60077 en esta muestra.

Esta lectura por capas evita dos errores opuestos. El primero sería minimizar la red porque la infraestructura física no está documentada: los 18 prefijos y su propagación sí son evidencia operacional relevante. El segundo sería magnificar la misma evidencia hasta hacerla representar la plataforma completa: BGP no ve inventarios de cómputo, réplicas, personal de guardia ni procesos de recuperación. AS60077 resuelve una pregunta estrecha y valiosa, “¿hay una superficie IPv4 pública y observable?”, pero deja abiertas las preguntas que un comprador formula después.

Una ruta válida no describe un centro de datos

La calidad registral de una ruta aporta confianza, pero sólo dentro de su propia capa. Para 193.151.156.0/24, la consulta de validación RPKI de RIPEstat devolvió el estado valid, con ROA que autorizaba el origen 60077. Es una señal positiva sobre esa combinación concreta de prefijo y origen. No equivale a una auditoría de los 18 anuncios, y mucho menos a una prueba sobre alimentación eléctrica, refrigeración, almacenamiento o conmutación dentro de una instalación.

RIPE RDAP sitúa ese prefijo dentro de un rango PA asignado y activo llamado IR-AT-20210316, con país IR, desde 193.151.128.0 hasta 193.151.158.255. El registro muestra ASIATECH-MNT y contactos administrativos y técnicos de Asiatech NOC. Esta cadena enlaza recursos de numeración, mantenedor y operación de red de una forma que puede comprobarse públicamente. Sin embargo, una dirección registrada no revela en qué edificio termina un paquete, quién posee el bastidor, cuánta capacidad queda disponible para nuevos clientes o cuánto tarda una carga en recuperarse después de un fallo.

Ése es el límite central del expediente. AS60077 hace visible un plano de control IPv4. No convierte ese plano de control en un plano de instalaciones.

La cadena registral responde, en realidad, a tres preguntas distintas. RIPE RDAP atribuye el autnum AT-CLOUD a ORG-ADA42-RIPE y Asre Dadeha Asiatech. El registro de direcciones vincula el rango que cubre 193.151.156.0/24 con IR-AT-20210316, ASIATECH-MNT y Asiatech NOC. La validación RPKI confirma que, para esa muestra, el origen 60077 estaba autorizado por ROA. Identidad del recurso, responsabilidad de mantenimiento y autorización de origen forman una secuencia coherente. Ninguno de esos eslabones contiene una afirmación sobre el estado de una máquina virtual o la salud de una zona de servicio.

Conviene precisar también el alcance de la palabra valid. En RPKI significa que el anuncio examinado concuerda con una autorización de origen aplicable. No significa que la ruta sea la más corta, que no esté congestionada, que el sistema que responde en el destino sea legítimo o que el servicio cumpla su SLA. Tampoco certifica la configuración de otros prefijos que no fueron el objeto de esa consulta concreta. Usar una muestra válida para afirmar que toda la plataforma está auditada sería desplazar una propiedad del control de rutas hacia capas que RPKI no inspecciona.

Las fechas del autnum añaden continuidad documental, no continuidad de servicio. La inscripción de AS60077 se remonta al 27 de junio de 2022 y el campo de última modificación estaba fechado el 23 de enero de 2026. Eso muestra que el objeto existe desde hace años y que fue actualizado. No informa cuántos cambios operativos ocurrieron entre ambas fechas, qué motivó la última modificación ni si la arquitectura comercial de Cloud.ir permaneció igual. Un registro actualizado reduce la posibilidad de estar leyendo un objeto completamente abandonado, pero no sustituye una cronología de operación.

También debe evitarse una inferencia geográfica excesiva. El país IR del rango RDAP y la afirmación oficial de que Cloud.ir funciona sobre centros de datos de Asiatech en Irán son señales compatibles. No forman un mapa de instalaciones. El país del recurso no determina la ubicación exacta de cada servidor ni la trayectoria física de cada sesión. Una dirección puede anunciarse desde distintos emplazamientos y una aplicación puede combinar redes, capas de entrega o componentes que no aparecen en la ficha del prefijo analizado. El paquete no documenta esa combinación, así que no se le atribuye ninguna concreta.

Esta separación no rebaja el valor de los registros. Al contrario, permite usarlos con precisión. Para atribución de red y autorización de origen, RIPE RDAP, RIPEstat y RPKI ofrecen una base verificable. Para evaluar energía, refrigeración, capacidad de almacenamiento, aislamiento entre fallos o procedimientos de restauración, hace falta otra clase de evidencia. El problema no es que el primer grupo sea débil, sino que contesta preguntas diferentes.

Un vecino observado no constituye redundancia independiente

La vista de vecinos de RIPEstat devolvió uno solo para AS60077: AS43754. Tanto RIPEstat como RIPE RDAP muestran AS43754 como activo y lo asocian a Asiatech Data Transmission company. bgp.tools también resume AS43754 como upstream de AS60077 y clasifica la red, entre otras etiquetas, dentro de alojamiento de servidores.

La consistencia entre BGP y Whois refuerza la existencia de esa relación: AS43754 aparece en los datos de importación y exportación de ambas vistas. AS212895, en cambio, figura en la información de importación de Whois, pero no en la observación BGP recogida. La diferencia importa. Una política registrada expresa una intención o configuración declarada; una relación observada ofrece evidencia de visibilidad en ese momento. Ninguna de las dos, por sí sola, demuestra qué ocurriría durante una avería.

Por eso AS43754 no puede contarse como una segunda ruta independiente sólo porque tenga un ASN distinto. Las fuentes lo sitúan dentro del perímetro de Asiatech Data Transmission company y no documentan otro upstream ajeno, una conmutación probada ni un diseño de caminos físicamente separados. Es posible que existan acuerdos, reservas o mecanismos que esta muestra pública no capte. Lo que no es posible es presentarlos como hechos verificados.

El matiz entre “un vecino observado” y “el único vecino posible” es esencial. La consulta de RIPEstat devuelve lo que sus datos permitían observar para AS60077 en ese momento. No es un inventario contractual de todos los enlaces, y el paquete no contiene configuraciones internas. Por eso este análisis no afirma que no exista ningún otro camino. Afirma que el único camino externo respaldado por la evidencia reunida es la relación visible con AS43754. Si hay enlaces de reserva, transporte privado o acuerdos que no se propagan a esa vista, quedan fuera de lo probado.

La independencia tampoco se decide contando números de sistema autónomo. Dos ASN pueden compartir grupo empresarial, instalaciones, canalizaciones, alimentación, equipos o procesos de cambio. El paquete sólo documenta aquí el vínculo nominal de AS43754 con Asiatech Data Transmission company y su papel como vecino observado; no describe los demás componentes. Esa asociación basta para impedir que AS43754 sea presentado como evidencia de diversidad frente al propio perímetro de Asiatech. No basta para describir exactamente qué recursos comparte con AS60077.

La mención de AS212895 ilustra por qué una política declarada no debe rellenar el vacío. Aparece en la información de importación de RIPE Whois, pero no en la relación BGP capturada. Ese contraste puede deberse a una política no activa, una ruta no visible para la muestra, una configuración de reserva u otra circunstancia que las fuentes no explican. Elegir una de esas hipótesis convertiría una ausencia de observación en una historia inventada. Lo verificable es únicamente la diferencia entre el registro de política y el plano observado.

Para demostrar redundancia independiente haría falta una cadena más rica: al menos otro proveedor identificable fuera del mismo perímetro, evidencia de que los caminos no convergen inmediatamente en una dependencia común, y pruebas de que la conmutación funciona bajo fallo. Aun esa información de red no resolvería por sí sola la diversidad de instalaciones. Dos upstreams pueden entrar por el mismo lugar; dos instalaciones pueden depender de una misma capa de control. La redundancia es una propiedad del diseño completo y de su operación, no una etiqueta que pueda inferirse de una tabla de vecinos.

Desde el punto de vista del cliente, el hallazgo cambia la pregunta contractual. No se trata de preguntar sólo cuántos enlaces tiene el proveedor, sino qué componentes siguen compartidos cuando uno falla, qué productos utilizan cada camino y cómo se verifica la transición. El paquete no contiene respuestas a esas preguntas. Sí contiene una razón concreta para formularlas: la superficie pública observada concentra la relación externa de AS60077 en AS43754 y no prueba una alternativa independiente.

El silencio de PeeringDB también tiene límites

PeeringDB contiene una ficha vigente para ASN 60077 bajo el nombre Asre Dadeha Asiatech, con status=ok y rir_status=ok. A la vez, la ficha informa ix_count=0 y fac_count=0; no publica sitio web, looking glass, route server, URL de política ni datos de tráfico o alcance.

La tentación sería convertir esos ceros en una conclusión física: ninguna instalación, ningún intercambio, ninguna interconexión. Sería un error. PeeringDB es una base de datos de divulgación voluntaria y su ficha sólo prueba qué se ha declarado allí. Los ceros no niegan la existencia de infraestructura privada o de tránsito contratado.

Pero tampoco son neutros para una evaluación comercial. Sin instalaciones o puntos de intercambio declarados, el comprador no puede usar esa ficha para contrastar diversidad metropolitana, presencia en edificios, alcance de peering o separación de rutas. La visibilidad BGP indica que los prefijos llegan a Internet; la ficha de PeeringDB no permite reconstruir por dónde, desde cuántos emplazamientos ni bajo qué dependencias físicas.

Los campos de estado de la ficha tampoco resuelven ese vacío. status=ok y rir_status=ok indican que el registro de red está vigente dentro de PeeringDB y que su estado frente al registro regional no aparece como problemático. No certifican actividad en una instalación, sesiones de intercambio, volumen de tráfico ni atención a clientes. Son propiedades de la ficha y de su relación registral, no un parte de salud de la plataforma.

La ausencia de sitio web en esa ficha no contradice que Cloud.ir sea accesible. Sólo muestra que el registro de ASN 60077 en PeeringDB no publica ese enlace. Del mismo modo, la ausencia de looking glass impide a un tercero usar esa herramienta concreta para observar rutas desde la perspectiva del operador, pero no demuestra que la red carezca de herramientas internas. La falta de una URL de política reduce la información pública sobre criterios de interconexión; no permite asumir una política determinada.

PeeringDB funciona mejor aquí como índice de divulgación que como inventario negativo. Si una instalación o un punto de intercambio estuvieran declarados, serían pistas verificables para continuar la diligencia. Al no estarlo, la ficha no ofrece esas pistas. Un operador puede usar tránsito privado sin publicar una presencia, y puede mantener infraestructura en lugares que no registra en esta base. El coste analítico del silencio es que un tercero debe obtener evidencia por otra vía, no que pueda concluir que la infraestructura no existe.

Ese coste importa porque la misma ruta puede ser visible desde casi todos los pares RIS y seguir atravesando dependencias concentradas. Los colectores muestran propagación del prefijo; PeeringDB podría, si la ficha fuera más completa, aportar nombres de instalaciones o intercambios para investigar diversidad. En este caso no lo hace. La combinación de ambos conjuntos dice “la red llega” y “el camino físico no está divulgado”, una conclusión más precisa que declarar tanto fortaleza como debilidad sin pruebas.

Una oferta comercial actual, sin un mapa técnico completo

En el otro extremo del análisis, el dominio cloud.ir muestra una superficie comercial activa. La página principal, el mapa de servicios y las páginas de producto de Cloud.ir ofrecen servidor cloud, VPS, centro de datos cloud, conmutación cloud, gestión de dominios, CDN y almacenamiento cloud. Las fechas lastmod del mapa para servicios centrales se extienden por 2025 y 2026, una señal de mantenimiento reciente del catálogo público.

Las páginas oficiales afirman que el servicio comenzó en el año iraní 1399, que ofrece más de 20 productos cloud y que opera sobre centros de datos de Asiatech en Irán. También describen prestaciones de disponibilidad y hacen referencias a ISO27001, TIA-942 y categorías Tier 2/3. Esas afirmaciones ayudan a entender cómo el operador presenta su producto, pero este paquete no incluye certificados independientes, una lista exacta de instalaciones ni una auditoría de su topología eléctrica, térmica o de comunicaciones.

La coexistencia de la marca comercial y el ASN no basta para asignar todos los productos al mismo recorrido. Las fuentes conectan Cloud.ir con Asiatech y muestran AS60077 como una red activa de Asre Dadeha Asiatech. No trazan, servicio por servicio, qué front-end, red de entrega, almacenamiento o plataforma de gestión utiliza AS60077. Un catálogo vivo demuestra que existe una puerta de entrada para clientes; no demuestra que cada carga siga la misma ruta ni que toda la capacidad anunciada comercialmente sea visible desde los datos de enrutamiento.

Esta separación es especialmente importante en cloud. BGP puede mostrar quién origina un prefijo. No muestra cuántas máquinas pueden aprovisionarse, qué proporción de almacenamiento está replicada, dónde se sitúa el dominio de fallo o cuánta capacidad permanece libre durante una incidencia.

La página de contacto añade una superficie pública para ventas y soporte, pero tampoco debe cargarse con más significado del que tiene. Su existencia ayuda a confirmar que el sitio se presenta como un servicio actual y ofrece una vía de relación. El paquete no incluye pruebas de tiempos de respuesta, resolución de casos o disponibilidad del personal. Una dirección de contacto es evidencia de exposición comercial; la capacidad operativa del canal requeriría una prueba diferente.

El catálogo permite saber qué categorías quiere vender Cloud.ir. Servidor cloud, VPS y centro de datos cloud son ofertas distintas incluso si comparten parte de la infraestructura. El mapa también enumera conmutación cloud, gestión de dominios, CDN y almacenamiento. Cada categoría puede depender de componentes diferentes: plano de gestión, red de acceso, cómputo, almacenamiento o distribución. Esta observación describe la necesidad de mapear dependencias, no afirma qué arquitectura concreta utiliza Cloud.ir. Las fuentes no proporcionan ese diagrama.

La afirmación de más de 20 productos amplía la misma cuestión. Un número elevado de productos puede reflejar variedad comercial, combinaciones de funciones o una plataforma extensa; el paquete no permite escoger entre esas lecturas. Tampoco identifica qué productos comparten un dominio de fallo ni cuáles utilizan AS60077 como ruta de cliente. Por eso el recuento oficial se conserva como declaración del operador, pero no se utiliza para calcular capacidad ni diversidad.

El inicio en el año iraní 1399 aporta contexto sobre la historia que cuenta la empresa. No prueba que todos los servicios actuales existieran desde entonces ni que la arquitectura haya permanecido estable. Las fechas lastmod de 2025 y 2026 muestran actividad editorial reciente en páginas centrales, no una auditoría de cambios técnicos. Una página actualizada puede describir correctamente una oferta y aun omitir el detalle que exige una evaluación de continuidad.

Las referencias a ISO27001, TIA-942 y niveles Tier 2/3 necesitan un tratamiento igualmente estricto. Son afirmaciones que aparecen en páginas oficiales y, por tanto, forman parte de la representación pública del servicio. Este paquete no incluye el certificado, su alcance, la entidad certificadora, las instalaciones cubiertas ni su vigencia. Tampoco ofrece un informe independiente que permita vincular las descripciones de nivel con una ubicación concreta. El artículo no niega esas afirmaciones; las mantiene en la categoría de declaraciones no verificadas de forma independiente.

Esa categoría evita una falsa dicotomía. Una afirmación oficial no es inútil: señala qué garantías considera relevante comunicar el operador y qué documentos podría solicitar un cliente. Pero tampoco tiene el mismo peso que un certificado comprobable o una prueba de instalación. La diligencia consiste en conservar la afirmación, identificar su fuente y preguntar por el soporte que falta, no en aceptarla o descartarla de manera automática.

Del catálogo a la ruta hay un salto que las fuentes no cierran

La coincidencia entre los nombres Asre Dadeha Asiatech, AT-CLOUD y Cloud.ir crea una relación razonable entre empresa, red y marca. RIPE RDAP atribuye AS60077 a la organización; RIPEstat emplea el nombre AT-CLOUD Asre Dadeha Asiatech; las páginas oficiales presentan Cloud.ir sobre centros de datos de Asiatech. Esa alineación permite analizar los elementos en un mismo expediente. No permite afirmar que el ASN sea el camino exclusivo de toda la oferta.

Para cerrar esa atribución harían falta observaciones por producto. Un cliente podría resolver nombres de servicio, revisar qué prefijos atienden cada endpoint y comparar rutas desde distintas ubicaciones. Podría descubrir que algunas funciones pasan por AS60077 y otras por redes diferentes, o que todos los componentes convergen en la misma superficie. Este paquete no realizó ni contiene ese mapa. Por ello, el artículo no asigna servidores cloud, VPS, CDN, almacenamiento o gestión de dominios a un prefijo concreto.

La limitación es importante porque la experiencia de cliente no termina en el primer paquete IP. Un portal puede estar accesible mientras el plano de aprovisionamiento falla; una máquina puede responder mientras el almacenamiento dependiente está degradado; una red puede anunciar el prefijo aunque la aplicación no acepte solicitudes. Estos son ejemplos de capas que una diligencia debería separar, no afirmaciones de incidentes en Cloud.ir. Los datos públicos de rutas sólo observan una parte de esa cadena.

Tampoco hay una equivalencia automática entre “centro de datos cloud” como nombre de producto y un centro de datos físico identificable. La página oficial describe una oferta y realiza afirmaciones de disponibilidad y redundancia. PeeringDB no aporta instalaciones para ASN 60077, y el paquete no contiene una lista independiente de edificios. El nombre comercial puede ser válido sin revelar la ubicación, el control o la diversidad física. La evaluación debe pedir esa información por separado.

La atribución de capacidad presenta el mismo salto. Los 14.080 números IPv4 no indican cuántas instancias están disponibles para venta. Más de 20 productos no indican cuántos recursos quedan libres. Un estado de ruta anunciado no mide saturación de CPU, almacenamiento o enlaces internos. La capacidad utilizable sólo podría sostenerse con inventarios, métricas, límites contractuales o pruebas de aprovisionamiento que no están en las 20 fuentes. Por eso no se deriva una cifra comercial de los registros de red.

El resultado es una relación comprobable pero incompleta: existe una organización registrada, una red pública activa y una marca de servicios accesible. Las conexiones entre esos tres elementos son suficientes para formular preguntas específicas, pero no para dibujar una topología extremo a extremo. La fortaleza del análisis está en mantener esa frontera, sobre todo cuando los nombres invitan a saltarla.

El SLA dibuja el perímetro del fallo

La página de SLA de Cloud.ir aporta una pieza que los registros de rutas no pueden ofrecer: la definición contractual de disponibilidad. La garantía publicada se limita a la disponibilidad de red y de servidores cloud bajo operación ordinaria. Excluye, entre otros supuestos, software y sistemas operativos del cliente, errores de configuración, ataques de denegación de servicio, suspensión, mantenimiento, parches críticos, fuerza mayor, fallos de equipos del cliente, interrupciones solicitadas, impago y órdenes legales o de seguridad.

Estas exclusiones no prueban que la operación sea débil. Cualquier SLA delimita responsabilidades. Sí muestran que la palabra “disponibilidad” no puede leerse como una promesa absoluta de continuidad de la aplicación. Una carga puede quedar inaccesible por una causa excluida aunque la infraestructura se considere disponible según el contrato. También puede existir una diferencia entre restaurar conectividad, recuperar una máquina y restablecer un servicio completo con sus datos y dependencias.

El documento público no permite medir tiempos reales de detección, conmutación, reparación o recuperación. Tampoco ofrece en este paquete resultados históricos de incidentes, pruebas de desastre o una matriz que vincule productos con dominios de fallo. Por eso las afirmaciones comerciales sobre persistencia, continuidad o alta disponibilidad deben leerse junto con las exclusiones, no en lugar de ellas.

El valor analítico del SLA está en que obliga a separar niveles de servicio. Disponibilidad de red puede significar que existe conectividad hacia una plataforma. Disponibilidad del servidor cloud puede referirse a la instancia dentro del perímetro definido por el operador. Funcionamiento del sistema operativo, la configuración y la aplicación recae en otras capas que el texto excluye. Una experiencia de usuario puede depender de todas a la vez, mientras que el compromiso contractual sólo cubre algunas.

El tratamiento de mantenimiento y parches críticos añade otra frontera. Una interrupción planificada o necesaria para proteger la plataforma puede quedar fuera de la garantía publicada. Eso no permite afirmar con qué frecuencia ocurre ni cuánto dura, porque el paquete no aporta un historial. Sí impide interpretar el porcentaje de disponibilidad como una promesa sin excepciones temporales. Para estimar riesgo, un cliente tendría que conocer el aviso, la duración y el efecto de esas intervenciones en su producto concreto.

La exclusión de ataques de denegación de servicio también muestra la diferencia entre presencia de red y continuidad comercial. AS60077 puede seguir anunciado mientras una carga o un acceso están afectados por tráfico hostil. El expediente no evalúa controles contra esos ataques ni registra incidentes. Sólo muestra que el SLA no incorpora esa causa dentro de la garantía general descrita. Por tanto, una compra sensible a ese riesgo necesitaría condiciones o evidencia adicionales, no una inferencia a partir de la visibilidad BGP.

Fuerza mayor, impago y órdenes legales o de seguridad son causas de naturaleza distinta, pero producen la misma consecuencia metodológica: la disponibilidad técnica no agota la posibilidad de suspensión. El riesgo de servicio incluye decisiones contractuales y regulatorias además de fallos de equipos. Las fuentes no cuantifican esos riesgos. El SLA simplemente confirma que están fuera o en el borde del compromiso ordinario.

Recuperar conectividad tampoco equivale necesariamente a recuperar datos y funciones. Para evaluar esa diferencia se necesitarían objetivos de restauración, política de copias, alcance de réplicas, dependencia entre ubicaciones y evidencia de pruebas. Ninguno aparece en el paquete. Es legítimo que parte de esa información sea privada, pero en su ausencia el registro público no puede sostener una afirmación fuerte sobre comportamiento de recuperación.

Así, el SLA no debe leerse como prueba de mala calidad ni como prueba suficiente de resiliencia. Es un documento de delimitación. Señala qué parte del fallo acepta medir el operador y qué causas deja fuera. Junto con los datos de red, ofrece una visión más honesta: la superficie pública puede estar activa y bien propagada, mientras que la continuidad de una aplicación sigue dependiendo de condiciones que BGP no observa y el contrato puede excluir.

Tres niveles de evidencia para una misma nube

La información reunida se vuelve más útil si se organiza en tres niveles: hechos observados, afirmaciones del operador y cuestiones no resueltas. Mezclarlos produciría una conclusión excesiva; separarlos permite evaluar CLOUD Asre Dadeha Asiatech sin borrar ni inflar la evidencia.

En el primer nivel están los hechos observados en fuentes registrales y de enrutamiento. AS60077 figura activo en RIPE RDAP con el nombre AT-CLOUD y la organización ORG-ADA42-RIPE. RIPEstat lo marcó como anunciado, registró 18 prefijos IPv4, 14.080 direcciones, visibilidad desde 324 de 325 pares RIS de IPv4 y un vecino observado. La muestra 193.151.156.0/24 fue válida en RPKI para origen 60077. El rango relacionado figura bajo IR-AT-20210316, con ASIATECH-MNT y Asiatech NOC. Son afirmaciones concretas, fechadas y comprobables dentro de las fuentes.

También pertenece a ese nivel la forma de la divulgación pública. PeeringDB mantiene una ficha con estado correcto, pero con cero instalaciones y cero puntos de intercambio declarados, además de los demás campos vacíos señalados. bgp.tools resume una red activa, 18 prefijos IPv4, cero prefijos IPv6 originados y AS43754 como upstream. RIPEstat identifica AS43754 como el único vecino observado y no muestra una originación IPv6 actual. Estas vistas no son idénticas, pero convergen en una red IPv4 visible y una topología pública muy poco detallada.

En el segundo nivel están las afirmaciones oficiales de Cloud.ir. El sitio accesible presenta un catálogo actual, declara un inicio en el año iraní 1399, más de 20 productos y operación sobre centros de datos de Asiatech en Irán. Las páginas mencionan estándares y niveles de centros de datos, y describen disponibilidad para sus servicios. El SLA define el alcance y las exclusiones de la garantía. Estas declaraciones deben citarse como tales: son la posición pública del operador y no hallazgos independientes sobre instalaciones.

El tercer nivel contiene lo que el paquete no resuelve. No hay un recorrido verificable desde cada producto hasta una instalación, ni una lista independiente de ubicaciones que atienden AS60077. No se prueba diversidad con proveedores externos, separación física de caminos, capacidad asignable, topología de almacenamiento, comportamiento de conmutación o recuperación. Tampoco se demuestra originación IPv6 actual desde AS60077 ni se descarta que algún producto disponga de IPv6 por otra vía.

Esta clasificación evita usar la incertidumbre como acusación. “No demostrado” no significa “falso” y “no divulgado” no significa “inexistente”. Significa que una decisión que dependa de esa propiedad necesita otro soporte. Al mismo tiempo, evita que una afirmación comercial ocupe el lugar de una prueba sólo porque sea plausible. El grado de confianza debe seguir la clase de fuente y la pregunta exacta.

Para un lector no técnico, la distinción puede resumirse así: sabemos que la red tiene una identidad, anuncia IPv4 y es visible; sabemos qué servicios dice ofrecer Cloud.ir y cómo limita su SLA; no sabemos, con estas fuentes, qué instalaciones y caminos sostienen cada servicio durante un fallo. Las tres frases pueden ser verdaderas a la vez. La evaluación responsable no tiene que elegir entre “operación real” y “opacidad total”; debe describir la zona comprobada y el borde de la incertidumbre.

La diligencia útil empieza en el borde de esa incertidumbre

Una solicitud de información bien formulada debería comenzar por el mapa de servicio. Para cada producto relevante, el cliente necesitaría identificar los endpoints, la red de entrega, las dependencias de gestión, el almacenamiento y las ubicaciones aplicables. El objetivo no sería exigir la publicación de detalles sensibles, sino comprobar si dos componentes que se presentan como redundantes comparten un mismo dominio de fallo. El paquete no ofrece ese mapa, de modo que la respuesta tendría que proceder del operador o de pruebas acordadas.

La segunda solicitud debería tratar la conectividad. La evidencia pública muestra AS43754 como vecino observado y no verifica otro upstream independiente. Una revisión podría pedir qué caminos atienden el producto, si pertenecen a organizaciones distintas, dónde convergen y qué prueba demuestra la conmutación. Una lista de proveedores sin topología no sería suficiente: la independencia depende también de la entrada física, los equipos y los procesos comunes.

La tercera se refiere a las instalaciones. Las afirmaciones sobre centros de datos, ISO27001, TIA-942 y niveles Tier 2/3 podrían respaldarse con documentos cuyo alcance identifique ubicación, servicio, titular y vigencia. El paquete no contiene esos documentos, por lo que este artículo no anticipa su contenido. Una verificación adecuada comprobaría además que la instalación certificada es la que realmente presta el producto contratado, en lugar de asumirlo por asociación de marca.

La capacidad exige otra conversación. Un cliente que dependa de crecimiento rápido o de recursos de reserva debería pedir límites de aprovisionamiento, cuotas, capacidad garantizada y comportamiento durante una incidencia. Los prefijos y las direcciones no responden a esas cuestiones. Tampoco basta el número de productos. La pregunta comercial no es cuánto espacio de numeración existe, sino qué recursos puede comprometer el operador bajo condiciones definidas y cómo se evita vender dos veces la misma reserva.

IPv6 debe confirmarse al nivel del producto. La captura no mostró prefijos IPv6 originados actualmente por AS60077 y sólo registró 2a05:1a30::/34 en una marca anterior. Un comprador no debería convertir esa ausencia en una negativa general ni la marca aislada en una promesa. Debería comprobar si el servicio contratado ofrece IPv6, qué ASN y prefijo lo entregan, si la ruta está protegida por RPKI y si las condiciones de soporte son equivalentes a IPv4.

La recuperación requiere evidencia operacional. El SLA enumera exclusiones, pero no proporciona en este paquete resultados de ejercicios ni tiempos históricos. Una revisión podría pedir cómo se detecta un fallo, qué inicia la conmutación, qué datos se restauran, quién autoriza el retorno y cómo se comunica una incidencia. Las respuestas deberían relacionarse con el producto concreto, porque una restauración del plano de red puede preceder o no a la recuperación de la carga.

Finalmente, la diligencia debería conservar una salida independiente. Cuando la topología pública es limitada, el cliente puede reducir su dependencia mediante copias exportables, documentación de reconstrucción, credenciales separadas y una ruta de migración probada. Estas son medidas generales de gestión de dependencia, no una afirmación de que Cloud.ir vaya a fallar. Su relevancia nace precisamente de la falta de evidencia pública suficiente para modelar todas las capas.

Ninguna de estas solicitudes invalida los hechos positivos. La red está anunciada, una muestra está autorizada por RPKI, el catálogo está activo y existe un SLA. La diligencia utiliza esos hechos como punto de partida y dirige el esfuerzo hacia lo que aún no puede comprobarse. Pedir de nuevo lo que RIPEstat ya demuestra aportaría poco; pedir el mapa de instalaciones, la independencia real, la capacidad asignable y la recuperación cubre el vacío que las fuentes dejan.

Las preguntas que permanecen abiertas

Para un cliente, AS60077 es un punto de partida útil porque reduce una parte de la incertidumbre. Hay un ASN activo, prefijos IPv4 ampliamente vistos, coherencia entre BGP y RIPE Whois y una muestra RPKI válida. También hay un sitio de servicio accesible, productos actuales y un SLA publicado. No se trata de una operación invisible.

La diligencia técnica empieza justo donde terminan esas pruebas. Un comprador que necesite continuidad demostrable tendría que solicitar una relación de instalaciones aplicables a su servicio, explicar qué entidad controla cada tramo, pedir la topología de upstreams y los resultados de pruebas de conmutación, y separar capacidad instalada de capacidad realmente asignable. También debería confirmar si su producto dispone de IPv6, por qué camino se entrega y bajo qué soporte, en vez de inferirlo de una aparición aislada de 2a05:1a30::/34.

La recuperación necesita su propio expediente: objetivos contractuales, copias y réplicas, dependencia entre zonas, historial de incidentes y evidencia de ejercicios. Ninguno de esos elementos puede deducirse de que 193.151.156.0/24 sea RPKI-válido o de que 324 pares RIS vean AS60077. Son capas distintas del riesgo.

La conclusión prudente es doble. La evidencia pública respalda una superficie IPv4 viva y una oferta de Cloud.ir orientada a clientes. No respalda todavía un relato completo sobre la ruta hasta las instalaciones, la independencia del tránsito, la capacidad disponible o el comportamiento de recuperación. AS60077 permite ver la red desde fuera; para saber qué sostiene el servicio cuando algo falla, todavía hace falta evidencia que no está en el registro público consultado.

AS60077 deja una huella clara, pero la infraestructura de Cloud.ir queda fuera del registro público