Resumen
- El RDAP de APNIC enumeraAS134768como
CHINANET-SHAANXI-CLOUD-BASE, con el nombre descriptivo CHINANET SHAANXI province Cloud Base network, país CN, registro en 2015 y un contacto de hostmaster de Chinanet. - La visibilidad de ruta actual es sólida. Lavista general de ASde RIPEstat informa que AS134768 está 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 de un padre. Losdatos whoisderivados de APNIC listan importaciones desde AS4134 y AS4809, pero las vistas públicas actuales de vecinos de RIPEstat,bgp.tools, lapágina BGPde Hurricane Electric eIPinfomuestran 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 de Shaanxi Chinanet, pero las vistas BGP públicas también muestran espacio enrutado descrito como IDC y servicio cloud, línea dedicada, 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 ni la ubicación del rack solo por el número de AS.
- Las señales de instalaciones públicas apuntan a una base de computación en la nube real en Xi'an/Xixian. Un informe de visita de la Universidad Northwest de 2025 describe la Base de Computación en la Nube de China Telecom Shaanxi como un gran centro de datos y nube 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 rol en las operaciones de nube del gobierno 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 propiedad de racks, alimentación eléctrica, conmutación por error del upstream, pruebas de restauración, límites de portabilidad de datos o escalamiento de soporte para clientes que compran capacidad alojada a través de esta red de base en la nube.
Una tabla de enrutamiento activa es solo la primera prueba
Un proveedor de capacidad alojada puede parecer fiable de dos maneras muy diferentes. Una prueba es la tabla de enrutamiento: 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 energía, el sistema de refrigeración tiene margen, los hipervisores tienen capacidad sobrante, la copia de seguridad se puede restaurar, el soporte técnico puede contactar al ingeniero adecuado y el cliente puede mover los datos al finalizar la relación.
La red CHINANET SHAANXI province Cloud Base tiene una primera prueba sólida y una segunda prueba pública más débil.
La identidad oficial es sencilla. El RDAP de APNIC paraAS134768nombra al ASCHINANET-SHAANXI-CLOUD-BASEy lo describe como CHINANET SHAANXI province Cloud Base network. El registro lo sitúa en China, muestra registro el 27 de octubre de 2015 y enumera 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 importando de AS4134 y AS4809 y exportando AS134768 a esas redes. Eso es suficiente para tratar la red como un sujeto de enrutamiento real de China Telecom Shaanxi, no un eslogan vago de nube.
El estado actual de las rutas 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 IPv6. Lavista de prefijos anunciadosde RIPEstat listó 125 entradas de prefijos actuales entre IPv4 e IPv6. Lapágina BGPde Hurricane Electric informó una escala similar, con 184.576 direcciones IPv4 originadas y ninguna ruta RPKI inválida originada en su vista actual. Esas no son señales de un ASN inactivo.
Pero una tabla de enrutamiento no muestra todo el servicio. No dice si una máquina virtual se está ejecutando en una sala propiedad de China Telecom, en un rack propiedad del cliente dentro de la sala, en un armario operado por un socio, en una región de Tianyi Cloud, en un pool de nube gubernamental, en un entorno de línea dedicada o en un acuerdo de colocació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 empresariales privados.
No le dice al comprador cuánto tarda en reemplazarse un servidor averiado 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 pública de BGP 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 "internet desapareció".
Es la falla más pequeña y difícil: un rack pierde una alimentación y la restante ya está cargada, un cambio de upstream expone una fuga de ruta, un pool de almacenamiento tiene copias de seguridad pero no una ruta de restauración rápida, 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 prueba el enrutamiento público
El enrutamiento público prueba que AS134768 es visible y lo suficientemente importante como para ser monitoreado. Lavista 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 colectores. La misma página de estado informa actividad vista por primera vez en enero de 2017 y un último elemento 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 meramente 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 de AS134768de Hurricane Electric informa 127 prefijos originados en total, 88 IPv4 y 39 IPv6, además de 11 pares BGP observados.IPinfodescribe el ASN como orientado a alojamiento, enumera China como país, muestra decenas de miles de dominios alojados en direcciones dentro del ASN y nombra a AS4134 como upstream en su resumen visible.
Hay diferencias en los contadores porque los colectores BGP públicos utilizan diferentes puntos de observación, elecciones 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 principal de China Telecom y una gran combinación de recursos IPv4 e IPv6.
La evidencia de origen de ruta también parece mejor que 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/23devolvió un estado válido para AS134768 en los resultados verificados. 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. Pero no debe, solo por eso, creer que su carga de trabajo alojada tiene protección multisitio, dos rutas de alimentación independientes, recuperación de copias de seguridad probada o fácil portabilidad de datos. BGP responde a la pregunta de alcanzabilidad. La capacidad alojada requiere varias otras respuestas.
La historia del upstream es más limitada de lo que sugiere la política de 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 troncales premium. Si ambas rutas estuvieran activas y transportaran cargas de trabajo de clientes de forma independiente, eso sería una diversidad útil. Las vistas de ruta pública no prueban esa lectura más fuerte.
Lavista de vecinos ASNde RIPEstat mostró 11 vecinos observados en la ventana revisada. El vecino del lado izquierdo era AS4134 con alta visibilidad en IPv4 e IPv6. Los vecinos del lado derecho eran un conjunto de redes 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ó de manera similar 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 gran operador puede mantener registros de política de enrutamiento que reflejen ingeniería interna, rutas planificadas o interconexión privada que los colectores públicos no exponen completamente. AS4809 aún puede importar 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 activa que afecte al cliente.
La prueba es evidencia actual y específica del producto: qué upstream transporta 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 principal 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 ruta BGP, diversidad de operador o troncal, 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 en la 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 comprando, ¿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 simplemente está disponible para el operador en otro lugar de la red?" Esa distinción evita que una red fuerte de China Telecom se venda en exceso como resiliencia total 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 de negocio. Muchos prefijos visibles son espacio de red sencillo de Shaanxi Chinanet. El RDAP de APNIC para36.41.64.0/20se resuelve en 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. El RDAP de APNIC para113.142.128.0/17se resuelve de manera similar en una asignación CHINANET-SN. Esos bloques respaldan el caso de que AS134768 transporta recursos de direcciones de China Telecom Shaanxi, a pesar de que algunas descripciones heredadas utilizan la ortografía "Shanxi(SN)" de maneras que pueden confundir Shaanxi con Shanxi. El contexto del contacto de Xi'an es el ancla práctica.
Otros recursos enrutados hacen que el límite operativo sea más complicado. bgp.tools enumera varios bloques del estilo 103.236.0.0/22 con descripciones de Sichuan Xiaoteyun Technology. El RDAP de APNIC para103.236.88.0/22identifica XIAOTEYUN como el nombre del recurso registrado y un contacto en Chengdu, Sichuan, mientras que lavista general de prefijode RIPEstat muestra AS134768 como el origen actual en la vista de ruta verificada. bgp.tools también muestra algunos prefijos con descripción de Baidu y Chinanet no Shaanxi bajo la página de AS134768. La presencia de esos recursos no es evidencia de irregularidad. 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íneas dedicadas, 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 decirle al comprador qué acuerdo operativo se aplica.
Un VPS que se ejecuta en la infraestructura de nube de China Telecom no es lo mismo que un enrutador de cliente cuyo prefijo es originado por AS134768, y ninguno de esos 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. Informa 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 respaldo, 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 debe 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, ¿la IP se mueve con la carga de trabajo o el cliente recibe nuevas direcciones? Esas preguntas convierten una gran tabla de enrutamiento en un mapa de dependencia real.
La etiqueta de base en la nube apunta a capacidad física
Las señales de instalaciones públicas 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 Northwest describe laBase de Computación en la Nube de China Telecom Shaanxicomo 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 datos y computación en la nube 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 de 5 kW, 8 kW, 12 kW y enfriados por líquido de mayor potencia, una afirmación de ancho de banda de exportación de 22T y un rol como uno de los nodos principales de la red troncal IDC de China Telecom. También dice que a los estudiantes se les mostró refrigeración, distribución de energía, capacidades de seguridad y la arquitectura de nube del gobierno provincial.
Eso es más sólido 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 rol en el campus. También se alinea históricamente con un informe de centros de datos Dynamics de 2015 sobre labase de computación en la nube de Xi'ande China Telecom, que describió la apertura de una base de nube de la región occidental y señaló la estrategia más amplia de nodos de nube regionales de China Telecom. Páginas secundarias y de socios, incluida ladescripción del nodo de Fenghuoyuny unartículo de Shaanxi Phoenixde 2018 sobre los servicios de nube de emprendimiento Tianyi, también ubican la base de nube de Shaanxi en el área de Fengxi New City del nuevo distrito de Xixian y discuten capacidad de IDC, nube y estilo de colocación.
Esas descripciones de instalaciones públicas ayudan, pero aún deben leerse como contexto a nivel de instalación en lugar de prueba específica del cliente. La página de la Universidad Northwest es un informe de visita al sitio, no un contrato de servicio. Las páginas de Fenghuoyun y Phoenix son descripciones de estilo socio o medios, 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 la disponibilidad de racks vacíos, margen de energía, conmutadores de repuesto, inventario de hardware, ventanas de migración de clientes o la división actual entre nube, cargas de trabajo gubernamentales, acceso a Internet, línea dedicada y servicios de socios.
La conclusión más útil es especificidad física con una advertencia. Los clientes deben asumir que hay un campus significativo de nube e IDC de China Telecom asociado con la historia de la base en la nube de Shaanxi. No deben asumir que cualquier servicio enrutado a través de AS134768 esté físicamente en una sala con nombre, respaldado por todo el campus o protegido por cada característica de redundancia descrita en un recorrido público. Una base en la nube puede alojar varios entornos lógicamente separados. Algunos pueden tener recuperación de desastres en dos sitios. Algunos pueden ser de zona única. Algunos pueden ser racks de socios.
Algunos pueden ser zonas de nube pública. Algunos pueden ser colocació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 conexión cruzada, alcance de la política de mantenimiento y si el servicio está en una plataforma compartida o en 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 sobre la base en la 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 troncal con China Telecom puede absorber más demanda que un proveedor alojado en una oficina pequeña. También tiene más capas donde el servicio del cliente puede depender de las elecciones 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 restricciones de energía, 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ía. Si toda la capacidad de alta densidad de repuesto está reservada para cargas de trabajo de nube gubernamental, un servidor alojado comercial puede no beneficiarse.
Si el pool 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 en la nube tiene 22T de ancho de banda de exportación mostrado pero el nivel de producto del cliente está limitado por velocidad o tiene un solo hogar dentro de un segmento de servicio, el ancho de banda principal 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 de inicio de Tianyi Cloudpresenta la marca en torno a la integración de nube y red, seguridad, personalización dedicada y múltiples formas de nube, incluidas nube pública, privada, dedicada, híbrida, de borde y de pila completa. Su documentación de ECS pararegiones y zonas de disponibilidadexplica que una zona de disponibilidad es uno o más centros de datos físicos dentro de una región, con energía y red independientes, y dice que el objetivo es el aislamiento de fallas, excepto grandes desastres o fallas de energía importantes. Esa es una declaración de arquitectura sensata. También significa que el cliente tiene que saber si la carga de trabajo comprada realmente abarca zonas, o si simplemente está en un pool de recursos local.
Lo mismo es cierto para la capacidad de servidor dedicado, VPS, colocación y servicio gestionado. Un cliente que compra un gabinete quiere energía de repuesto, manos remotas, tiempo de entrega de conexiones cruzadas, hardware de reemplazo y ventanas de mantenimiento. Un cliente que compra máquinas virtuales quiere tamaño de clúster de hipervisor, replicación de almacenamiento, aislamiento de instantáneas, exportación de imágenes y ubicación de dominio de falla. Un cliente que compra nube del sector público quiere cumplimiento de políticas, ubicación de copias de seguridad, controles de identidad y recuperación de 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 permanecen si falla un rack, host, conmutador, estante de almacenamiento, alimentación eléctrica o ruta upstream? ¿Puede el pool restante soportar la carga normal del cliente, o solo mantener a los clientes prioritarios en línea? ¿El cliente necesita comprar una segunda zona de disponibilidad o un producto de recuperación de desastres separado para recibir esa protección? Sin esa respuesta, "base en la nube" sigue siendo una etiqueta de instalación, no una garantía de resiliencia.
La energía, refrigeración y ventanas de reparación deciden la interrupción
Las páginas de centros de datos a menudo presentan la energía y la refrigeración como orgullo de ingeniería. Los clientes deben leerlas como determinantes de interrupción. El informe de visita de la Universidad Northwest dice que la base de Shaanxi tiene salas estándar T4, bajo PUE, opciones de rack de alta densidad y capacidades avanzadas de refrigeración y seguridad. La página de Fenghuoyun describe sistemas de energía de respaldo, servicios tipo colocación, conmutación central y afirmaciones de certificación de seguridad.
Un artículo de Shaanxi Phoenix de 2018 dice que la base tenía una gran capacidad de rack planificada y promovía niveles de servicio de continuidad de red y energía. Estas son señales públicas positivas, pero no un sustituto de los términos de servicio específicos del cliente.
La redundancia de energía tiene varias capas. Las alimentaciones de servicios públicos pueden ser diversas, pero el tablero de distribució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 fiabilidad 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 conectar accidentalmente ambos suministros a un lado.
Un rack de alta densidad refrigerado por líquido puede ser potente, pero agrega dependencias de refrigerante e instalaciones que no existen para servidores ordinarios 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 falle un enfriador, bomba o unidad de tratamiento de aire. No dice si los gabinetes de alta densidad refrigerados por líquido pueden seguir funcionando durante el mantenimiento. No le dice al cliente si un evento de reducción temporal obligará 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 escalamiento del proveedor. Una falla del 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 sencillos. ¿Quién abre el ticket interno? ¿Quién puede entrar a la sala? ¿Qué piezas se almacenan en el sitio? ¿Qué cambios requieren una ventana de mantenimiento? ¿Cómo se notifica a los clientes si el mantenimiento planificado afecta 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 simplemente se apoyan según 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 migración larga.
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. Informa más de 23.000 dominios alojados en todo el ASN, con concentraciones en un pequeño conjunto de IP. bgp.tools también etiqueta el tipo de red como contenido. La cartera de productos públicos de Tianyi Cloud incluye hosts de nube elástica, hosts de nube de aplicaciones, servicios de máquina física, almacenamiento, copia de seguridad, recuperación de desastres y otras ofertas de infraestructura.
En conjunto, estas señales respaldan la premisa central: la red de la base en la nube es parte de una superficie de capacidad alojada orientada al cliente.
No prueban el servicio exacto detrás de ningún dominio alojado. Un dominio puede apuntar a alojamiento compartido, una plataforma de revendedor, un firewall de aplicaciones, un proxy inverso, equipo de cliente en colocación, un servidor heredado, una aplicación gubernamental interna o un cliente empresarial que utiliza servicio de IP estática. La concentración de direcciones IP no es lo mismo que la concentración de cuentas de nube.
Una gran cantidad de dominios en 103.236.90.151, por ejemplo, puede indicar alojamiento compartido o una dirección de plataforma, pero el RDAP de APNIC para la asignación subyacente 103.236.88.0/22 identifica XIAOTEYUN como el nombre del recurso registrado. Eso hace que la cadena operativa sea más complicada que "China Telecom Shaanxi posee cada sitio 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 parte de otro inquilino puede afectar la reputación, la entregabilidad del correo o el filtrado. Si un cliente está en un espacio de direcciones de socio enrutado, el origen de la ruta y los contactos de abuso pueden no mapearse claramente al contrato. Si un cliente está en una nube privada virtual con una IP elástica, la migración puede requerir cambios de DNS y corte de punto final.
Si un cliente está en colocación con un enrutador propiedad del cliente, el proveedor puede ser responsable de la energía y las conexiones cruzadas, pero no del sistema operativo o la aplicación del cliente.
Por lo tanto, el artículo trata los recuentos de dominios alojados como una señal de mercado no oficial, no como una prueba de capacidad final. Sugieren que AS134768 se utiliza para tráfico web y de infraestructura orientado al cliente. No pueden establecer quién es el propietario de los servidores, si las cargas de trabajo tienen copias de seguridad, si la tenencia está aislada, 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 estilo cPanel durante una situación de estrés.
La evidencia definitiva sería documentación del producto vinculada al servicio real: asignación de direcciones, diseño de aislamiento de inquilinos, alcance de copias de seguridad e 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 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 enumera el AS en China. Los informes de la base en la nube de Shaanxi sitúan el campus físico en el área de Xi'an/Xixian. Las páginas de productos y documentos de servicio de Tianyi Cloud están orientadas 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 copias de seguridad, acceso de soporte y rutas de salida.
El entorno legal de China hace que la ubicació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 laPCPDde Hong Kong y traducida por fuentes comoChina Law Translate, agrega obligaciones de procesamiento de información personal y transferencia transfronteriza. Los deberes exactos dependen del cliente, tipo de datos y acuerdo 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 copias de seguridad: dónde se almacenan las instantáneas, archivos, réplicas de recuperación de 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 utilizar gestión remota, herramientas de seguridad externas o copia de seguridad entre regiones.
Un servicio puede anunciar una base en la nube de Shaanxi pero proporcionar recuperación de desastres en otra provincia. Eso puede ser buena arquitectura, pero debe ser explícito.
La localidad de 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? ¿Existen 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 la 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 recuperar datos?
La lectura más segura es que la infraestructura local de 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 enrutamiento de AS134768 no puede responder a esas preguntas. Solo los términos del servicio y el acuerdo de procesamiento de datos pueden hacerlo.
El contrato de servicio decide lo que la nube no cubre
Los clientes de la nube a menudo confunden el lenguaje de disponibilidad con la responsabilidad operativa total. Elíndice de SLAde Tianyi Cloud enumera acuerdos de nivel de servicio en productos de computación, almacenamiento, copia de seguridad y recuperación de desastres. Supágina de SLA de ECSdirige a los usuarios a los términos de nivel de servicio del host de nube elástica. Los documentos de productos de Tianyi Cloud también distinguen zonas de disponibilidad, tipos de instancia, servicios GPU, discos de nube, productos de copia de seguridad y productos de recuperación de desastres. Esa estructura le dice a los clientes algo importante: la resiliencia se ensambla a partir de servicios específicos, no se hereda automáticamente de la marca principal.
En la práctica, un comprador debe esperar exclusiones. La mayoría de los SLA de nube excluyen el mantenimiento programado, fallos de configuración del lado del cliente, problemas de cuenta y pago, eventos de fuerza mayor y fallos 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 de desastres protegen solo los datos o la configuración seleccionada 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 la ruta upstream falla, ¿está cubierta por la disponibilidad de red o se excluye como mantenimiento de la red troncal? Si un rack pierde energía, ¿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 de DDoS anula la ruta de una IP del cliente, ¿cuál es la ruta de escalamiento?
Si una carga de trabajo de nube gubernamental tiene controles de seguridad diferentes a los 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 presentación de dominio, una queja de abuso o una falta de coincidencia 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 la copia de seguridad, 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 hechos de ruta como los hechos del contrato en el mismo archivo.
Principales rutas de falla a probar
La primera ruta de falla es la falla del rack o la instalación. Esto incluye energía del rack, refrigeración de fila, errores de PDU, conmutadores de la parte superior del rack, conexiones cruzadas, paneles de fibra, acceso físico y errores de mantenimiento. Los informes públicos de la base en la nube sugieren una instalación sustancial, pero la escala de la instalación no elimina la falla local. 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 de la red troncal. Las vistas públicas actuales muestran AS4134 como el upstream visible. La política whois menciona AS4809, pero los colectores de rutas no lo convierten en una ruta de conmutación por error probada para el cliente. Los clientes necesitan el mapa de upstream activo, 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 del stock de hardware. Una plataforma alojada puede identificar un servidor averiado rápidamente y aún esperar un reemplazo. Las GPU de alta densidad, refrigeradas por líquido o computación especializada agregan más riesgo de inventario. Un cliente debe preguntar qué piezas se almacenan localmente, cuáles requieren envío del proveedor y si el operador puede migrar en vivo o restaurar a un hardware diferente mientras las piezas están en tránsito.
La cuarta ruta es la falla del soporte. La red de la base en la nube se encuentra dentro de una gran organización de operador, lo que puede ser una fortaleza si el escalamiento es maduro. También puede crear riesgo de traspaso entre operaciones locales, operaciones de red troncal, operaciones de nube, soporte al cliente, facturación, seguridad y equipos de socios. El cliente debe saber qué mesa es propietaria de cada tipo de incidente y qué nivel de gravedad desencadena un escalamiento las 24 horas.
La quinta ruta es la falla de copia de seguridad 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 copia de seguridad. 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 el almacenamiento de objetos, eso significa versionado, protección contra eliminación y separación de cuentas.
Para la colocació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 una situación de estrés, cuando una aplicación es inestable o la empresa ha perdido la confianza. Ese es el peor momento para descubrir que las direcciones IP no se pueden mover, las imágenes no se pueden exportar, las instantáneas son propietarias, el ancho de banda está limitado o el soporte no ayudará hasta que se liquiden las facturas. La migración debe ensayarse cuando el servicio está saludable.
Estas pruebas no requieren desconfianza. Son debida diligencia ordinaria para cualquier proveedor de capacidad alojada cuya evidencia de red pública sea más sólida que su evidencia pública de límite de servicio.
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 APNIC oficial y un contexto plausible de nube física. Para alcanzar Fuerte, la evidencia pública o contractual necesitaría conectar la tabla de enrutamiento con el servicio al cliente de manera más directa.
La primera mejora sería una declaración de topología actual. Debe nombrar el AS de origen activo, los ASN upstream, los prefijos del producto, la región y el mapeo de zonas de disponibilidad. Debe explicar si AS4809 está activo para el servicio o solo aparece en la política de enrutamiento. Debe identificar si las cargas de trabajo de los clientes utilizan espacio de China Telecom Shaanxi, espacio compartido de Tianyi Cloud, espacio PI del cliente o bloques de direcciones de socios. Debe indicar quién mantiene las ROA y quién responde a eventos de abuso o fuga de rutas.
La segunda mejora sería la evidencia del límite de la instalación. Los clientes no necesitan un plano de planta público, pero sí necesitan saber si su carga de trabajo se encuentra en la base en la nube de Xixian/Fengxi, otro centro de datos de Shaanxi, un pool regional de Tianyi Cloud, un rack de socio o un gabinete propiedad del cliente. La declaración debe incluir clase de energía, suposiciones de densidad de rack, política de ventana de mantenimiento, plan de piezas de repuesto y si el servicio es de zona única o multizona.
La tercera mejora sería la evidencia de recuperación. Un proveedor sólido puede mostrar simulacros de restauración, no solo productos de copia de seguridad. Puede describir pruebas recientes de restauración de VM, restauración de almacenamiento, restauración de base de datos, conmutación por error de red y exportación de clientes. Puede decir qué fallas están cubiertas por la conmutación por error automatizada y cuáles requieren un ticket manual. También puede indicar objetivos realistas de tiempo de recuperación y punto de recuperación por producto.
La cuarta mejora sería la evidencia de localidad de datos y salida. El proveedor debe describir la ubicación de producción, ubicación de copias de seguridad, 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, debe distinguir el cumplimiento normativo de la conveniencia comercial.
La quinta mejora sería la evidencia de incidentes. Una página de estado, resumen del historial de incidentes, calendario de mantenimiento, matriz de gravedad de soporte y plantilla de informe posterior al incidente marcarían la diferencia entre una gran tabla de enrutamiento y un servicio al cliente confiable. Los grandes operadores a veces mantienen esta información detrás de portales de clientes, lo cual está bien para clientes bajo contrato. La ausencia pública aún significa que un lector externo no debe asumirlo.
Si se producen esos elementos, la historia cambia de "gran superficie enrutada activa de China Telecom Shaanxi con respaldo plausible de instalación de base en la 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 province Cloud Base es un sujeto de infraestructura activa. APNIC, RIPEstat, bgp.tools, Hurricane Electric e IPinfo respaldan el mismo hecho central: AS134768 es una red activa de China Telecom Shaanxi de base en la nube con una huella sustancial IPv4 e IPv6. Las verificaciones representativas de origen de ruta 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 alcanzabilidad, no propiedad del rack. Los registros de direcciones de APNIC muestran titulares de recursos y contactos, no cargas de trabajo de clientes. Los recuentos de dominios alojados sugieren uso web y de alojamiento, no calidad de copia de seguridad.
Los informes de visita a la base en la nube y las páginas de socios apuntan a un centro de datos y campus de nube reales en el área de Xi'an, pero no le dicen a un cliente qué producto es de zona única, cuál es multizona, qué ruta usa AS4809, qué rack tiene energía de repuesto o qué equipo de soporte restaura un servidor averiado a las 2 a.m.
Para un comprador, la postura práctica es confianza disciplinada. Trate la red como activa. Trate el contexto de la base en la nube de China Telecom Shaanxi como significativo. Luego pregunte por la evidencia que realmente decide las interrupciones: prefijo del producto, zona de disponibilidad, ruta upstream, propiedad de ROA, energía del rack, margen de refrigeración, hardware de repuesto, alcance de copia de seguridad, prueba de restauración, escalamiento 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 otros lugares, son enrutadores, fibras, salas de energía, bucles de refrigeración, puertos de conmutador, colas de soporte y contratos. AS134768 hace que esa capacidad sea visible para Internet. No elimina la necesidad de verificar la cadena física y operativa debajo de ella.