Resumen

  • APNIC RDAP listaAS134768comoCHINANET-SHAANXI-CLOUD-BASE, con el nombre descriptivo red CHINANET SHAANXI provincia Cloud Base, país CN, registro en 2015 y un contacto de hostmaster de Chinanet.
  • La visibilidad de ruta actual es fuerte. Lavisión general de ASde RIPEstat reporta AS134768 como anunciado, mientras que elestado de enrutamientode RIPEstat muestra 86 prefijos IPv4, 39 prefijos IPv6 y 11 vecinos observados en la ventana pública revisada.
  • La topología sigue dependiendo del padre. Los datos de whois derivados de APNIClistan importaciones de AS4134 y AS4809, pero las vistas públicas de vecinos actuales de RIPEstat,bgp.tools, lapágina BGPde Hurricane Electric yIPinfotodas muestran a AS4134, China Telecom Backbone, como el upstream visible.
  • La evidencia de direcciones públicas es mixta de una manera que importa para la capacidad alojada. Muchos prefijos originados son recursos Shaanxi Chinanet, pero las vistas BGP públicas también muestran espacio enrutado descrito como IDC y servicio en la nube, línea arrendada, Baidu, Zhejiang, Guangdong y bloques de direcciones de Sichuan Xiaoteyun, por lo que un cliente no puede inferir la propiedad de la carga de trabajo o la ubicación del rack solo a partir del número AS.
  • Las señales públicas de las instalaciones apuntan a una base real de computación en la nube en Xi'an/Xixian. Un informe de visita de la Universidad del Noroeste de 2025 describe la Base de Computación en la Nube Shaanxi de China Telecom como un gran centro de computación en la nube y big data del oeste de China con más de 10,000 racks, salas estándar T4, PUE tan bajo como 1.25, opciones de rack de alta densidad y un papel en las operaciones de la nube gubernamental provincial.
  • El grado de evidencia es Medio, no Fuerte. La red está visiblemente viva y es grande, pero las fuentes públicas no publican un mapa actual y específico del producto de la propiedad de los racks, alimentación eléctrica, conmutación por error upstream, pruebas de restauración, límites de portabilidad de datos o escalación de soporte para clientes que compran capacidad alojada a través de esta red de base en la nube.

Una tabla de rutas en vivo es solo la primera prueba

Un proveedor de capacidad alojada puede parecer confiable de dos maneras muy diferentes. Una prueba es la tabla de rutas: las rutas son visibles, los prefijos están autorizados, los paquetes tienen un camino y el AS aparece bajo un operador conocido. La otra prueba es operativa: los racks tienen alimentación eléctrica, el sistema de refrigeración tiene margen, los hipervisores tienen capacidad sobrante, la copia de seguridad es restaurable, el servicio de soporte puede contactar al ingeniero adecuado y el cliente puede mover los datos cuando termina la relación.

La red CHINANET SHAANXI provincia Cloud Base tiene una primera prueba sólida y una segunda prueba pública más débil.

La identidad oficial es directa. APNIC RDAP paraAS134768nombra el AS comoCHINANET-SHAANXI-CLOUD-BASEy lo describe como red CHINANET SHAANXI provincia Cloud Base. El registro lo ubica en China, muestra registro el 27 de octubre de 2015 y lista contactos de hostmaster de Chinanet. Lavista whoisde RIPEstat repite el mismo nombre y descripción del AS, y añade líneas de política de ruta que importan de AS4134 y AS4809 y exportan AS134768 a esas redes. Eso es suficiente para tratar la red como un sujeto de enrutamiento real de China Telecom Shaanxi, no un vago eslogan de nube.

El estado de ruta actual también es relevante. Elestado de enrutamientode RIPEstat mostró AS134768 visible para casi todos los pares RIS tanto en IPv4 como en IPv6 en la ventana de julio de 2026 revisada. Contó 86 prefijos IPv4, 39 prefijos IPv6, 184,576 direcciones IPv4 y 12,576 equivalentes /48 de IPv6. Lavista de prefijos anunciadosde RIPEstat listó 125 entradas de prefijos actuales en IPv4 e IPv6. Lapágina BGPde Hurricane Electric reportó una escala similar, con 184,576 direcciones IPv4 originadas y ninguna ruta RPKI inválida originada en su vista actual. Esos no son signos de un ASN inactivo.

Pero una tabla de rutas no muestra todo el servicio. No dice si una máquina virtual se ejecuta en una sala propiedad de China Telecom, un rack propiedad del cliente dentro de la sala, un armario operado por un socio, una región de Tianyi Cloud, un grupo de nube gubernamental, un entorno de línea arrendada o un acuerdo de coubicación de terceros. No revela si el espacio anunciado está conectado a servidores de producción, puertas de enlace de borde, enrutadores de clientes, nodos de alojamiento, plataformas de contenido o enlaces comerciales privados.

No le dice al comprador cuánto tiempo se tarda en reemplazar un servidor fallido o si una cola de soporte sobrecargada puede retrasar una migración.

Esa diferencia es la dependencia central del artículo. AS134768 vende la impresión de capacidad de nube en red, y la evidencia BGP pública respalda la existencia de un borde grande y activo de China Telecom Shaanxi. El comprador aún tiene que probar la capa física y contractual detrás de ese borde. En el alojamiento, la interrupción más dañina a menudo no es «desapareció Internet».

Es la falla más pequeña y difícil: un rack pierde una alimentación y la alimentación restante ya está cargada, un cambio upstream expone una fuga de ruta, un grupo de almacenamiento tiene copias de seguridad pero sin una ruta rápida de restauración, una retención de facturación bloquea la exportación durante una migración, o una ventana de mantenimiento se trata como fuera de la promesa de disponibilidad.

Lo que demuestra el enrutamiento público

El enrutamiento público demuestra que AS134768 es visible y lo suficientemente importante como para monitorearlo. Lavisión general de ASde RIPEstat identifica al titular como CHINANET-SHAANXI-CLOUD-BASE, con el mismo nombre descriptivo utilizado por APNIC. El estado de enrutamiento actual de RIPEstat muestra una amplia visibilidad IPv4 e IPv6, no una ruta marginal vista por unos pocos recolectores. La misma página de estado informa la primera actividad vista en enero de 2017 y un último elemento visto el 12 de julio de 2026. Por lo tanto, el historial de rutas respalda la continuidad: Internet público ha visto este ASN durante años, y no fue simplemente registrado y abandonado.

Los agregadores de terceros coinciden con esa imagen.bgp.toolsclasifica la red como activa bajo APNIC, etiqueta el tipo de red como contenido, muestra China Telecom Backbone como el upstream, e informa 75 prefijos IPv4 y 39 IPv6 originados en su vista visible. Lapágina AS134768de Hurricane Electric informa 127 prefijos originados en total, 88 IPv4 y 39 IPv6, más 11 pares BGP observados.IPinfodescribe el ASN como orientado al alojamiento, lista China como el país, muestra decenas de miles de dominios alojados en direcciones dentro del ASN, y nombra a AS4134 como el upstream en su resumen visible.

Hay diferencias en los contadores porque los recolectores BGP públicos utilizan diferentes puntos de observación, opciones de filtrado y tiempos de actualización. RIPEstat contó 86 prefijos IPv4 en la vista de estado de enrutamiento, mientras que bgp.tools mostró 75 prefijos IPv4 originados y Hurricane Electric mostró 88. Esa variación no debe interpretarse como una contradicción. La señal común es más importante que el número exacto: AS134768 tiene una gran superficie enrutada, una fuerte ruta padre de China Telecom y una gran combinación de recursos IPv4 e IPv6.

La evidencia de origen de ruta también se ve mejor que la de muchas redes de alojamiento pequeñas. La validación de origen de ruta de RIPEstat para bloques IPv4 representativos de Shaanxi, como36.41.64.0/20,113.142.128.0/17y117.34.124.0/23, devolvió un estado válido para AS134768 en los resultados revisados. Lo mismo ocurre con bloques de nube y red IPv6 de muestra, como240e:982:4500::/40y240e:108:1140::/48. Las ROA válidas no garantizan la calidad del servicio, pero reducen una clase de riesgo de origen de ruta.

Por lo tanto, la conclusión operativa no es «red débil». Es «enrutamiento público sólido, evidencia de cliente incompleta». Un cliente puede creer razonablemente que AS134768 está activo. No debería, solo por eso, creer que su carga de trabajo alojada tiene protección multisitio, dos rutas de alimentación independientes, recuperación de respaldo probada o portabilidad de datos fácil. BGP responde a la pregunta de accesibilidad. La capacidad alojada requiere varias otras respuestas.

La historia del upstream es más estrecha de lo que sugiere la política del registro

El registro whois derivado de APNIC de AS134768 nombra dos importaciones: AS4134 y AS4809. AS4134 es China Telecom Backbone. AS4809 es la red CN2 de China Telecom, a menudo asociada con rutas de backbone premium. Si ambas rutas estuvieran llevando cargas de trabajo de clientes de manera activa e independiente, sería una diversidad útil. Las vistas de ruta públicas no prueban esa lectura más fuerte.

Lavista de vecinos ASNde RIPEstat mostró 11 vecinos observados en la ventana revisada. El vecino izquierdo era AS4134 con alta visibilidad en IPv4 e IPv6. Los vecinos derechos eran un conjunto de redes urbanas 5G de China Telecom Shaanxi, incluyendo AS138387 para Xi'an, AS138409 para Tongchuan, AS138436 para Baoji, AS138513 para Weinan, AS138514 para Xianyang y otras visibles principalmente en IPv6. El resumen de IPinfo también contó un upstream,AS4134. bgp.tools presentó similarmente a AS4134 como el upstream. Hurricane Electric mostró a AS4134 como el par IPv4 y también el par IPv6 nombrado en la tabla visible.

La brecha no es fatal. Un operador grande puede mantener registros de política de ruta que reflejen ingeniería interna, rutas planificadas o interconexión privada que los recolectores públicos no exponen completamente. AS4809 aún puede ser importante para algunos servicios incluso si AS4134 es el upstream público visible en las vistas muestreadas. Pero un cliente que compra capacidad alojada no debe tratar la línea AS4809 en whois como prueba de una ruta de conmutación por error viva que afecta al cliente.

La prueba es evidencia actual y específica del producto: qué upstream lleva este servicio, qué conmuta a qué, cómo se filtra la política de ruta, cómo se aplica RPKI, y si la ruta de respaldo tiene suficiente capacidad comprometida durante la carga máxima.

Esto es especialmente importante porque todas las rutas visibles se encuentran dentro de la familia más amplia de China Telecom. La resiliencia de la red padre puede ser excelente, pero no es lo mismo que la independencia comercial o física. Una verdadera afirmación de diversidad separaría al menos cuatro capas: diversidad de rutas BGP, diversidad de operador o backbone, diversidad de ruta física y capacidad sobrante después de la conmutación por error.

Si ambas rutas dependen de la misma zanja de fibra metropolitana, el mismo conmutador central de la base de nube, la misma entrada del edificio o el mismo plano de control de China Telecom, la segunda línea AS puede no proteger al cliente de la falla que le importa.

El lenguaje de adquisición correcto no es hostil. Un comprador puede preguntar: «Para el servicio que estamos adquiriendo, ¿qué AS de origen, ASN upstream, prefijos, zonas de disponibilidad y salas de datos físicas están dentro del alcance? ¿Qué ruta es primaria? ¿Qué ruta está probada? ¿Qué ruta está simplemente disponible para el operador en otra parte de la red?» Esa distinción evita que una red sólida de China Telecom se venda en exceso como resiliencia completa de múltiples proveedores.

La mezcla de prefijos muestra superficies de alojamiento, acceso y socios juntas

La lista de prefijos públicos es lo suficientemente amplia como para sugerir más de una superficie comercial. Muchos prefijos visibles son espacio de red Shaanxi Chinanet directo. APNIC RDAP para36.41.64.0/20resuelve a una asignación CHINANET-SN más grande, y la etiqueta de contacto administrativo sitúa la oficina de comunicación de datos en Xi'an. APNIC RDAP para113.142.128.0/17resuelve similarmente a una asignación CHINANET-SN. Esos bloques respaldan el caso de que AS134768 transporta recursos de direcciones de China Telecom Shaanxi, aunque algunas descripciones heredadas usan la ortografía «Shanxi(SN)» de maneras que pueden confundir Shaanxi con Shanxi. El contexto de contacto de Xi'an es el ancla práctica.

Otros recursos enrutados hacen que el límite operativo sea más complicado. bgp.tools lista varios bloques de estilo 103.236.0.0/22 con descripciones para Sichuan Xiaoteyun Technology. APNIC RDAP para103.236.88.0/22identifica a XIAOTEYUN como el nombre de recurso registrado y un contacto de Chengdu, Sichuan, mientras que lavisión general del prefijode RIPEstat muestra a AS134768 como el origen actual en la vista de ruta revisada. bgp.tools también muestra algunos prefijos descritos como Baidu y no Shaanxi Chinanet bajo la página AS134768. La presencia de esos recursos no es evidencia de irregularidades. Es evidencia de que el AS de origen, el cliente, el titular del recurso y la ubicación de la instalación pueden divergir.

Esa divergencia es normal en redes grandes. Un operador puede originar espacio PI de cliente, espacio protegido contra DDoS, direcciones de nube, redes de línea arrendada, bloques de entrega de contenido, segmentos de nube gubernamental o asignaciones de socios. El riesgo para el cliente es que el nombre del AS por sí solo no puede decir al comprador qué arreglo operativo se aplica.

Una VPS que se ejecuta en infraestructura de nube de China Telecom no es lo mismo que un enrutador de cliente cuyo prefijo es originado por AS134768, y tampoco es lo mismo que un sitio web alojado en una dirección IP contada por los datos de dominios alojados de IPinfo.

IPinfoilustra por qué esto importa. Reporta más de 23,000 dominios alojados en direcciones dentro del ASN y destaca 103.236.90.151 como una dirección con miles de dominios. Esa es una señal de mercado útil: el ASN parece alojar tráfico web denso en dominios. No puede probar el propietario contractual de esos sitios, la ubicación de los racks, la política de copias de seguridad, o si la dirección pertenece a un revendedor, una plataforma de alojamiento compartido, una capa CDN o un entorno gestionado por el cliente.

Para los clientes, el mapa de direcciones debería ser parte de la incorporación. ¿Qué prefijo se asignará al servicio? ¿Es espacio de China Telecom Shaanxi, espacio del cliente, espacio de socio o espacio compartido de Tianyi Cloud? ¿Quién controla el DNS inverso, el manejo de abusos, la creación de ROA, la política de firewall y el enrutamiento nulo de emergencia? Si se migra el servicio, ¿se mueve la IP con la carga de trabajo o el cliente recibe nuevas direcciones? Esas preguntas convierten una gran tabla de rutas en un mapa de dependencias real.

La etiqueta de base de nube apunta a capacidad física

Las señales públicas de las instalaciones hacen que el nombre «Cloud Base» sea más que decorativo. Un informe de visita de 2025 de la Escuela de Economía y Gestión de la Universidad del Noroeste describe laBase de Computación en la Nube Shaanxi de China Telecomcomo que comenzó su construcción en 2013 y entró en operación formal en 2015. El mismo informe la describe como un gran centro de computación en la nube y big data del oeste de China, con salas de computadoras estándar T4, PUE tan bajo como 1.25, más de 10,000 racks, opciones de gabinetes refrigerados por líquido de 5 kW, 8 kW, 12 kW y mayor potencia, una afirmación de visualización de ancho de banda de exportación de 22T y un papel como uno de los nodos centrales del backbone IDC de China Telecom. También dice que se mostraron a los estudiantes capacidades de refrigeración, distribución de energía, seguridad y la arquitectura de nube gubernamental provincial.

Eso es más fuerte que una página de producto vaga porque describe atributos físicos: racks, densidad de potencia, diseño de refrigeración, protección contra incendios, ancho de banda y un papel de campus. También coincide históricamente con un informe de 2015 de centros de datos Dynamics sobre labase de computación en la nube de Xi'an de China Telecom, que describió la apertura de una base de nube en la región occidental y señaló la estrategia regional más amplia de nodos de nube de China Telecom. Páginas secundarias y de socios, incluyendo ladescripción del nodo de Fenghuoyuny un artículo de 2018 deShaanxi Phoenixsobre los servicios de nube empresarial Tianyi, también ubican la base de nube Shaanxi en Fengxi New City del Área Nueva de Xixian y discuten capacidad IDC, nube y coubicación.

Esas descripciones públicas de las instalaciones ayudan, pero aún deben leerse como contexto a nivel de instalación, no como prueba específica del cliente. La página de la Universidad del Noroeste es un informe de visita al sitio, no un contrato de servicio. Las páginas de Fenghuoyun y Phoenix son descripciones de socios o estilo mediático, no auditorías neutrales. La capacidad de diseño no es lo mismo que la capacidad utilizable.

Un recuento de racks no es una declaración sobre disponibilidad de racks vacíos, margen de potencia, conmutadores de repuesto, inventario de hardware, ventanas de migración del cliente o la división actual entre servicios de nube, cargas de trabajo gubernamentales, acceso a Internet, línea arrendada y servicios de socios.

La conclusión más útil es la especificidad física con una advertencia. Los clientes deben asumir que existe un campus significativo de nube e IDC de China Telecom asociado con la historia de la base de nube Shaanxi. No deben asumir que cualquier servicio enrutado a través de AS134768 está físicamente en una sala nombrada, respaldado por todo el campus, o protegido por cada característica de redundancia descrita en una visita pública. Una base de nube puede alojar varios entornos lógicamente separados. Algunos pueden tener recuperación ante desastres en dos sitios. Algunos pueden ser de una sola zona. Algunos pueden ser racks de socios.

Algunos pueden ser zonas de nube pública. Algunos pueden ser coubicación de clientes.

Por lo tanto, el comprador debe solicitar la declaración de ubicación real: campus, edificio, clase de sala, mapeo de rack o zona de disponibilidad, diseño de alimentación eléctrica, clase de refrigeración, ruta de interconexión, alcance de la política de mantenimiento y si el servicio está en una plataforma compartida o un rack dedicado. La respuesta importa más que la escala total de la base.

La capacidad instalada no es capacidad utilizable

El material público de la base de nube enfatiza la escala, y la escala es útil. Un campus con miles de racks, opciones de gabinetes de alta densidad y una gran relación con el backbone de China Telecom puede absorber más demanda que un pequeño proveedor alojado en una oficina. También tiene más capas donde el servicio del cliente puede depender de las decisiones de asignación interna del operador.

La capacidad instalada es lo que se ha construido o se puede mostrar en un plan público. La capacidad utilizable es lo que la carga de trabajo del cliente puede consumir sin violar las restricciones de alimentación, refrigeración, almacenamiento, red o soporte. La capacidad recuperable es lo que permanece disponible después de una falla. Un recuento de racks dice poco sobre la segunda y tercera categorías. Si toda la capacidad de alta densidad sobrante está reservada para cargas de trabajo de nube gubernamental, un servidor alojado comercial puede no beneficiarse.

Si el grupo de almacenamiento de respaldo es grande pero el ancho de banda de restauración es estrecho, un cliente puede tener una copia de seguridad sin una ruta de recuperación. Si la base de nube tiene 22T de ancho de banda de exportación mostrado pero el nivel de producto del cliente tiene límite de velocidad o está conectado a una sola conexión dentro de un segmento de servicio, el ancho de banda titular no define el modo de falla del cliente.

La propia documentación pública de Tianyi Cloud refuerza esta visión en capas. Lapágina principal de Tianyi Cloudpresenta la marca en torno a la integración nube-red, seguridad, personalización dedicada y múltiples formas de nube, incluyendo servicios de nube pública, privada, dedicada, híbrida, de borde y de pila completa. Su documentación de ECS pararegiones y zonas de disponibilidadexplica una zona de disponibilidad como uno o más centros de datos físicos dentro de una región, con alimentación y red independientes, y dice que el objetivo es el aislamiento de fallas excepto para grandes desastres o fallas de alimentación mayores. Esa es una declaración de arquitectura sensata. También significa que el cliente tiene que saber si la carga de trabajo adquirida abarca realmente zonas, o si está simplemente en un grupo de recursos local.

Lo mismo ocurre con la capacidad de metal desnudo, VPS, coubicación y servicio gestionado. Un cliente que compra un armario desea alimentación sobrante, manos remotas, tiempo de entrega de interconexión, hardware de repuesto y ventanas de mantenimiento. Un cliente que compra máquinas virtuales desea tamaño del clúster de hipervisores, replicación de almacenamiento, aislamiento de instantáneas, exportación de imágenes y colocación en dominios de falla. Un cliente que compra nube del sector público desea cumplimiento normativo, ubicación de copias de seguridad, controles de identidad y recuperación ante desastres probada.

AS134768 puede transportar tráfico para todas esas superficies, pero cada una tiene una definición diferente de capacidad utilizable.

La prueba práctica es solicitar una declaración de capacidad bajo falla. ¿Cuánta computación, almacenamiento, ancho de banda y soporte quedan si falla un rack, un host, un conmutador, un estante de almacenamiento, una alimentación eléctrica o una ruta upstream? ¿Puede el grupo restante soportar la carga normal del cliente, o solo mantener en línea a los clientes prioritarios? ¿El cliente necesita comprar una segunda zona de disponibilidad o un producto de recuperación ante desastres separado para recibir esa protección? Sin esa respuesta, «base de nube» sigue siendo una etiqueta de instalación, no una garantía de resiliencia.

La alimentación, la refrigeración y las ventanas de reparación deciden la interrupción

Las páginas de los centros de datos a menudo presentan la alimentación y la refrigeración como orgullo de ingeniería. Los clientes deben leerlos como determinantes de interrupción. El informe de visita de la Universidad del Noroeste dice que la base Shaanxi tiene salas estándar T4, PUE bajo, opciones de rack de alta densidad y capacidades avanzadas de refrigeración y seguridad. La página de Fenghuoyun describe sistemas de alimentación de respaldo, servicios de estilo coubicación, conmutación central y afirmaciones de certificación de seguridad.

Un artículo de 2018 de Shaanxi Phoenix dice que la base tenía una gran capacidad de rack planificada y promovía niveles de servicio de continuidad de red y alimentación. Son señales públicas positivas, pero no un sustituto de los términos de servicio específicos del cliente.

La redundancia de alimentación tiene varias capas. Las alimentaciones de servicios públicos pueden ser diversas, pero el equipo de conmutación aún puede ser común. Los sistemas UPS pueden ser redundantes, pero la duración de la batería puede ser corta. Los generadores pueden estar disponibles, pero la logística de combustible, la confiabilidad de arranque del generador y el estado de mantenimiento deciden la resistencia real. Las PDU de rack pueden tener alimentaciones A y B, pero un cliente puede enchufar accidentalmente ambos suministros en un lado.

Un rack de alta densidad refrigerado por líquido puede ser potente, pero añade dependencias de refrigerante y soporte de instalación que no existen para servidores comunes de baja densidad.

La redundancia de refrigeración también tiene capas. Un PUE bajo es valioso, pero no es una métrica de tiempo de actividad. Dice algo sobre eficiencia y diseño. No dice si una fila determinada tiene suficiente margen de refrigeración después de que falla un enfriador, bomba o unidad de manejo de aire. No dice si los gabinetes refrigerados por líquido de alta densidad pueden seguir funcionando durante el mantenimiento. No le dice al cliente si un evento de degradación temporal forzará a mover las cargas de trabajo.

Las ventanas de reparación son donde el cliente ve la verdad. Una falla de rack puede requerir manos remotas. Una falla de servidor puede requerir piezas de repuesto. Una falla de enrutamiento puede necesitar un ingeniero autorizado para cambiar BGP. Una falla de almacenamiento puede requerir escalación al proveedor. Una falla de hipervisor puede requerir espacio de evacuación. Una falla de copia de seguridad puede requerir que alguien tome una decisión de restauración mientras el servicio principal está caído. El tamaño de China Telecom no elimina estos pasos; le da al operador más recursos para gestionarlos si el proceso está preparado.

El cliente debe preguntar por la ruta de incidentes en términos simples. ¿Quién abre el ticket interno? ¿Quién puede entrar a la sala? ¿Qué piezas están en stock en el sitio? ¿Qué cambios requieren una ventana de mantenimiento? ¿Cómo se notifica a los clientes si el mantenimiento planificado afecta a un borde de nube, alimentación eléctrica, plano de almacenamiento o ruta IP? ¿El SLA excluye el mantenimiento programado? ¿Qué servicios se acreditan y cuáles se apoyan solo con el mejor esfuerzo? Esos detalles son menos glamorosos que un recuento de racks, pero determinan si una falla se convierte en un evento corto o una larga migración.

Las señales de dominios alojados requieren un manejo cuidadoso

Los recuentos de dominios alojados de IPinfo hacen que AS134768 parezca una red de alojamiento, y eso es una evidencia de mercado útil. Reporta más de 23,000 dominios alojados en todo el ASN, con concentraciones en un pequeño conjunto de IPs. bgp.tools también etiqueta el tipo de red como contenido. El portafolio público de productos de Tianyi Cloud incluye hosts de nube elásticos, hosts de nube de aplicaciones, servicios de máquina física, almacenamiento, respaldo, recuperación ante desastres y otras ofertas de infraestructura.

Juntas, estas señales respaldan la premisa central: la red de base de nube es parte de una superficie de capacidad alojada orientada al cliente.

No prueban el servicio exacto detrás de un dominio alojado. Un dominio puede apuntar a alojamiento compartido, una plataforma de revendedor, un cortafuegos de aplicaciones, un proxy inverso, equipo del cliente en coubicación, un servidor heredado, una aplicación gubernamental interna, o un cliente empresarial que usa servicio IP estático. La concentración de direcciones IP no es lo mismo que la concentración de cuentas en la nube.

Un gran número de dominios en 103.236.90.151, por ejemplo, puede indicar alojamiento compartido o una dirección de plataforma, pero APNIC RDAP para la asignación subyacente 103.236.88.0/22 identifica a XIAOTEYUN como el nombre de recurso registrado. Eso hace que la cadena operativa sea más complicada que «China Telecom Shaanxi posee todos los sitios en la IP».

Esta distinción importa durante una falla. Si un cliente está en una IP de alojamiento compartido, un evento de abuso por otro inquilino puede afectar la reputación, la capacidad de entrega de correo o el filtrado. Si un cliente está en espacio de direcciones de socio enrutado, los contactos de origen de ruta y abuso pueden no coincidir claramente con el contrato. Si un cliente está en una nube privada virtual con una IP elástica, la migración puede requerir cambios de DNS y conmutación de extremo.

Si un cliente está en coubicación con un enrutador propiedad del cliente, el proveedor puede ser responsable de la alimentación y las interconexiones, pero no del sistema operativo o la aplicación del cliente.

El artículo trata, por lo tanto, los recuentos de dominios alojados como una señal de mercado no oficial, no como una prueba final de capacidad. Sugieren que AS134768 se utiliza para tráfico web y de infraestructura orientado al cliente. No pueden establecer quién posee los servidores, si las cargas de trabajo están respaldadas, si el inquilinato está aislado, si hay una ruta de restauración probada, o si el cliente puede exportar una imagen de VM, un volcado de base de datos, un archivo de buzón o una cuenta completa tipo cPanel durante una situación de estrés.

La evidencia concluyente sería la documentación del producto vinculada al servicio real: asignación de direcciones, diseño de aislamiento de inquilinos, alcance de respaldo y instantáneas, formatos de exportación, manejo de abusos, controles DDoS, control de DNS inverso, política de reputación de correo y soporte de migración. Sin esos detalles, la escala de dominios alojados es una razón para hacer mejores preguntas, no una razón para relajarse.

La localidad de los datos es un punto de venta y una restricción

El campo de región para este perfil es CN, y la evidencia pública respalda una superficie operativa basada en China. APNIC lista el AS en China. Los informes de la base de nube Shaanxi sitúan el campus físico en el área de Xi'an/Xixian. Las páginas de producto y los documentos de servicio de Tianyi Cloud están orientados a China. Esta presencia local puede ser valiosa para cargas de trabajo del sector público chino, reguladas y sensibles a la latencia. También puede limitar cómo un cliente diseña las copias de seguridad, el acceso de soporte y las rutas de salida.

El entorno legal de China hace que la colocación de datos sea más que una preferencia de adquisición. La traducción de la Ley de Ciberseguridad alojada porDigiChinadescribe un requisito de localización para información personal y datos importantes recopilados o producidos por operadores de infraestructura de información crítica en China continental. LaLey de Seguridad de Datosestablece un marco nacional de seguridad de datos. La Ley de Protección de Información Personal, resumida por elPCPDde Hong Kong y traducida por fuentes comoChina Law Translate, añade obligaciones de procesamiento de información personal y transferencia transfronteriza. Los deberes exactos dependen del cliente, tipo de datos y arreglo de servicio, pero la dirección es clara: las reglas de ubicación, acceso y transferencia importan.

Para los clientes de AS134768, la localidad tiene tres dimensiones prácticas. La primera es la localidad de producción: dónde se encuentran realmente los puntos finales de computación, almacenamiento y red. La segunda es la localidad de respaldo: dónde se almacenan las instantáneas, archivos, réplicas de recuperación ante desastres y registros. La tercera es la localidad administrativa: quién puede acceder a los sistemas, desde dónde, bajo qué entidad legal y proceso de soporte. Un servicio puede estar alojado localmente pero usar gestión remota, herramientas de seguridad externas o respaldo entre regiones.

Un servicio puede anunciar una base de nube Shaanxi pero proporcionar recuperación ante desastres en otra provincia. Eso puede ser una buena arquitectura, pero debe ser explícito.

La localidad de los datos también afecta la migración. Si un cliente necesita irse, ¿puede exportar datos a otro proveedor basado en China, otra región de China Telecom, un sistema local o una plataforma en el extranjero? ¿Hay límites legales, técnicos o contractuales para transferir registros, información personal, datos gubernamentales, claves de cifrado o copias de seguridad? ¿El proveedor admite exportación masiva sin limitación? ¿Cuánto tiempo después de la terminación conserva el cliente el acceso? ¿Qué sucede si la cuenta se suspende por facturación mientras el cliente aún necesita recuperación de datos?

La lectura más segura es que la infraestructura local en China es una característica cuando las necesidades de cumplimiento y latencia del cliente coinciden con la plataforma, y una restricción cuando el cliente necesita redundancia transfronteriza o salida rápida. La tabla de rutas de AS134768 no puede responder a esas preguntas. Solo los términos de servicio y el acuerdo de procesamiento de datos pueden hacerlo.

El contrato de servicio decide lo que la nube no cubre

Los clientes de nube a menudo confunden el lenguaje de disponibilidad con la responsabilidad operativa total. Elíndice SLAde Tianyi Cloud lista acuerdos de nivel de servicio en computación, almacenamiento, respaldo y productos de recuperación ante desastres. Supágina SLA de ECSdirige a los usuarios a los términos de nivel de servicio del host de nube elástico. Los documentos de producto de Tianyi Cloud también distinguen zonas de disponibilidad, tipos de instancia, servicios GPU, discos en la nube, productos de respaldo y productos de recuperación ante desastres. Esa estructura dice a los clientes algo importante: la resiliencia se ensambla a partir de servicios específicos, no se hereda automáticamente de la marca matriz.

En la práctica, un comprador debe esperar exclusiones. La mayoría de los SLA de nube excluyen el mantenimiento programado, fallas de configuración del lado del cliente, problemas de cuenta y pago, eventos de fuerza mayor y fallas fuera del límite de servicio definido por el proveedor. Algunos productos tienen créditos en lugar de garantías de restauración. Algunas instancias de alto rendimiento o especializadas pueden seguir un SLA diferente. Algunos productos de recuperación ante desastres protegen solo los datos o la configuración seleccionados por el cliente. Nada de esto es inusual.

Es por eso que leer el acuerdo específico del servicio es importante.

Para AS134768, el límite del contrato debe probarse contra las principales rutas de falla. Si falla la ruta upstream, ¿está cubierto por la disponibilidad de red o excluido como mantenimiento del backbone? Si un rack pierde alimentación, ¿el cliente recibe crédito de servicio, soporte de restauración, o ambos? Si una VM gestionada por el cliente está mal configurada después de la conmutación por error, ¿dónde termina la responsabilidad del proveedor? Si una acción de mitigación DDoS enruta nulo a una IP del cliente, ¿cuál es la ruta de escalación?

Si una carga de trabajo de nube gubernamental tiene controles de seguridad diferentes de la nube comercial, ¿qué equipo de soporte actúa?

La facturación y el estado de la cuenta merecen atención. La capacidad alojada puede fallar administrativamente. Una factura impaga, un retraso en la renovación del contrato, un problema de verificación de nombre real, un problema de registro de dominio, una queja por abuso o una discrepancia de identidad del cliente pueden suspender el servicio o bloquear la migración tan efectivamente como un enrutador roto.

Los clientes que compran capacidad crítica deben preguntar si una disputa de facturación puede afectar la exportación de datos, cuánto tiempo se retienen los datos después de la suspensión, y quién puede autorizar el acceso de emergencia.

El mejor contrato de nube hace visibles las dependencias invisibles. Establece el límite del servicio, la métrica de disponibilidad, el aviso de mantenimiento, la retención de datos, la responsabilidad de respaldo, el método de exportación, la gravedad del soporte, el objetivo de respuesta y las obligaciones del cliente. Si AS134768 es la superficie de ruta y Tianyi Cloud o una unidad de China Telecom Shaanxi es el proveedor de servicios, el cliente necesita tanto los datos de ruta como los datos del contrato en el mismo archivo.

Rutas de falla principales a probar

La primera ruta de falla es la falla del rack o de la instalación. Esto incluye alimentación del rack, refrigeración de la fila, errores de PDU, conmutadores de parte superior del rack, interconexiones, paneles de fibra, acceso físico y errores de mantenimiento. Los informes públicos de la base de nube sugieren una instalación sustancial, pero la escala de la instalación no elimina las fallas locales. Los clientes necesitan saber si su servicio es de un solo rack, una sola sala, un solo edificio, multizona o dos sitios.

La segunda ruta es la falla del upstream o del backbone. Las vistas públicas actuales muestran a AS4134 como el upstream visible. La política whois menciona AS4809, pero los recolectores de rutas no lo convierten en una ruta de conmutación por error probada para el cliente. Los clientes necesitan el mapa activo de upstream, la prueba de conmutación por error, los filtros de ruta, el estado RPKI y el comportamiento esperado si AS4134 tiene un problema regional o nacional.

La tercera ruta es la falla de existencias de hardware. Una plataforma alojada puede identificar un servidor fallido rápidamente y aún así esperar un reemplazo. La computación de GPU de alta densidad, refrigerada por líquido o especializada añade más riesgo de inventario. Un cliente debe preguntar qué piezas están en stock localmente, cuáles requieren envío del proveedor, y si el operador puede migrar en vivo o restaurar a hardware diferente mientras las piezas están en tránsito.

La cuarta ruta es la falla de soporte. La red de base de nube se encuentra dentro de una gran organización de operador, lo que puede ser una fortaleza si la escalación es madura. También puede crear riesgo de transferencia entre operaciones locales, operaciones de backbone, operaciones de nube, soporte al cliente, facturación, seguridad y equipos de socios. El cliente debe saber qué mesa de ayuda posee cada tipo de incidente y qué nivel de gravedad desencadena una escalación de 24 horas.

La quinta ruta es la falla de respaldo y restauración. Las copias de seguridad que existen pero son lentas, incompletas o controladas por la cuenta incorrecta no resuelven una interrupción. Los clientes deben exigir evidencia de restauración, no solo nombres de productos de respaldo. Para una VM, eso significa arrancar una imagen restaurada. Para una base de datos, eso significa consistencia y evidencia de punto de recuperación. Para almacenamiento de objetos, eso significa versionado, protección contra eliminación y separación de cuentas. Para coubicación, puede significar que el proveedor no respalda los datos del cliente en absoluto.

La sexta ruta es la falla de migración. Los clientes a menudo abandonan una plataforma durante momentos de estrés, cuando una aplicación es inestable o el negocio ha perdido confianza. Ese es el peor momento para descubrir que las direcciones IP no pueden moverse, las imágenes no pueden exportarse, las instantáneas son propietarias, el ancho de banda está limitado, o el soporte no ayudará hasta que se paguen las facturas. La migración debe ensayarse cuando el servicio está saludable.

Estas pruebas no requieren desconfianza. Son diligencia debida ordinaria para cualquier proveedor de capacidad alojada cuya evidencia de red pública sea más fuerte que su evidencia de límite de servicio público.

Qué elevaría el grado de evidencia

AS134768 obtiene un grado de evidencia de red Medio porque tiene un enrutamiento público sólido, identidad oficial de APNIC y un contexto plausible de nube física. Para alcanzar Fuerte, la evidencia pública o contractual necesitaría conectar la tabla de rutas con el servicio al cliente de manera más directa.

La primera mejora sería una declaración de topología actual. Debería nombrar el AS de origen activo, los ASN upstream, los prefijos de producto, la región y el mapeo de zonas de disponibilidad. Debería explicar si AS4809 está activo para el servicio o solo aparece en la política de ruta. Debería identificar si las cargas de trabajo del cliente utilizan espacio de China Telecom Shaanxi, espacio compartido de Tianyi Cloud, espacio PI del cliente o bloques de direcciones de socios. Debería indicar quién mantiene las ROA y quién responde a eventos de abuso o fuga de rutas.

La segunda mejora sería evidencia del límite de la instalación. Los clientes no necesitan un plano público, pero sí necesitan saber si su carga de trabajo se encuentra en la base de nube Xixian/Fengxi, otro centro de datos de Shaanxi, un grupo regional de Tianyi Cloud, un rack de socio o un armario propiedad del cliente. La declaración debería incluir la clase de alimentación, supuestos de densidad de rack, política de ventana de mantenimiento, plan de piezas de repuesto y si el servicio es de una sola zona o multizona.

La tercera mejora sería evidencia de recuperación. Un proveedor sólido puede mostrar simulacros de restauración, no solo productos de respaldo. Puede describir restauraciones recientes de VM, restauración de almacenamiento, restauración de base de datos, conmutación por error de red y pruebas de exportación de clientes. Puede decir qué fallas están cubiertas por conmutación por error automática y cuáles requieren un ticket manual. También puede establecer objetivos realistas de tiempo de recuperación y punto de recuperación por producto.

La cuarta mejora sería evidencia de localidad de datos y salida. El proveedor debería describir la ubicación de producción, ubicación de respaldo, ubicación de registros, acceso de subcontratistas, control de claves de cifrado, formatos de exportación, retención después de la terminación y restricciones de transferencia transfronteriza. Para cargas de trabajo gubernamentales o reguladas, debería distinguir el cumplimiento legal de la conveniencia comercial.

La quinta mejora sería evidencia de incidentes. Una página de estado, un resumen del historial de incidentes, un calendario de mantenimiento, una matriz de gravedad de soporte y una plantilla de informe posterior al incidente marcarían la diferencia entre una gran tabla de rutas y un servicio al cliente confiable. Los grandes operadores a veces mantienen esta información detrás de los portales de clientes, lo cual está bien para los clientes bajo contrato. La ausencia pública aún significa que un lector externo no debe asumirla.

Si esos elementos se producen, la historia cambia de «gran superficie enrutada de China Telecom Shaanxi en vivo con respaldo plausible de instalaciones de base de nube» a «plataforma de capacidad alojada verificada con dominios de falla y rutas de recuperación conocidos». Esa es la diferencia entre escala de red y confianza en la infraestructura.

La conclusión: rutas sólidas, resiliencia condicional

La red CHINANET SHAANXI provincia Cloud Base es un sujeto de infraestructura activo. APNIC, RIPEstat, bgp.tools, Hurricane Electric e IPinfo respaldan el mismo hecho central: AS134768 es una red activa de base de nube de China Telecom Shaanxi con una huella sustancial de IPv4 e IPv6. Las verificaciones de origen de ruta representativas son válidas. La visibilidad actual es alta. La red no es un caparazón inactivo.

La precaución operativa es igualmente clara. El BGP público muestra accesibilidad, no propiedad de racks. Los registros de direcciones de APNIC muestran titulares y contactos de recursos, no cargas de trabajo de clientes. Los recuentos de dominios alojados sugieren uso web y de alojamiento, no calidad de respaldo.

Los informes de visita a la base de nube y las páginas de socios apuntan a un centro de datos y campus de nube real en el área de Xi'an, pero no le dicen a un cliente qué producto es de una sola zona, cuál es multizona, qué ruta usa AS4809, qué rack tiene alimentación sobrante, o qué equipo de soporte restaura un servidor fallido a las 2 a.m.

Para un comprador, la postura práctica es una confianza disciplinada. Trate la red como viva. Trate el contexto de la base de nube China Telecom Shaanxi como significativo. Luego solicite la evidencia que realmente decide las interrupciones: prefijo de producto, zona de disponibilidad, ruta upstream, titularidad de ROA, alimentación del rack, margen de refrigeración, hardware de repuesto, alcance de respaldo, prueba de restauración, escalación de soporte, exclusiones de mantenimiento, reglas de continuidad de facturación y términos de exportación de datos.

La capacidad alojada no es ingrávida. En Shaanxi, como en cualquier otro lugar, son enrutadores, fibras, salas de alimentación, bucles de refrigeración, puertos de conmutación, colas de soporte y contratos. AS134768 hace visible esa capacidad para Internet. No elimina la necesidad de verificar la cadena física y operativa debajo de ella.