Bring Your Own IP en un VPS con BGP: guía completa

Esta es la página central del recorrido BYOIP completo. Conecta cada paso desde la obtención de un ASN hasta la monitorización de tus anuncios BGP en producción. Cada sección enlaza con un artículo dedicado donde encontrarás configuraciones, comandos y pasos de verificación.

Si ya sabes qué son BGP y BYOIP, salta directamente a ¿Qué necesitas antes de tu primera sesión BGP?.

¿Qué significa traer tu propia IP a un VPS?

Bring Your Own IP (BYOIP) consiste en anunciar espacio de direcciones IP que posees o alquilas de un Regional Internet Registry (RIR) a través de la red de un proveedor de hosting usando BGP. En lugar de usar las direcciones IP del proveedor, tu VPS origina rutas para tus propios prefijos. El tráfico destinado a esas IPs llega a tu servidor a través de los enlaces upstream y puntos de intercambio del proveedor.

Mantienes el control de las direcciones. Si cambias de proveedor, tus IPs se mueven contigo. Sin cambios DNS, sin reiniciar la reputación, sin tiempo de inactividad visible para los clientes más allá de la ventana de convergencia.

¿Por qué traer tus propias IPs?

Continuidad de la reputación IP. La entregabilidad del correo, la reputación DNS y las listas blancas de firewall siguen a la dirección, no al servidor. Cambiar de proveedor con IPs asignadas por este significa reconstruir la reputación desde cero.

Portabilidad entre proveedores. Tus prefijos no están vinculados a ningún host en particular. Puedes migrar a otro proveedor, o funcionar en multi-homing con dos, sin cambiar las direcciones a las que se conectan tus clientes.

Multi-homing y redundancia. Anuncia el mismo prefijo desde múltiples ubicaciones. BGP gestiona la conmutación por error automáticamente. Tu servicio sigue siendo accesible incluso cuando un sitio cae.

Cumplimiento normativo y auditoría. Algunos entornos regulados exigen documentación sobre la propiedad de las direcciones IP. Poseer tu asignación a través de un RIR te proporciona esa trazabilidad.

Anycast. Anuncia el mismo prefijo desde nodos geográficamente distribuidos. Los usuarios son enrutados al más cercano. Así funcionan los servidores raíz DNS y los puntos de presencia CDN.

¿Cómo encaja BGP en el BYOIP?

BGP (Border Gateway Protocol) es el protocolo que usan los routers para intercambiar información de accesibilidad entre sistemas autónomos en Internet. Cuando traes tu propia IP a un VPS, ejecutas un demonio BGP en tu servidor. Ese demonio establece una sesión con el router de tu proveedor y anuncia tus prefijos. El proveedor propaga esos anuncios a sus upstreams y peers. En minutos, routers de todo Internet aprenden que tu espacio IP es accesible a través de la red de tu proveedor.

Es el mismo protocolo que usa cada ISP, proveedor cloud y red de contenido. La diferencia es la escala: anuncias uno o dos prefijos en lugar de miles.

No necesitas entender cada atributo BGP para empezar. Necesitas saber cómo configurar una sesión, anunciar un prefijo y filtrar lo que aceptas. Los artículos detallados de este cocoon cubren cada uno de esos puntos.

¿Qué necesitas antes de tu primera sesión BGP?

Seis bloques de construcción, en orden de dependencia:

Un Autonomous System Number (ASN). Tu identidad en el Internet BGP. Lo obtienes de un RIR (RIPE NCC en Europa, ARIN en Norteamérica, APNIC en Asia-Pacífico) a través de un LIR patrocinador. El procesamiento tarda 2-5 días laborables en RIPE NCC. Cómo registrar un ASN en RIPE NCC
Una asignación IP. Como mínimo un /24 para IPv4 o un /48 para IPv6. Los prefijos más pequeños son filtrados por la mayoría de redes y no se propagarán. Puedes tener espacio IPv4 de un RIR (cada vez más escaso y caro) o alquilarlo a un broker. Las asignaciones IPv6 están disponibles fácilmente en todos los RIR.
Objetos route IRR. Entradas en el Internet Routing Registry que documentan qué ASN está autorizado a originar tu prefijo. Muchos proveedores de tránsito construyen sus filtros BGP a partir de datos IRR. Sin un objeto route correspondiente, tu anuncio puede ser descartado silenciosamente. Créalos en la base de datos RIPE (o el equivalente de tu RIR) antes de tu primera sesión.
ROA RPKI (Route Origin Authorizations). Objetos criptográficos que vinculan tu prefijo a tu ASN. Más del 51 % de las rutas IPv4 y el 57 % de las rutas IPv6 tienen ahora ROAs válidos. Las redes que realizan Route Origin Validation (ROV) rechazarán los anuncios que no pasen las verificaciones RPKI. Crea los ROA en el portal de tu RIR. RPKI ROA para BGP: crear ROAs, validar rutas en BIRD2 y FRR
Un demonio de enrutamiento. Software en tu VPS que habla BGP. Las tres opciones principales son BIRD2, FRRouting (FRR) y VyOS. Consulta la comparación más abajo.
Un proveedor con soporte de sesión BGP. No todos los proveedores de VPS ofrecen esto. Necesitas un proveedor que configure una sesión BGP entre su router y tu VPS, acepte tus anuncios de prefijo y los propague upstream.

Lista de verificación previa

Antes de solicitar una sesión BGP a tu proveedor, asegúrate de tener:

Elemento	Dónde obtenerlo	Tiempo estimado
ASN	RIR vía LIR patrocinador	2-5 días laborables
IPv4 /24 o mayor	Asignación RIR o alquiler	Días a semanas
IPv6 /48 o mayor	Asignación RIR	1-2 días laborables
Objetos route/route6 IRR	Base de datos RIPE o equivalente	Minutos (tras ASN)
ROA RPKI para cada prefijo	Portal de miembros RIR	Minutos
LOA (Carta de autorización)	La firmas tú, el proveedor puede solicitarla	Minutos
Proveedor con soporte BGP	o similar	Variable

Tu proveedor normalmente necesitará tu ASN, los prefijos que planeas anunciar y posiblemente una LOA confirmando que estás autorizado a anunciarlos.

¿Cómo se relacionan ASN, asignación IP y RPKI?

Estos tres forman la cadena de confianza que permite a Internet verificar que tus anuncios son legítimos.

Tu ASN identifica tu red. Cada anuncio BGP lleva el ASN de origen en su AS-path. Las redes upstream usan esto para construir política de enrutamiento.

Tu asignación IP es el espacio de direcciones que estás autorizado a usar. La base de datos del RIR te registra (o a tu LIR patrocinador) como titular.

Los objetos IRR son la capa de política de enrutamiento. Un objeto route en la base de datos RIPE dice "AS64500 está autorizado a originar 192.0.2.0/24." Los proveedores de tránsito consultan los datos IRR para construir filtros de prefijos. Si tu objeto route falta o es incorrecto, los filtros automatizados de tu proveedor de tránsito pueden rechazar tu anuncio.

Los ROA RPKI son la capa criptográfica. Un ROA es un objeto firmado almacenado en el repositorio RPKI de tu RIR. Dice lo mismo que el objeto route IRR, pero es verificable criptográficamente. Las redes que ejecutan validadores ROV (Routinator, rpki-client, Fort, RIPE NCC RPKI Validator) obtienen los ROA y alimentan los resultados de validación a sus routers. Un anuncio sin un ROA válido tiene cada vez más probabilidades de ser descartado.

La cadena de dependencias se ve así:

ASN (from RIR)
  └── IP allocation (from RIR)
        ├── IRR route objects (RIPE Database)
        ├── RPKI ROAs (RIR portal)
        └── BGP session (provider router <-> your daemon)
              └── Prefix announcement (your daemon originates routes)

Pon en orden las capas superiores antes de tocar la configuración BGP. Un anuncio sin registros IRR y RPKI correspondientes será filtrado o señalado como un potencial secuestro de rutas.

Cómo registrar un ASN en RIPE NCC

¿Qué demonio de enrutamiento usar: BIRD2, FRR o VyOS?

Tres opciones dominan BGP en entornos VPS Linux. Las tres soportan dual-stack (IPv4 + IPv6), validación RPKI y las funcionalidades necesarias para BYOIP. La elección depende del estilo de configuración preferido y los requisitos operativos.

Característica	BIRD2	FRRouting (FRR)	VyOS
Estilo de configuración	Lenguaje declarativo propio	CLI tipo Cisco IOS (vtysh)	CLI tipo JunOS (set/commit)
Lenguaje de filtrado	Filtros potentes, Turing-completos	Route-maps + prefix-lists	Route-maps (FRR bajo el capó)
Dual-stack	Archivo de configuración único, multi-tabla	Bloques address-family separados	Bloques address-family separados
Soporte RPKI	Protocolo `rpki` integrado	Módulo rpki integrado	Vía integración FRR
Uso de memoria	Menor (2x más eficiente que FRR en benchmarks)	Mayor, especialmente con tablas completas	Mayor (overhead de un SO completo)
Curva de aprendizaje	Más empinada si vienes de Cisco	Baja para usuarios Cisco/IOS	Baja para usuarios JunOS
Ideal para	Servidores de ruta IXP, configuraciones con muchas políticas	Workflow familiar tipo Cisco	Experiencia completa de router OS

BIRD2 tiene el lenguaje de filtrado más expresivo. Puedes escribir políticas de importación/exportación complejas en un solo archivo de configuración. Maneja IPv4 e IPv6 en una sola instancia del demonio. El consumo de memoria es aproximadamente la mitad que el de FRR para cargas equivalentes. La contrapartida: su sintaxis de configuración no tiene equivalente en el mundo de los fabricantes. Aprendes el lenguaje de BIRD o no usas BIRD. Configuración de BGP con BIRD2 en un VPS Linux

FRRouting (FRR) usa un CLI tipo Cisco IOS a través de vtysh. Si has trabajado con Cisco, Arista o el antiguo Quagga, FRR te resultará familiar de inmediato. Los route-maps y prefix-lists funcionan como esperas. Es la suite de enrutamiento de código abierto más desplegada. Configuración de BGP con FRRouting en un VPS Linux

VyOS es un sistema operativo de red completo que usa FRR como motor de enrutamiento. Configuras todo mediante un workflow set / commit al estilo JunOS. Proporciona una experiencia de router completa: firewall, NAT, VPN, DHCP y enrutamiento en un solo paquete. En Virtua Cloud puedes desplegar VyOS con un clic. La contrapartida: es un SO completo, no solo un demonio. Pierdes la flexibilidad de un servidor Linux de propósito general. Configuración de BGP en VyOS sobre un VPS: Tutorial Dual-Stack

¿Cuál elegir? Si quieres máximo control y eficiencia, elige BIRD2. Si quieres la familiaridad de Cisco en un servidor Linux, elige FRR. Si quieres un appliance de router dedicado, elige VyOS.

¿Cómo asegurar un despliegue BGP?

La seguridad en BGP no es opcional. Una sesión BGP mal configurada puede filtrar rutas, aceptar prefijos secuestrados o exponer tu red a la inyección de tráfico. Cada despliegue BGP debería incluir estas capas desde el primer día.

RPKI y validación de origen de ruta

Configura tu demonio para validar las rutas recibidas contra los datos RPKI. Ejecuta una caché RPKI local (Routinator o rpki-client) o conéctate a un validador hospedado. Rechaza rutas con estado RPKI "invalid". Esto evita que tu router acepte prefijos secuestrados.

A fecha de 2025, más del 51 % de las rutas IPv4 y el 57 % de las rutas IPv6 tienen ROAs válidos. Todos los grandes proveedores de tránsito realizan ROV. Si tus propios prefijos carecen de ROAs, algunas redes descartarán tus anuncios. RPKI ROA para BGP: crear ROAs, validar rutas en BIRD2 y FRR

Filtrado de rutas

Nunca uses export all o import all en producción. Son el equivalente BGP de chmod 777.

En el lado de exportación, anuncia solo los prefijos que estás autorizado a originar. Usa una prefix-list que coincida explícitamente con tus asignaciones. En el lado de importación, si eres single-homed (un upstream), normalmente aceptas solo una ruta por defecto. Si eres multi-homed, filtra las importaciones por prefix-list y AS-path para prevenir fugas de rutas.

Rechaza prefijos bogon (espacio RFC 1918, rangos de documentación, bloques no asignados) en la importación. Rechaza prefijos más largos que /24 para IPv4 o /48 para IPv6. Establece límites max-prefix para protegerte contra un peer que vuelque accidentalmente una tabla de enrutamiento completa en tu sesión.

Filtrado de rutas BGP: Prefix Lists, Filtros AS-Path, Rechazo de Bogons y GTSM

GTSM (Generalized TTL Security Mechanism)

GTSM (RFC 5082) garantiza que los paquetes BGP lleguen con un TTL de 255, lo que significa que se originaron en un vecino directamente conectado. Esto bloquea a atacantes remotos que intenten inyectar paquetes BGP. La mayoría de proveedores lo soportan. Actívalo en tu lado cuando tu proveedor confirme el soporte.

Reglas de firewall

Permite el puerto TCP 179 solo desde la IP del router BGP de tu proveedor. Descarta todo lo demás destinado al puerto 179. Es una sola regla nftables o iptables, pero previene intentos de conexión BGP no autorizados.

Errores comunes

rp_filter rompiendo el tráfico. El filtrado de ruta inversa de Linux (rp_filter=1, el valor por defecto en muchas distribuciones) descarta paquetes que llegan a una interfaz si la tabla de enrutamiento del kernel indica que la IP de origen debería llegar por otra interfaz. Con prefijos anunciados por BGP en interfaces dummy, esto rompe tráfico legítimo. Establece rp_filter=0 o rp_filter=2 (modo loose) en las interfaces afectadas. Compruébalo tras cada actualización del kernel.

Confusión entre configuración de BIRD 1.x y BIRD 2.x. BIRD 2 usa una sintaxis de configuración completamente diferente a BIRD 1.x. Muchos tutoriales en línea (incluidos resultados destacados de Vultr y otros) siguen mostrando sintaxis de BIRD 1.x. Si copias y pegas configuración de un tutorial antiguo en BIRD 2, el demonio se negará a arrancar. Comprueba siempre qué versión estás ejecutando con birdc show status.

Objetos IRR faltantes. Creaste los ROA RPKI pero olvidaste el objeto route IRR. El constructor de filtros automatizado de tu upstream consulta IRR, no encuentra ningún objeto correspondiente y descarta silenciosamente tu anuncio. Tu prefijo es RPKI-valid pero sigue siendo inalcanzable. Crea siempre ambos.

¿Qué puedes hacer con BGP más allá de los anuncios básicos?

Una vez que tu prefijo está anunciado y es accesible, BGP abre varios casos de uso avanzados.

Anycast

Anuncia el mismo prefijo desde múltiples ubicaciones geográficas. Cada sitio ejecuta un servicio idéntico (resolver DNS, edge CDN, endpoint API). Los usuarios son enrutados al sitio más cercano por la selección de ruta BGP. Si un sitio falla, su sesión BGP cae, el prefijo se retira de esa ubicación y el tráfico se desplaza automáticamente a los sitios restantes.

Anycast es el principio de funcionamiento del sistema de servidores raíz DNS. Puedes ejecutar el mismo patrón con dos o tres nodos VPS en diferentes centros de datos. DNS Anycast con BIRD2 y BGP: configuración multi-ubicación

Conmutación por error y multi-homing

Anuncia tu prefijo desde dos proveedores o dos ubicaciones con el mismo proveedor. Usa LOCAL_PREF y MED para establecer la preferencia primario/respaldo. Cuando el primario falla, el tráfico cambia al respaldo dentro de la ventana de convergencia BGP (típicamente 30-90 segundos con BFD activado).

Para mantenimiento planificado, usa la comunidad graceful shutdown (RFC 8326). Tu demonio señala a los peers que deprioricen el prefijo antes de que bajes la sesión. El tráfico se drena al sitio de respaldo sin pérdida de paquetes. Failover BGP y multihoming desde dos ubicaciones VPS

Comunidades BGP para ingeniería de tráfico

Las comunidades son etiquetas adjuntas a los anuncios BGP que influyen en cómo las redes upstream manejan tus rutas. Usos comunes:

Comunidad blackhole: Señala a tu upstream que descarte todo el tráfico hacia un prefijo específico durante un ataque DDoS.
Control de prepending: Pide a tu upstream que prependa tu AS para hacer una ruta menos preferida, dirigiendo el tráfico a otro upstream.
Anuncio selectivo: Anuncia a peers pero no a tránsito, o viceversa, controlando dónde se propaga tu prefijo.
Alcance geográfico: Limita el anuncio a regiones o IXPs específicos.

Cada proveedor define sus propios valores de comunidades. Consulta la documentación de comunidades BGP de tu proveedor antes de usarlas. BGP Communities: estándar, large y extended

¿Cómo monitorizar los anuncios BGP?

Necesitas saber cuándo algo cambia con tus prefijos. Los secuestros de rutas, las retiradas accidentales, los cambios de estado RPKI y las caídas de visibilidad requieren atención inmediata. No asumas que tus anuncios son estables porque funcionaban ayer.

BGPalerter es una herramienta de monitorización auto-hospedada que vigila tus prefijos y ASN. Se conecta a fuentes de datos BGP públicas (RIPE RIS, RouteViews) y te alerta sobre:

Secuestros de prefijo (otro ASN originando tu prefijo)
Secuestros de sub-prefijo (alguien anunciando un más específico de tu prefijo)
Fugas de rutas
Cambios de estado RPKI invalid
Caídas de visibilidad (tu prefijo desaparece de un número significativo de puntos de observación)

Ejecútalo como servicio systemd en un VPS separado del que hace BGP. Si tu nodo BGP cae, sigues queriendo recibir alertas. Configura notificaciones a Slack, email o tu stack de monitorización. Monitorizar anuncios BGP con BGPalerter en Linux

Herramientas de validación externa

Úsalas para verificar que tus anuncios se ven correctos desde fuera:

bgp.tools -- Vista en tiempo real de tu prefijo, AS-path, estado RPKI y consistencia IRR
RIPE Stat -- Looking glass operado por el RIR con historial de enrutamiento y validación RPKI
Hurricane Electric BGP Toolkit (bgp.he.net) -- Información AS, informes de prefijos, estado IRR y RPKI
Servidores looking glass -- La mayoría de proveedores de tránsito e IXPs ofrecen acceso looking glass para verificar cómo aparece tu prefijo desde su perspectiva

Consulta estas herramientas tras tu primer anuncio y periódicamente después. Un anuncio que parece correcto desde la perspectiva de tu demonio puede estar siendo filtrado o secuestrado más arriba en la cadena.

El recorrido completo: de cero a BGP monitorizado

Aquí está el camino completo, con enlaces al artículo que cubre cada paso:

Obtener un ASN de tu RIR a través de un LIR patrocinador. Cómo registrar un ASN en RIPE NCC
Obtener espacio IP. Como mínimo /24 IPv4, /48 IPv6. De tu RIR o un broker.
Crear objetos route IRR en la base de datos RIPE para cada prefijo.
Crear ROA RPKI en el portal de tu RIR para cada prefijo. RPKI ROA para BGP: crear ROAs, validar rutas en BIRD2 y FRR
Elegir un demonio de enrutamiento: BIRD2 Configuración de BGP con BIRD2 en un VPS Linux, FRR Configuración de BGP con FRRouting en un VPS Linux o VyOS Configuración de BGP en VyOS sobre un VPS: Tutorial Dual-Stack.
Configurar BGP en tu VPS. Establecer la sesión, anunciar tus prefijos, aplicar filtros.
Asegurar el despliegue. Validación RPKI, filtrado de rutas, GTSM, reglas de firewall. Filtrado de rutas BGP: Prefix Lists, Filtros AS-Path, Rechazo de Bogons y GTSM
Verificar desde fuera. Consultar bgp.tools, RIPE Stat y el looking glass de tu proveedor.
Configurar monitorización. Desplegar BGPalerter para vigilar secuestros y problemas de visibilidad. Monitorizar anuncios BGP con BGPalerter en Linux
Explorar casos de uso avanzados. Comunidades BGP Communities: estándar, large y extended, anycast DNS Anycast con BIRD2 y BGP: configuración multi-ubicación, conmutación por error Failover BGP y multihoming desde dos ubicaciones VPS.

¿Necesitas tu propia ASN o puedes usar una privada?

Si anuncias prefijos a un solo upstream y nunca planeas multi-homing o peering en un IXP, una ASN privada (64512-65534 para 16 bits, 4200000000-4294967294 para 32 bits) puede funcionar. Tu proveedor la elimina del AS-path antes de propagar tus rutas upstream.

Obtén tu propia ASN pública si alguno de estos casos aplica:

Planeas conectarte a múltiples upstreams (multi-homing)
Quieres hacer peering en un punto de intercambio de Internet
Quieres que tu ASN sea visible en traceroutes y looking glasses BGP
Quieres usar comunidades BGP que referencien tu ASN
Operas un servicio donde la identidad de red importa (CDN, DNS, infraestructura de correo)

La diferencia de coste es mínima. Una ASN pública a través del RIPE NCC cuesta la tarifa del LIR patrocinador (típicamente unos cientos de euros al año). Para la mayoría de los casos de uso, una ASN pública es la elección correcta.