Resumen

  • RIPE NCC incluye a OVH US LLC como miembro bajo Estados Unidos. La ficha ofrece una identidad administrativa dentro de un sistema regional de recursos numéricos, pero no atribuye por sí sola a la empresa un prefijo, ASN, ruta, centro, cliente, servicio cloud o resultado operativo concreto.
  • OVHcloud describe públicamente un servicio BYOIP para incorporar IPv4 elegibles, mantener la responsabilidad sobre las direcciones y su reputación, y elegir un AS de OVHcloud o del cliente como origen. Esa documentación explica una capacidad de marca; no demuestra qué entidad jurídica contrata u opera cada despliegue regional.
  • Hay cuatro capas distintas: el registro regional conserva la relación administrativa; un ROA autoriza a un AS a originar un prefijo; un objeto de ruta IRR expresa intención de enrutamiento; y BGP muestra anuncios que realmente circulan. Ninguna capa sustituye a las demás.
  • RPKI puede clasificar un anuncio como válido, inválido o desconocido. Comprueba la relación entre prefijo, longitud y origen, pero no valida toda la ruta, la unión con el servicio cloud, el estado de la aplicación ni la identidad comercial.
  • La salida se diseña antes de entrar. El plan debe nombrar propietarios de RIR, ROA e IRR; definir origen normal, transición y retorno; revisar DNS y dependencias de seguridad; mantener un solapamiento controlado; observar externamente la nueva ruta; y retirar la antigua solo después de esa prueba.

La imagen destacada es una escena editorial fotorrealista original de una persona no identificada ensayando un cambio de ruta entre dos equipos sin marca. No representa a OVH US LLC, OVHcloud, RIPE NCC, ARIN, personal, clientes, oficinas, instalaciones, redes, bloques, incidentes, caídas, debilidades ni avales reales.

La dirección conocida puede esconder una ruta nueva

Pensemos en una distribuidora regional con un portal, una API para transportistas y un sistema de correo. Algunos clientes han permitido su rango IPv4 en el firewall. La misma dirección aparece en reglas antifraude, monitores y documentación antigua. Renumerar todo costaría meses, así que la empresa elige BYOIP.

El proyecto parece sencillo. El público mantiene las mismas direcciones. Los socios no cambian sus listas. El equipo de correo espera conservar la reputación acumulada. La dirección escucha que el bloque seguirá perteneciendo a la empresa y que podrá llevárselo cuando cambie de proveedor.

La dificultad llega en la salida. El nuevo proveedor debe anunciar desde otro sistema autónomo. Un ROA aún autoriza al origen anterior. Un objeto IRR conserva un ASN antiguo. La longitud máxima no cubre el prefijo más específico que se intenta anunciar. Si el proveedor viejo retira la ruta antes de que la nueva sea válida y visible, el derecho administrativo sobre el bloque no entrega tráfico.

El ejemplo es genérico, no un incidente de OVHcloud. Sirve para separar la permanencia del número de la continuidad del servicio. La IP puede ser la misma mientras cambian la autorización, los filtros, los routers, las cuentas y la aplicación. Una migración concluye cuando esas capas coinciden y el camino anterior todavía puede restaurarse.

El alcance exacto de la ficha OVH US LLC

El directorio de BTW enlaza este artículo con OVH US LLC. El listado público de miembros de RIPE NCC coloca a OVH US LLC bajo Estados Unidos y aporta contexto administrativo. La utilidad de la ficha es fijar un nombre concreto dentro de un sistema público de coordinación.

No es un mapa de la red. Para este artículo no identifica un ASN, prefijo, ruta, campus o cliente. No demuestra disponibilidad, rendimiento, soporte ni el resultado de una mudanza. La membresía registra una relación; no muestra el estado instantáneo de BGP.

Este límite importa cuando se usa una marca internacional. OVHcloud publica páginas globales y regionales, pero contratos, sociedades, instalaciones y responsabilidades pueden variar. El texto no trata OVH US LLC, OVH SAS y todas las compañías bajo la marca como si fueran una sola persona jurídica.

Por eso la ficha RIPE sirve como ancla administrativa, las páginas OVHcloud describen el servicio publicado por la marca y las fuentes de RIPE NCC, ARIN e IETF explican registros y protocolos. Cada afirmación se mantiene dentro de la prueba correspondiente.

La misma disciplina hace falta en operaciones. La marca contratada, el titular del recurso, el ASN de origen, la cuenta cloud y el equipo que modifica routers pueden estar relacionados sin ser idénticos. Ante una incidencia, el nombre familiar no sustituye saber quién puede firmar, anunciar, retirar y restaurar.

BYOIP explicado para quien no opera BGP

Un prefijo IP es un bloque de direcciones. Un sistema autónomo, o AS, es una red que presenta una política de enrutamiento coherente a otras redes. Su número, el ASN, la identifica. BGP es el mecanismo mediante el cual las redes anuncian cómo llegar a los prefijos.

En un servicio cloud normal, el cliente suele usar direcciones del proveedor. Cuando se marcha, debe renumerar. Con BYOIP, lleva un rango elegible sobre el que posee la autoridad requerida, y el proveedor lo anuncia para los servicios alojados en su plataforma.

La página pública de OVHcloud afirma que el cliente sigue siendo titular de las direcciones que incorpora mientras OVHcloud las anuncia y enruta hacia servicios compatibles. Presenta continuidad, reputación y reversibilidad como ventajas. También menciona compatibilidad con rangos registrados en ARIN, APNIC y RIPE, la opción Bring Your Own AS, DNS inverso opcional y límites de tamaño y región. Un comprador debe confirmar de nuevo esas condiciones para el producto actual.

La guía de ayuda explica que el flujo documentado importa bloques IPv4 /24 y que el cliente selecciona RIR, región y origen: AS de OVHcloud o AS propio. La elección cambia el ASN que debe aparecer en ROA, objetos IRR, supervisión y salida. Es un requisito concreto del flujo publicado, no una regla universal para cualquier servicio BYOIP, y no es un ajuste cosmético.

Una comparación cotidiana ayuda. El registro de recursos se parece a los documentos que acreditan quién puede gestionar una propiedad. El ROA se parece a una autorización firmada que indica qué puerta puede recibir entregas. El objeto IRR es una entrada de directorio usada para planificar el camino. BGP son los vehículos que realmente toman ese camino. La aplicación es el almacén que debe estar abierto al final. Papeles correctos no garantizan una carretera o una puerta funcionales.

Cuatro pruebas que deben conservar su nombre

La primera es el registro del recurso. Un RIR coordina asignaciones de direcciones y ASN. La organización necesita cuentas vigentes, responsables y, según el modelo, un certificado que cubra el bloque. Esto demuestra autoridad administrativa definida, no un anuncio vivo.

La segunda es RPKI. El titular de recursos certificados puede crear un Route Origin Authorization. RFC 9582 describe un objeto firmado con un AS de origen, uno o varios prefijos y una longitud máxima opcional. Los validadores convierten ese material en datos que las redes pueden usar en su política.

La tercera es el Internet Routing Registry. Un objeto route o route6 combina prefijo y origen con metadatos. RIPE documenta la estructura y la autorización para crearlo. Muchos operadores consultan IRR al elaborar filtros. Es una declaración de intención, no el ROA criptográfico ni la ruta activa.

La cuarta es BGP en ejecución. El proveedor configura routers, los vecinos reciben anuncios según sus políticas y los puntos de observación ven partes del sistema. Detrás de la ruta, la IP debe estar asociada al proyecto, firewall, balanceador o servidor correcto.

Puede haber divergencias. El titular figura correctamente, pero no existe ROA. El ROA autoriza un AS que no anuncia. El IRR mantiene un origen antiguo. BGP transporta una ruta inválida. La ruta llega al proveedor y la aplicación devuelve errores. Cada diferencia tiene un responsable distinto.

El expediente debe etiquetar la evidencia: recurso revisado a cierta hora; carga ROA validada por un punto concreto; objeto IRR consultado; origen BGP observado; prueba de aplicación realizada. Una captura del panel demuestra estado del panel, no experiencia universal.

Qué significan válido, inválido y desconocido

RIPE NCC explica que una ruta es válida cuando un ROA que cubre el prefijo autoriza el origen observado y permite su longitud. Es inválida si el ASN no está autorizado o el anuncio es más específico que el maxLength. Es desconocida si ningún ROA que cubra el prefijo proporciona respuesta.

Válido no significa disponible. No confirma el camino AS completo, la asociación con el servicio, TLS, aplicación o propiedad comercial. Solo verifica una relación de origen.

Inválido es una alerta seria, aunque no demuestra por sí solo un ataque. Puede haber un ASN mal escrito, una transición de proveedor, un subprefijo no previsto o un cambio de certificado. La investigación debe ser urgente y precisa.

Desconocido tampoco equivale a seguro o comprometido. Indica ausencia de una autorización que cubra la observación. Las redes aplican políticas locales. RFC 6811 señala además que los validadores usan cachés distribuidas; durante una actualización pueden existir vistas distintas.

Crear un ROA no pulsa un interruptor mundial. El RIR publica, los validadores descargan y los routers consumen según sus intervalos. ARIN describe tiempos del repositorio y del ecosistema, no un segundo universal. La bitácora debe registrar envío, publicación, validación observada y origen BGP visible.

El ASN y maxLength no admiten aproximaciones

El ASN del ROA debe coincidir con la red que originará el prefijo. OVHcloud ofrece elegir su AS o uno del cliente. Si el diseño cambia al salir, la autorización también debe cambiar.

Durante un solapamiento legítimo puede ser necesario autorizar dos orígenes. ARIN explica que cada ROA contiene un solo AS y que se requieren ROA adicionales para varios ASN. La arquitectura, proveedor y política determinan si ese solapamiento es apropiado; no debe improvisarse bajo presión.

La longitud máxima indica hasta qué especificidad se autoriza. Una cifra demasiado restrictiva vuelve inválido un anuncio legítimo. Una cifra demasiado amplia autoriza más subprefijos de los necesarios. ARIN aconseja ROA exactos para los prefijos anunciados y cautela con valores amplios.

La pregunta no técnica es clara: ¿la autorización firmada describe exactamente los prefijos y orígenes de funcionamiento normal, transición y retorno? Si nadie mantiene la respuesta, la portabilidad existe solo en teoría.

Los objetos IRR expresan intención, no visibilidad

La documentación de RIPE describe objetos route y route6, cuyo identificador combina prefijo y origen, y protege su creación mediante autorizaciones. Esos datos pueden alimentar filtros de operadores y por ello afectan a la aceptación de rutas.

Sin embargo, un objeto IRR no es un ROA. Sus modelos de confianza difieren. Puede existir uno sin el otro. Y ninguno es BGP: un objeto antiguo puede sobrevivir tras la salida, mientras uno nuevo puede aparecer antes de que ningún router anuncie.

El control previo debe comparar cuatro valores por separado: intención del plan, objeto IRR, ROA validado y origen observado. La API de RIPE permite consultas repetibles, pero la automatización debe detenerse ante una discrepancia concreta, no elegir el resultado más parecido.

Diseñar la salida antes del alta

Antes del primer anuncio, el camino actual sigue funcionando. Ese es el momento barato para revisar autoridad y accesos.

Registrar titular, cuenta RIR, certificado, administradores y recuperación. Determinar si el bloque es directo o proviene de un operador superior. ARIN advierte que un usuario de espacio reasignado puede no tener autoridad RPKI y necesitar que el proveedor ascendente cree el ROA.

Registrar la relación real con el proveedor: entidad contratante, región, soporte, ASN de origen, reglas de tamaño, retirada y DNS inverso. La documentación de marca orienta, pero el pedido vigente manda.

Guardar ROA, maxLength, objetos IRR y orígenes actuales. Nombrar quién puede editar cada uno y cuánto tarda un tercero. Establecer una línea base externa de ruta y aplicación.

Después escribir el movimiento inverso. ¿Qué debe existir antes de anunciar desde el nuevo AS? ¿Qué observaciones permiten retirar el antiguo? ¿Cuánto dura el solapamiento? ¿Qué autorizaciones se conservan para volver? ¿Cuándo se eliminan? Un plan que solo sabe entrar no es reversible.

Una secuencia de trabajo verificable

Primero, confirmar rango IPv4, autoridad, certificado, cuentas, ASN y requisitos actuales del producto. Segundo, redactar los ROA y objetos IRR esperados y someter cada carácter a una segunda revisión.

Tercero, inventariar DNS directo e inverso, certificados, firewall, listas permitidas, reputación, geolocalización, contactos de abuso, monitores y socios. Conservar la IP reduce cambios, pero no elimina dependencias.

Cuarto, completar el alta sin tráfico normal. Una guía separada de OVHcloud etiqueta actualmente su función BGP Service como alfa y no apta para producción. No debe confundirse con una promesa general de BYOIP ni usarse sin una evaluación explícita.

Quinto, publicar autoridad mediante canales autorizados y conservar el estado anterior mientras el retorno lo necesite. Sexto, comprobar RIR, validadores, IRR y proveedor antes de anunciar.

Séptimo, efectuar un anuncio acotado y observar prefijo, longitud y origen desde varios puntos externos. Octavo, probar TLS, HTTP, API, correo y protocolos relevantes por la ruta pública.

Noveno, mover tráfico gradualmente con umbrales de error y decisión escritos. Décimo, retirar el origen anterior solo después de observar el nuevo y limpiar objetos, cuentas, reglas y secretos obsoletos cuando ya no sostengan el retorno.

Cada fase necesita un propietario y una condición de parada. “El equipo de red” no es una persona disponible a las tres de la mañana.

Volver atrás es restaurar un estado, no pulsar cancelar

Cancelar un pedido, retirar una ruta, volver a anunciar la antigua o cambiar una asociación de aplicación producen resultados diferentes. Si la nueva ruta es válida pero la aplicación falla, retirar el anuncio ayuda únicamente si el servicio y la ruta viejos continúan listos.

Si la ruta es inválida por un ASN incorrecto, revertir código no corrige el origen. Si aparecen dos orígenes inesperados, pedir a ambos proveedores que deshagan todo a la vez puede crear un vacío.

El retorno debe describirse como estado completo: origen anterior visible, registros de autoridad compatibles, aplicación asociada, pruebas externas correctas y responsable de decisión. Retirar la ruta nueva es una acción dentro de ese estado.

El tiempo también importa. Repositorios, cachés y routers no convergen al instante. Mantener el camino viejo cuesta, pero preserva la única recuperación probada. Ahorrar unas horas de infraestructura puede multiplicar el coste de una caída.

Fallos frecuentes y costes reales

Falta de autoridad: el equipo descubre que un proveedor superior controla el certificado. ASN equivocado: ROA, pedido y anuncio no coinciden. maxLength incorrecto: solo algunos subprefijos quedan inválidos. IRR obsoleto: ciertos filtros mantienen la intención anterior. Retirada temprana: no queda origen operativo.

Retorno falso: se detiene lo nuevo sin recuperar lo viejo. Asociación incorrecta: BGP funciona y la aplicación no. Limpieza incompleta: permanecen ROA, objetos, cuentas y credenciales antiguas. Confusión de entidad: el incidente llega a la cola equivocada.

El coste aparece en personas y negocio: turnos nocturnos, socios bloqueados, soporte duplicado, decisiones sin evidencia y pérdida de confianza. La tarifa de la función puede ser pequeña; la coordinación no lo es.

Una matriz de responsabilidad debe asignar recurso RIR, ROA, IRR, anuncio proveedor, servicio, DNS, monitorización, coordinación y retirada. Una fila sin dueño es un control productivo no asignado.

Programa de treinta días

Días 1 a 5: inventariar prefijos críticos, servicios, titular, origen, ROA, IRR y línea base externa. Días 6 a 10: probar accesos y recuperación con dos operadores. Días 11 a 15: definir estados normal, transición, retorno y final con revisión independiente.

Días 16 a 20: revisar DNS, certificados, correo, listas, seguridad, monitores y terceros. Días 21 a 25: ensayar de forma segura y medir sin convertir un ensayo en SLA. Días 26 a 28: simular ruta inválida, ruta válida con aplicación caída y visibilidad parcial.

Días 29 y 30: aprobar coordinador, autoridad de retorno, ventana de solapamiento, evidencias y fecha de limpieza. Al final, otra persona debe poder ejecutar el plan sin depender de memoria informal.

Lo que no dicen las fuentes públicas

Las fuentes no asignan a OVH US LLC ningún ASN, prefijo, ruta, cliente, instalación o despliegue concreto para este artículo. La ficha RIPE no sirve para eso.

Las páginas OVHcloud describen capacidades de marca, no la entidad jurídica de cada caso ni el resultado de un cliente. No muestran un ROA, objeto IRR o ruta real de cliente, ni prueban una caída o debilidad.

No garantizan tiempo global de propagación. Cada validador, red y punto de observación tiene contexto. Tampoco prueban disponibilidad, correo, reputación, latencia o rendimiento de protección.

La guía de BGP Service consultada califica esa función separada como alfa y no destinada a producción; aquí no se recomienda como dependencia.

La imagen es contexto editorial genérico y no representa equipos, lugares, personas o incidentes reales de OVH US LLC u OVHcloud.

Conclusión

La ficha de OVH US LLC en RIPE es un ancla administrativa limitada. La documentación OVHcloud muestra un control BYOIP para IPv4 elegible y una elección de origen proveedor o cliente. Permite analizar el proceso sin inventar una ruta específica.

La portabilidad funciona por capas: registro, ROA, IRR, BGP y aplicación. Un resultado RPKI válido es importante, pero no garantiza servicio. La salida debe prepararse antes de la entrada con accesos, ASN, objetos precisos, dependencias, observación externa, camino antiguo y limpieza ordenada.

Para una persona no especialista, la prueba cabe en cinco preguntas: ¿quién controla el recurso?, ¿quién firma la autorización?, ¿qué red debe anunciar?, ¿qué ve Internet?, ¿quién puede restaurar lo anterior? Si las respuestas están documentadas y ensayadas, BYOIP aporta reversibilidad. Si solo están en un panel, una dirección familiar puede esconder una migración frágil.

Fuentes

  1. https://www.ripe.net/membership/member-support/list-of-members/us/ovh/
  2. https://www.ovhcloud.com/en/network/byoip/
  3. https://help.ovhcloud.com/csm/en-au-network-bring-your-own-ip?id=kb_article_view&sysparm_article=KB0044847
  4. https://www.ovhcloud.com/sites/default/files/external_files/cp_byoip_-_v2.0_-_2022.11.28_-_en.pdf
  5. https://help.ovhcloud.com/csm/en-sg-network-bgp-service-configuration?id=kb_article_view&sysparm_article=KB0066889
  6. https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/bgp-origin-validation/
  7. https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/resource-certification-roa-management/
  8. https://docs.db.ripe.net/Authorisation/Protection-of-Route-Object-Space/
  9. https://docs.db.ripe.net/RPSL-Object-Types/Descriptions-of-Primary-Objects/
  10. https://docs.db.ripe.net/Update-Methods/RESTful-API/
  11. https://www.arin.net/resources/manage/rpki/roas/
  12. https://www.arin.net/resources/manage/rpki/help/byoip/
  13. https://www.arin.net/resources/manage/rpki/help/bestpractices/
  14. https://www.arin.net/resources/manage/rpki/help/faq/
  15. https://datatracker.ietf.org/doc/html/rfc9582
  16. https://datatracker.ietf.org/doc/html/rfc6811
  17. https://datatracker.ietf.org/doc/html/rfc6480