Resumen

  • AFRINIC registra AS328032 como un objeto de sistema autónomo activo cuyo titular es Routed Hosting (PTY) LTD. PeeringDB y NAPAfrica publican el contexto de interconexión declarado del ASN. Estas fichas establecen identidad y puntos de coordinación; no prueban una carga cloud ni un plan de recuperación.
  • Routed describe servicios de copia y recuperación que utilizan zonas de disponibilidad en Johannesburgo y Ciudad del Cabo. El cliente aún necesita evidencia fechada de replicación, RPO, RTO, separación de dependencias, capacidad, ejercicios, conmutación y retorno.

Empezar por el objeto que describe cada registro

La entrada de Routed Hosting en el directorio de BTW identifica el objeto empresarial seleccionado para este análisis. Sirve para no confundir una compañía con un producto, un número de enrutamiento o una organización de nombre parecido. La página no muestra por sí sola AS328032, de modo que la relación con el ASN debe provenir de un registro independiente de recursos numéricos y no de una inferencia basada en la etiqueta.

El registro RDAP de AFRINIC para AS328032 describe un recurso de numeración. Un sistema autónomo es una red o conjunto de redes que presenta una política de enrutamiento común ante el resto de internet. Su número, el ASN, proporciona una identidad única cuando otras redes intercambian rutas mediante BGP.

AFRINIC identifica el objeto como AS328032, nombra a Routed Hosting (PTY) LTD como organización registrante bajo el identificador ORG-RHL1-AFRINIC y marca el objeto como active. La ficha registra un evento de alta en junio de 2016 y un último cambio en enero de 2023. Estos campos responden a una pregunta concreta: ¿a qué organización asocia el registro este número de enrutamiento?

Active no es una luz verde para todos los routers, almacenamientos, trabajos de réplica o servicios de recuperación. RDAP no mide pérdida de paquetes, antigüedad de copias, capacidad de contingencia ni resultados de pruebas. El registro cumple su función cuando mantiene una identidad única, un titular y contactos trazables. No es un sistema de monitorización para equipos y aplicaciones que no opera.

Los directorios de intercambio aportan contexto, no la ruta del cliente

El registro de red de PeeringDB asocia Routed Hosting con AS328032 y el conjunto AS-ROUTEDHOSTING. Declara una política general de peering abierta y compatibilidad con IPv4 e IPv6. Los registros públicos de conexión a intercambios sitúan el ASN en CINX, JINX y en instalaciones NAPAfrica de Ciudad del Cabo y Johannesburgo.

El directorio de participantes de NAPAfrica añade la perspectiva del operador del intercambio. Incluye a Routed Hosting y ASN 328032 en Johannesburgo y Ciudad del Cabo, con participación en servidores de rutas y en ambas familias de protocolo. Un punto de intercambio es un entorno compartido donde varias redes intercambian tráfico. Un servidor de rutas facilita el intercambio de información BGP sin exigir una sesión bilateral distinta entre cada pareja de participantes.

Estas fichas hacen visible la superficie pública de interconexión. Un ingeniero puede saber qué ASN usar en una conversación sobre rutas y dónde se declaran relaciones de intercambio. Un comprador puede plantear preguntas más precisas sobre política de enrutamiento, proveedores de tránsito e intercambio local.

Sin embargo, no muestran el trayecto de una carga de trabajo identificada. Operational en PeeringDB es el estado declarado de una ficha mantenida por el participante, no una medición continua de paquetes. Una cifra de 10G describe una conexión declarada, no el margen libre en el momento en que varios clientes necesiten recuperar. Dos ubicaciones lógicas tampoco prueban independencia de fibra, energía, edificio, plano de gestión o proveedores de tránsito. Diversidad lógica y separación física están relacionadas, pero no son equivalentes.

Durante un incidente, ver AS328032 en una ruta puede ayudar a localizar el dominio con el que coordinar. Por sí solo, no determina si el origen del problema está en las instalaciones del cliente, la plataforma cloud, el DNS, una ruta ascendente o la aplicación. El ASN acota una frontera de coordinación; no diagnostica todas las capas a ambos lados de esa frontera.

Las páginas de producto explican una intención de servicio

El sitio de Routed presenta servicios de nube privada, copia desde entornos del cliente y recuperación entre esos entornos y la nube, o entre zonas de disponibilidad. En una explicación de su servicio de recuperación, la empresa describe topologías desde instalaciones a nube y entre nubes que utilizan Johannesburgo y Ciudad del Cabo.

Routed menciona VMware Cloud Director Availability y Veeam Cloud Connect Replication. Describe replicación, planes e informes de recuperación, pruebas de failover y failback. El failover es el traslado controlado de la carga al entorno de recuperación cuando el entorno principal no puede ejecutarla. El failback la devuelve al entorno principal cuando vuelve a estar preparado.

Un artículo de VMware de 2022 también describió el uso que Routed hacía entonces de Cloud Director, la integración con Veeam y Cloud Director Availability para copia y DRaaS. El texto del socio ayuda a establecer la historia de la arquitectura publicada. Su fecha importa: no certifica una versión actual, una acreditación vigente ni el resultado presente de un cliente.

Estas fuentes explican mecanismos y propósito. Son un comienzo razonable para una conversación de compra, pero no sustituyen el alcance y la evidencia operativa del cliente. Un servicio puede estar disponible y una carga quedar fuera de la política de réplica. Puede existir una copia mientras identidad, DNS, claves de cifrado o una base de datos dependiente siguen inaccesibles. El éxito de una prueba para una aplicación no demuestra otra.

La recuperación es una afirmación sobre una carga concreta

La evidencia fuerte de continuidad está unida a una carga definida, un fallo definido y una fecha. El RPO, objetivo de punto de recuperación, expresa la máxima pérdida aceptable de datos medida en tiempo. El RTO, objetivo de tiempo de recuperación, expresa el plazo previsto para restaurar el servicio. Ni el ASN, ni una afiliación a un intercambio, ni el nombre de un producto de réplica prueban que un cliente específico vaya a cumplirlos.

El comprador puede pedir una cadena de evidencia compacta:

  1. Inventario protegido. ¿Qué máquinas virtuales, bases, almacenes, identidades, zonas DNS, claves y políticas de red están dentro del alcance? ¿Qué queda fuera?
  2. Estado de réplica. ¿Cuándo replicó cada componente por última vez con éxito? ¿Qué alertas detectan retraso, fallo o una copia que no puede arrancar?
  3. Objetivos de recuperación. ¿Qué RPO y RTO se aplican a la carga y a qué fallos? ¿Dónde figuran en el contrato?
  4. Separación de dependencias. ¿Qué edificios, alimentación, fibras, redes de tránsito, planos de gestión o personas comparten los entornos principal y de recuperación?
  5. Capacidad de contingencia. ¿Qué cómputo, almacenamiento, red y licencias están reservados o disponibles tras un fallo? ¿Funciona el diseño si varios clientes invocan la recuperación a la vez?
  6. Evidencia de prueba. ¿Cuándo se ejecutó el último ejercicio de extremo a extremo? ¿Pudieron los usuarios acceder a la aplicación, cuadraron los datos, funcionaron los servicios de identidad y las claves, y cuánto duró cada etapa?
  7. Evidencia de retorno. ¿Cómo vuelven al principal los cambios realizados durante la recuperación sin perder datos ni provocar una segunda interrupción?

No hace falta revelar información confidencial de otro cliente. Un informe de prueba delimitado, un diagrama sin detalles sensibles, un resumen de controles y un contrato con responsabilidades por cada relevo pueden aportar evidencia auditable. Lo decisivo es que proceda del servicio en ejecución y de la configuración actual, no de una palabra tomada de otra capa.

Un fallo hipotético muestra el límite

Imaginemos a un minorista cuyo sistema de pedidos funciona en una nube privada y se replica a un segundo sitio. Es un ejemplo explicativo, no una afirmación sobre un cliente conocido de Routed.

Si el sitio principal deja de estar disponible, AS328032 puede ayudar a una red externa a identificar el dominio de enrutamiento implicado. Los directorios de intercambio pueden mostrar dónde se declara la interconexión pública. Si la alcanzabilidad forma parte del problema, estos datos pueden acelerar la coordinación.

La aplicación solo se recuperará si funciona el resto de la cadena: réplica reciente y consistente, capacidad suficiente, identidad y claves disponibles, DNS o gestión de tráfico dirigidos al entorno recuperado, una persona autorizada para decidir, una base de datos que no produzca dos versiones rivales y un retorno seguro posterior.

Si una prueba recupera el servicio en cuarenta minutos frente a un RTO de una hora, eso es evidencia para esa prueba y ese alcance. No es una garantía permanente sobre futuros incidentes. Si falta una clave y el ejercicio falla, el ASN no se vuelve inexacto; aparece una brecha en otra capa.

Leer con cuidado las palabras de estado

Active puede describir un objeto de registro, operational una conexión declarada, available un producto y resilient una intención de diseño. Recovered debería describir un resultado observado para un servicio y unas condiciones definidos.

Fundir todos esos términos en un único “funciona” acorta la revisión pero debilita la conclusión. Una lectura rigurosa dice que AFRINIC registra la identidad del recurso, PeeringDB y NAPAfrica aportan contexto de interconexión declarado, Routed y VMware describen arquitectura y mecanismos, y una prueba fechada establece qué se recuperó realmente.

Cada capa sigue siendo útil. Los registros exactos reducen errores de identidad y facilitan la coordinación. La documentación de producto fija expectativas. El contrato reparte responsabilidades. Los sistemas en ejecución y los ejercicios determinan si todo ello funciona para la carga evaluada.

Preguntas para el comprador

Conviene confirmar si AS328032 es el ASN esperado para originar o transportar el tráfico público del servicio y si intervienen otras identidades de red. También hay que preguntar qué intercambios o proveedores ascendentes son relevantes para el contrato, sin suponer que toda ficha pública está en la ruta del cliente. Por último, se debe identificar dónde reside la copia y qué dependencias comparte aún con el entorno principal.

El último ejercicio debería mostrar el fallo inyectado, el estado inicial, RPO y RTO medidos, validación del usuario, conciliación de datos y resultado del failback. Cada acción debe tener dueño: proveedor, revendedor, cliente o socio de software. Una capacidad que existe, pero carece de responsable durante un incidente, todavía no es un plan operativo.

Qué vigilar

  • Cambios en el titular, estado o historial de AS328032 en AFRINIC.
  • Altas, bajas o cambios de ubicación, protocolo o servidor de rutas en PeeringDB o el operador del intercambio.
  • Actualizaciones de Routed sobre zonas, plataforma, copia o recuperación.
  • Ejercicios de recuperación fechados, de clientes o independientes, que publiquen alcance y resultados medidos.
  • Cambios contractuales que aclaren objetivos, capacidad, dependencias y responsabilidades de failover y failback.

Cada señal debe conservar la fecha de observación. La identidad puede durar mientras rutas, servicios y dependencias cambian. Una intención de diseño nunca sustituye una prueba terminada.

Fuentes

AS328032 aporta al dominio de enrutamiento de Routed Hosting una identidad pública única y un punto de coordinación. Los registros de intercambio añaden el contexto de interconexión declarado. Las páginas de Routed describen un servicio de recuperación y los mecanismos previstos. Decidir si una carga se recuperará sigue dependiendo de evidencia fechada sobre esa carga, sus dependencias y un ejercicio completo. Cuando el registro público llega a su límite, la conclusión correcta no es que la recuperación haya fallado ni que esté garantizada: aún debe demostrarse para ese alcance.

Un plan de seguimiento que mantenga separadas las capas

La supervisión profesional debería mantener cuatro relojes. El primero sigue la identidad: objeto AFRINIC, titular e historial de mantenimiento. El segundo sigue la interconexión declarada: altas, bajas y cambios relevantes en PeeringDB y los directorios de intercambio. El tercero sigue el diseño del servicio: plataforma, zonas y responsabilidades que publican Routed o sus socios. El cuarto sigue la prueba operativa: fecha y resultado del último ejercicio de la carga protegida.

Cada reloj requiere un disparador distinto. Un cambio registral inesperado exige reconciliar la identidad. La desaparición de una ficha de intercambio exige revisar rutas y camino de servicio, no declarar automáticamente una caída. Un cambio de plataforma exige revisar compatibilidad y manuales de recuperación. Un ejercicio atrasado o fallido exige corregir la capa de carga de trabajo.

El registro de seguimiento debe conservar fecha y tipo de afirmación. Así se distingue una actualización de directorio de una observación de rutas, un anuncio del proveedor de un resultado probado y se evita que un artículo antiguo de un socio se convierta silenciosamente en evidencia de la configuración actual.

Para compras, el disparador práctico es la distancia entre promesa y prueba. Si el contrato fija un RTO de una hora, pero falta el último ejercicio integral, está incompleto o es más antiguo que el intervalo acordado, la siguiente acción es una prueba con alcance definido. Si el ejercicio tuvo éxito, pero cambiaron la carga o sus dependencias, el resultado no se extiende al nuevo alcance sin revisión.

Para redes, un cambio de ASN o de intercambio debe actualizar el mapa de escalado y las observaciones esperadas. Para propietarios de aplicaciones, debe provocar una revisión de alcanzabilidad pública, DNS y certificados en el plan de recuperación. Ningún equipo debería dar por probado el trabajo de la otra capa.

La decisión de control es quién posee la afirmación de recuperación

Los fallos de continuidad suelen comenzar como fallos de responsabilidad. El proveedor cloud puede operar la plataforma, un revendedor gestionar la relación comercial, el cliente controlar la réplica de la aplicación y otro equipo conservar DNS, identidad o claves. Todos pueden describir correctamente su componente y, aun así, dejar sin demostrar el servicio de extremo a extremo.

La dirección debe asignar un responsable a la afirmación completa de recuperación y darle capacidad para reunir evidencia a través de fronteras organizativas. Debe poder programar pruebas, revelar brechas, reservar capacidad y detener una migración cuando las dependencias no son recuperables. Sin esa autoridad, el plan puede convertirse en documentos que parecen compatibles, pero cuyo resultado no pertenece a nadie.

Los incentivos también son distintos. El material comercial premia afirmaciones amplias. Los registros y directorios premian datos exactos y reutilizables. Operaciones premia estabilidad y cambio controlado. Una gobernanza útil no obliga a una pieza a cumplir las tres funciones: deja que el registro establezca identidad, el contrato asigne responsabilidad y la prueba demuestre rendimiento.

Algunas decisiones se vuelven caras de revertir. Una carga acumula dependencias propietarias, la identidad queda solo en el sitio principal o la recuperación depende de capacidad no reservada. Estos riesgos deben aparecer antes de la migración, cuando todavía se pueden cambiar arquitectura y contrato. Esperar al primer incidente convierte una elección de diseño en una restricción urgente.

La pregunta decisiva no es si AS328032 existe ni si Routed ofrece recuperación ante desastres. Las fuentes públicas sostienen ambas afirmaciones dentro de sus límites. La pregunta de dirección es si la carga exacta, ante el escenario acordado, tiene un propietario identificado y un resultado reciente que demuestre recuperación y retorno seguro. Ahí es donde registros, contratos y sistemas en ejecución se convierten en una decisión de continuidad responsable.