Errores comunes en la configuración de BGP con IPv4

Errores en la configuración de BGP al recibir subredes IPv4 nuevas

Configurar BGP para un bloque de direcciones IPv4 recién comprado o alquilado es de esas tareas donde lo pequeño se cobra caro. Que el prefijo figure a tu nombre en el RIR no garantiza nada: un anuncio mal hecho puede dejar la subred invisible para media Internet, filtrada a medias o, en el peor escenario, secuestrada por terceros. Después de acompañar a muchos clientes de IP4 Market en sus primeras migraciones, hemos visto repetirse los mismos fallos. Estos son los más frecuentes, con su correspondiente checklist para esquivarlos.

1. Anunciar el prefijo sin ROA publicado en el RIR

Este es, con diferencia, el error más común. Desde que los grandes proveedores exigen validación RPKI, anunciar sin un ROA (Route Origin Authorization) válido equivale casi a no anunciar. Si el ROA no existe, o si el ASN de origen declarado no coincide con el que realmente anuncia, el prefijo acaba marcado como RPKI Invalid y buena parte de Internet lo descarta sin más. Se estima que más del 55% de las rutas globales ya se validan con RPKI, y la cifra sigue subiendo.

• Error típico: comprar el bloque, transferirlo en RIPE Database y anunciarlo desde el ASN del proveedor sin haber creado el ROA.
• Solución: publica el ROA en el RIR (RIPE NCC, ARIN, LACNIC…) con el ASN correcto y una maxLength coherente. Un detalle que muchos pasan por alto: si anuncias un /24 suelto, no pongas maxLength 24 salvo que vayas a segmentar; si piensas anunciar el agregado y los /24 individuales, decláralo expresamente.

2. LOA incorrecto o inexistente hacia el tránsito

Cuando anuncias un prefijo que no figura como tuyo a nivel de registro (un bloque alquilado, por ejemplo, o espacio anunciado bajo el ASN de un ISP), el upstream pedirá un LOA (Letter of Authorization). Y aquí empiezan los disgustos: LOA con el ASN equivocado, prefijos mal escritos, firmas sin fecha. Motivos triviales que tumban la propagación completa.

Qué debe contener un LOA correcto

• Prefijo exacto en notación CIDR (por ejemplo, 203.0.113.0/24).
• ASN autorizado a anunciar y ASN del downstream si aplica.
• Datos de contacto del titular del recurso y fecha de emisión.
• Coherencia total con el registro WHOIS/RDAP del RIR.

3. No anunciar el /24 mínimo o fragmentar en exceso

La tabla BGP global supera el millón de rutas IPv4, y muchos operadores filtran por tamaño mínimo de prefijo. Anunciar algo más específico que un /24 suele ser tirar el tiempo: la mayoría de redes lo descartan. Pero el extremo contrario también es un problema. Fragmentar un /22 en cuatro /24 cuando todos comparten la misma salida solo multiplica el consumo de tabla sin beneficio alguno.

¿La buena práctica? Anunciar el agregado (el /22, en este caso) y deagregar los /24 únicamente cuando necesites rutas de retorno distintas: multihoming con tránsitos diferentes o tráfico anycast.

4. Configuración BGP: errores de filtro y política de anuncios

Aunque el ROA y el LOA estén impecables, la sesión BGP en sí sigue siendo fuente habitual de sustos.

Anuncios que no salen del AS propio

Si el prefijo no está en la política de exportación (route-map, prefix-list o policy-options, según fabricante), el vecino jamás lo verá. Antes de escalar al proveedor, comprueba siempre con show ip bgp neighbor x.x.x.x advertised-routes o el comando equivalente.

Filtros de entrada demasiado permisivos

Aceptar rutas completas sin filtrar, o sin límite de prefijos, deja tu red expuesta a fugas y a saturación de la tabla RIB. Configura un prefix-limit razonable. Por ejemplo: aceptar solo la default route más tus propios prefijos de un upstream con filtrado estricto.

Olvidar el atributo de origen y AS-path prepending mal aplicado

Un prepending agresivo (5-10 AS añadidos) sobre un único tránsito puede dejar el prefijo con tráfico irregular o directamente nulo. Ajusta el prepending según el AS-path entrante real, no de forma estática.

5. No propagar el prefijo en IRR antes del anuncio

Muchos upstreams validan los anuncios contra las bases IRR (Internet Routing Registry). Si tu objeto route/route6 no existe o apunta a otro origen, el anuncio se filtrará aunque el ROA sea correcto. En RIPE, crea el objeto route con origen en tu ASN y mantén la coherencia entre IRR y RPKI. Herramientas como bgpq4, o los validadores de los propios transit providers, consultan estas bases de forma automática.

6. Errores de tiempos: retirar el anuncio antiguo demasiado pronto

Si el bloque venía de otro operador (algo habitual en el mercado secundario, donde un /24 se mueve entre 25 y 50 dólares por dirección según región y reputación), el anuncio anterior puede persistir en caches durante horas. Retirar el anuncio del antiguo ASN y anunciar desde el nuevo al mismo tiempo puede generar rutas conflictivas.

1. Anuncia el prefijo desde el nuevo ASN, con el ROA antiguo ya retirado.
2. Verifica la visibilidad global con Looking Glass (bgp.he.net, routeviews, RIPEstat).
3. Cuando la nueva ruta esté estable, confirma que el anuncio antiguo desaparece de los principales peers.

7. No revisar la reputación y blacklist del bloque recibido

Un bloque recién comprado puede arrastrar listados en DNSBL (Spamhaus, Barracuda), historial de abusos o geolocalización errónea. Todo ello afecta a la entregabilidad de correo y a servicios de CDN. Antes de anunciar nada, revisa el historial del prefijo en RIPEstat, Spamhaus y las bases de reputación. En IP4 Market todos los bloques listados por vendedores verificados pasan comprobaciones de limpieza previas, lo que reduce bastante estos riesgos.

Checklist final antes de anunciar tu nueva subred IPv4

• Transferencia completada en el RIR y WHOIS/RDAP actualizado con tu organización.
• ROA publicado con ASN y maxLength correctos.
• Objeto route IRR creado y coherente con RPKI.
• LOA emitido si el anuncio se realiza vía upstream o ASN de terceros.
• Política de exportación BGP verificada en el router.
• Prefix-limit y filtros de entrada configurados.
• Reputación del bloque revisada y monitorización activada.

Conclusión

Lo curioso es que la mayoría de problemas al poner en producción una subred IPv4 nueva no vienen del protocolo BGP en sí, sino de la falta de coordinación entre tres planos: el registro (RIR), la validación (RPKI, IRR, LOA) y la configuración en los routers. Con una planificación ordenada —ROA e IRR antes del anuncio, filtros revisados, monitorización durante las primeras horas— se evita el 90% de las incidencias. Y si estás buscando bloques IPv4 limpios y documentados para comprar o alquilar, en IP4 Market encontrarás una plataforma con vendedores verificados, precios competitivos y acompañamiento técnico durante todo el proceso de transferencia y anuncio, para que tu configuración de BGP parta de una base sólida desde el primer día.