Cómo solucionar el AS-path prepending rechazado en BGP (BIRD y FRR)

El AS-path prepending es la forma estándar de dirigir el tráfico entrante en una configuración BGP multihomed: se repite el propio ASN en los anuncios hacia un upstream para que esa ruta parezca más larga y menos preferida. Muchos operadores se encuentran con que el peer rechaza su AS-path prepending en BGP: el prefijo desaparece de ese upstream o el prepend no tiene ningún efecto. Esta guía explica las causas habituales (límites de longitud del path, filtros de AS-path, comprobaciones IRR/RPKI) y muestra configuraciones correctas de BIRD 2 y FRRouting para Debian/Ubuntu y CentOS/Rocky/AlmaLinux. Los ejemplos usan el ASN local 64500, el upstream 203.0.113.1 (AS64496) y el prefijo 198.51.100.0/24; reemplácelos por sus valores reales.

Paso 1: Confirme que el AS-path prepend está siendo rechazado

Primero compruebe que su router realmente envía la ruta con prepend; luego busque en los registros mensajes NOTIFICATION o reinicios de sesión, y use un looking glass público para ver qué AS paths recibe el resto de Internet. Si lo que usted anuncia es correcto pero desde fuera no se ve ninguna ruta a través de ese upstream, el upstream (o una red más lejana) la está filtrando.

# BIRD 2
birdc show route 198.51.100.0/24 export upstream1 all
journalctl -u bird --since "1 hour ago" --no-pager
# FRRouting
vtysh -c "show bgp ipv4 unicast neighbors 203.0.113.1 advertised-routes"
vtysh -c "show bgp ipv4 unicast neighbors 203.0.113.1" | grep -iE "state|prefix|notification"

curl -s "https://stat.ripe.net/data/looking-glass/data.json?resource=198.51.100.0/24" | grep -o '"as_path":"[^"]*"' | sort | uniq -c

Paso 2: Haga prepend solo de su propio ASN

El error más común es hacer prepend de un ASN ajeno (el del upstream o el de otra red) o insertarlo al final del path, lo que cambia el AS de origen. Los upstreams suelen exigir que el primer ASN coincida con el ASN del vecino y validan el origen contra su as-set; los ASN ajenos en el path parecen un secuestro (hijack) y la ruta se descarta. Los ASN privados (64512–65534) también se filtran con frecuencia. Esta es la configuración correcta de BIRD 2; BIRD añade el ASN local una vez más al exportar por eBGP:

# /etc/bird/bird.conf (BIRD 2)
filter export_upstream1 {
  if net = 198.51.100.0/24 then {
    bgp_path.prepend(64500);   # own ASN only
    bgp_path.prepend(64500);
    accept;
  }
  reject;
}

protocol bgp upstream1 {
  local as 64500;
  neighbor 203.0.113.1 as 64496;
  ipv4 {
    import none;
    export filter export_upstream1;
  };
}

birdc configure

Paso 3: Configure el AS-path prepending en FRRouting

FRR aplica los prepends con un route-map de salida. Después, haga un soft reset de salida (soft out) para que la sesión permanezca activa.

vtysh
configure terminal
ip prefix-list MY-NETS seq 10 permit 198.51.100.0/24
route-map UPSTREAM-OUT permit 10
 match ip address prefix-list MY-NETS
 set as-path prepend 64500 64500
exit
route-map UPSTREAM-OUT deny 100
exit
router bgp 64500
 address-family ipv4 unicast
  neighbor 203.0.113.1 route-map UPSTREAM-OUT out
 exit-address-family
end
write memory
clear bgp ipv4 unicast 203.0.113.1 soft out

Paso 4: Mantenga el AS path lo bastante corto para evitar filtros de longitud

Muchas redes descartan rutas con AS paths demasiado largos, y algunas limitan cuántas veces puede repetirse un mismo ASN. De uno a tres prepends bastan para influir en la selección de rutas; a partir de cinco casi no hay beneficio y aumenta el riesgo de filtrado. Otra causa frecuente es un filtro de AS-path demasiado estricto en el upstream, por ejemplo una expresión regular como ^64500$, que rechaza "64500 64500 64500". Pida al upstream que utilice algo como ^(64500_)+$.

Compruebe el AS path que realmente envía:

birdc show route 198.51.100.0/24 export upstream1 all | grep BGP.as_path
vtysh -c "show bgp ipv4 unicast 198.51.100.0/24"

Paso 5: Revise los objetos route del IRR y RPKI/ROA

El prepending no cambia el AS de origen, pero el upstream rechazará igualmente el prefijo si no tiene un objeto route en el IRR, si no figura en el as-set que registró con ellos o si el ASN de origen o la longitud máxima del ROA no coinciden. Compruébelo con:

whois -h whois.radb.net -- '-i origin AS64500'
whois -h whois.ripe.net -- '-T route 198.51.100.0/24'
curl -s "https://stat.ripe.net/data/rpki-validation/data.json?resource=AS64500&prefix=198.51.100.0/24"

El estado RPKI debe ser valid; si es invalid, corrija primero el ROA. Las listas de filtros de los upstreams suelen actualizarse automáticamente al cabo de un tiempo, o puede solicitar al upstream una actualización manual.

Preguntas frecuentes

Hice prepend, pero el tráfico no cambió

Las redes remotas pueden preferir rutas mediante Local Preference, que tiene prioridad sobre la longitud del AS path, por lo que el prepending no tiene efecto en ellas. Pruebe con las comunidades del upstream o cambie la granularidad de los prefijos que anuncia.

¿Puedo hacer prepend del ASN de mi upstream?

No. Repita únicamente su propio ASN. Añadir otros ASN rompe la autenticidad del path y la mayoría de las redes descartarán la ruta.

¿Puede IMIDC ayudarme con el prepending?

Si anuncia sus propias IP o IP alquiladas desde servidores de IMIDC, describa sus requisitos en un ticket de soporte y nuestros ingenieros revisarán la sesión, los filtros y el estado de IRR/ROA.

¿Sigue sin resolverlo? Abra un ticket con el soporte técnico 24/7 de IMIDC.