Cómo anunciar IP alquiladas desde su propio ASN: LOA, IRR y ROA
¿Alquiló un bloque IPv4 o IPv6 a IMIDC y desea anunciarlo por BGP desde su propio ASN en su propio centro de datos o con otro proveedor? Necesitará tres cosas: una LOA (carta de autorización) del titular de las direcciones, objetos de ruta IRR (route / route6) y un ROA de RPKI. Esta guía recorre todo el proceso: qué es una LOA, qué datos debe proporcionar, cómo se complementan IRR y ROA, cómo filtran los upstreams y cómo confirmar la propagación con bgp.tools, bgp.he.net y RIPEstat. Está dirigida a operadores que ya tienen un ASN y una sesión BGP con un upstream.
Paso 1: Para qué sirve una LOA en los anuncios BGP
Una LOA es una carta firmada por el titular de las direcciones que indica que el ASxxx puede anunciar un prefijo determinado. La mayoría de los proveedores de tránsito e IX verifican antes de aceptar prefijos de clientes: ¿quién es el titular de este espacio y está usted autorizado a anunciarlo? Hoy en día una LOA por sí sola ya no basta, porque la mayoría de los upstreams también verifican IRR y RPKI de forma automática; por eso la LOA, el objeto de ruta IRR y el ROA deben coincidir entre sí.
Paso 2: Datos que debe proporcionar al solicitar una LOA a IMIDC
Solicite la LOA mediante un ticket de soporte con la siguiente información. Cuanto más completa esté, más rápido se procesará:
Prefix(es): 203.0.113.0/24 2001:db8:1000::/48
Origin ASN: AS64500
Company / holder: Example Networks Ltd
Upstream(s): AS64510 (Transit Provider A), AS64520 (IX route server)
Announce from: 2026-10-10
IRR source: RIPE / RADB
Technical contact: [email protected]- Prefijo: la tabla global suele aceptar como máximo IPv4 /24 e IPv6 /48 en cuanto a especificidad; los prefijos más largos probablemente serán filtrados.
- ASN de origen: el ASN desde el que anunciará y el titular legal de ese ASN.
- Upstream: nombre y ASN de su(s) proveedor(es) de tránsito; algunos exigen que su nombre figure en la LOA.
- Fecha de inicio: cuándo planea anunciar, para poder programar las actualizaciones de IRR y ROA.
Paso 3: Cree los objetos de ruta IRR (RIPE DB / RADB)
El IRR (Internet Routing Registry) es el conjunto de bases de datos de enrutamiento que muchos upstreams utilizan para generar filtros de prefijos automáticamente. Para espacio de la región RIPE, los objetos de ruta se registran en la base de datos de RIPE y requieren la autorización del titular de las direcciones, por lo que normalmente IMIDC los crea o los autoriza; para espacio que no es de RIPE se suele usar RADB. Consulte la guía «Crear objetos de ruta IRR» para ver la sintaxis. Verifíquelos con whois:
# instalar whois: Debian/Ubuntu
apt install -y whois
# CentOS/Rocky/AlmaLinux
dnf install -y whois
# objeto de ruta en la base de datos de RIPE
whois -h whois.ripe.net -T route 203.0.113.0/24
whois -h whois.ripe.net -T route6 2001:db8:1000::/48
# objeto de ruta replicado / registrado en RADB
whois -h whois.radb.net 203.0.113.0/24Asegúrese de que el campo origin muestre su ASN.
Paso 4: Asegúrese de que exista un ROA para evitar el estado RPKI inválido
Cada vez más redes descartan las rutas con RPKI inválido. Si ya existe un ROA para el bloque pero autoriza a otro ASN, su anuncio será inválido. En su ticket, solicite un ROA para su ASN, con un maxLength que cubra la longitud que anuncia. Compruebe el estado con RIPEstat:
# estado RPKI del origen AS64500 para el prefijo (API de RIPEstat)
curl -s "https://stat.ripe.net/data/rpki-validation/data.json?resource=AS64500&prefix=203.0.113.0/24" | python3 -m json.tool | grep -E '"status"|"validating_roas"' -A2valid es lo que busca; unknown significa que no hay ROA y la mayoría de las redes aún lo aceptan; invalid debe corregirse antes de anunciar.
Paso 5: Logre que los upstreams actualicen sus filtros y origine el prefijo
Los upstreams normalmente generan listas de prefijos a partir del IRR según su ASN o as-set. Algunos las actualizan a diario; otros requieren un ticket con la LOA adjunta. Una vez confirmado, origine el prefijo en su router. Ejemplo con BIRD 2:
# ejemplo de BIRD 2 (consulte la guía "Sesión BGP" para la configuración completa)
protocol static announce_v4 {
ipv4;
route 203.0.113.0/24 blackhole;
}
filter export_upstream {
if net = 203.0.113.0/24 then accept;
reject;
}
# recargar y comprobar
birdc configure
birdc show route export upstream_v4Paso 6: Compruebe la propagación con bgp.tools, bgp.he.net y RIPEstat
Una vez anunciado, un prefijo suele aparecer en la tabla global en pocos minutos. Búsquelo en bgp.tools o bgp.he.net para ver el ASN de origen, las rutas de upstream y el estado RPKI; el Routing Status de RIPEstat (stat.ripe.net) muestra cuántos colectores RIS lo ven. Desde la línea de comandos:
# quién ve el prefijo y con qué origen (RIPEstat)
curl -s "https://stat.ripe.net/data/routing-status/data.json?resource=203.0.113.0/24" | python3 -m json.tool | head -40
# cuántos peers RIS lo ven
curl -s "https://stat.ripe.net/data/visibility/data.json?resource=203.0.113.0/24" | python3 -m json.tool | grep -E '"ris_peers_seeing"|"total_ris_peers"'
# desde su router: ¿la sesión está activa y la ruta se exporta?
birdc show protocols
# probar desde fuera la accesibilidad de una dirección del prefijo
mtr -rwc 20 203.0.113.1Plazos habituales: una vez enviados los datos completos, la preparación de la LOA y de IRR/ROA suele tardar algunos días hábiles, según lo completa que esté la información y la revisión; la actualización de filtros de los upstreams tarda desde unas horas hasta unos días, según su grado de automatización; la propagación en sí tarda minutos; algunas bases de datos de geolocalización se actualizan más lentamente (consulte la guía «Geofeed»).
Preguntas frecuentes
¿Por qué mi prefijo no aparece en bgp.tools?
Compruebe que la sesión BGP esté en estado Established, que el router realmente exporte el prefijo, que el upstream haya actualizado sus filtros (búsquelo en su looking glass) y que el RPKI no sea inválido.
¿Puedo anunciar fragmentos más pequeños que un /24?
Los prefijos IPv4 más largos que /24 se filtran ampliamente en Internet, así que no. Divida el /24 en subredes internamente como prefiera y siga anunciando el /24 completo.
¿Necesito una nueva LOA si cambio de upstream o de ASN?
Cambiar de ASN requiere una nueva LOA, además de actualizar los objetos de ruta IRR y el ROA. Si solo cambia de upstream, normalmente basta con que el nuevo upstream actualice sus filtros, aunque algunos piden una LOA nueva.
¿Sigue teniendo problemas? Abra un ticket de soporte con el soporte técnico 24/7 de IMIDC: https://www.imidc.com/submitticket.php