Implementación de BGP en MikroTik sin errores

Si operas un ISP o una red empresarial con más de una salida a internet, tarde o temprano llegas a BGP. Es el protocolo que sostiene el ruteo entre sistemas autónomos: anuncia tus prefijos al mundo, recibe la tabla de tus upstreams y decide por dónde entra y sale cada paquete. El problema es que una implementación de BGP en MikroTik mal armada no falla con un error claro y ruidoso; falla filtrando rutas que no debía, reanunciando tránsito ajeno, o dejando caer una sesión en plena hora peak sin que nadie sepa por qué. Este artículo recorre cómo configurar BGP en RouterOS 7 de forma correcta, con los comandos reales del menú /routing/bgp y los controles que separan una red estable de un incidente evitable.

Qué cambió en BGP con RouterOS 7

Si vienes de RouterOS 6, lo primero es desaprender la estructura vieja. El stack de ruteo se reescribió por completo y BGP dejó de vivir en un solo menú de peers. En RouterOS 7 la configuración de BGP en MikroTik se reparte en tres piezas claras:

• /routing/bgp/instance: define tu identidad como sistema autónomo. Aquí van tu as (número de AS de 32 bits, en formato AS-Plain o AS-Dot) y el router-id. Routers con el mismo router-id se agrupan en una instancia.
• /routing/bgp/connection: cada sesión con un vecino. Es el menú donde pasarás la mayor parte del tiempo: direcciones remota y local, rol, filtros y familias de direcciones.
• /routing/bgp/template: parámetros comunes que varias conexiones heredan vía la propiedad templates. Clave cuando tienes decenas de peers con la misma política.

El estado ya no se mira en el mismo lugar donde configuras: las sesiones activas viven en /routing/bgp/session, de solo lectura. Esta separación entre configuración y estado es una de las mejores cosas de RouterOS 7 y conviene aprovecharla al diagnosticar.

Antes del primer peer: diseño y prerrequisitos

La mayoría de los errores de BGP no nacen en BGP. Nacen antes. Verifica esto antes de tocar /routing/bgp:

• IGP resuelto primero. En iBGP los next-hops se resuelven a través de rutas del IGP. Si tu OSPF no está convergido y estable, tus rutas BGP quedarán inactivas por next-hop irresoluble. El orden correcto es IGP sólido, después BGP encima.
• Router-id explícito. No lo dejes al azar. Usa una loopback estable como identificador; evitas que un cambio de interfaz te reinicie sesiones.
• Números de AS correctos. Ten claro tu ASN propio y el de cada vecino. Un remote.as equivocado hace que la sesión ni siquiera pase de OpenSent.
• Autenticación acordada. Si el upstream pide firma TCP MD5 (tcp-md5-key), coordínala de antemano; sin ella la sesión no levanta.

Configurar BGP en MikroTik paso a paso

Veamos una sesión eBGP típica contra un upstream. Primero la instancia con tu identidad, luego la conexión. El detalle importante en RouterOS 7 es local.role: es obligatorio y define el comportamiento del peer según RFC 9234 (roles como ebgp, ibgp, ebgp-customer, ebgp-provider).

/routing/bgp/instance
add name=default as=65010 router-id=10.255.0.1

/routing/bgp/connection
add name=upstream-A instance=default \
    remote.address=203.0.113.1 remote.as=64500 \
    local.role=ebgp \
    afi=ip \
    output.filter-chain=bgp-out-upstream \
    input.filter=bgp-in-upstream \
    output.network=mis-prefijos \
    tcp-md5-key=clave-acordada

Los prefijos propios que quieres anunciar se declaran en una address-list referenciada por output.network. Ojo con un detalle real de RouterOS: la red solo se anuncia si existe una ruta IGP que la respalde y su atributo ORIGIN queda en IGP; otros métodos de distribución dejan el ORIGIN en INCOMPLETE. Para un peer iBGP contra un route reflector la forma es la misma, cambiando el rol:

/routing/bgp/connection
add name=ibgp-rr instance=default \
    remote.address=10.255.0.2 remote.as=65010 \
    local.role=ibgp \
    nexthop-choice=force-self

Para vecinos que no están directamente conectados (por ejemplo, peering multihop hacia una loopback), habilita multihop=yes; esto también ajusta cómo se aceptan los next-hop fuera de la red local.

Los filtros: el 90% de los errores de BGP están aquí

Aquí está la parte que separa una implementación de BGP en MikroTik profesional de una que provoca incidentes. BGP en RouterOS acepta y anuncia todo por defecto. Si no defines input.filter ni output.filter-chain, tu router aceptará cualquier prefijo del vecino y le reanunciará todo lo que sepa. Sin filtro de salida, un router mal configurado puede convertirse en tránsito accidental entre dos upstreams y colapsar bajo la tabla completa de internet.

Los filtros viven en /routing/filter/rule como cadenas encadenadas por nombre. Un mínimo defendible: en entrada, descarta prefijos demasiado específicos y bogons; en salida, anuncia solo tus propios prefijos y nada más.

/routing/filter/rule
add chain=bgp-out-upstream \
    rule="if (dst in 198.51.100.0/22) { accept } reject"

add chain=bgp-in-upstream \
    rule="if (dst-len > 24) { reject }"
add chain=bgp-in-upstream \
    rule="accept"

RouterOS 7 además ofrece un arma específica para escala de operador: input.filter-nlri y input.accept-nlri. A diferencia del input.filter normal —que rechaza el prefijo pero igual lo parsea, lo guarda en memoria y lo deja visible como "not active, filtered"— estos filtran el NLRI antes de almacenarlo, reduciendo el uso de memoria de forma significativa. En un router que recibe full table de varios upstreams, la diferencia es real. Complementa con input.limit-process-routes-ipv4 para poner un techo defensivo a la cantidad de rutas que un vecino puede empujarte.

Estabilidad de la sesión: hold-time, BFD y detección de caídas

Una sesión BGP que "se cae sola" casi siempre es un problema de temporizadores o de detección de fallas, no de BGP en sí. Los parámetros que controlan esto en /routing/bgp/connection:

Propiedad	Qué hace	Nota práctica
hold-time	Si no llegan KEEPALIVE/UPDATE en ese periodo, la sesión se cierra	Se negocia el menor valor de ambos peers; rango 3s–65535s
keepalive-time	Intervalo entre keepalives	Por defecto, 1/3 del hold-time
use-bfd	Usa BFD para detectar la caída del enlace en milisegundos	Mucho más rápido que esperar el hold-time completo
remote.ttl / local.ttl	Límite de saltos del TCP (GTSM)	remote.ttl=255 restringe a vecinos directos; solo afecta eBGP

Si tu red no puede tolerar decenas de segundos de convergencia tras una caída de enlace, BFD es la respuesta: en vez de esperar que expire el hold-time, la sesión se declara caída casi de inmediato y el ruteo reconverge. Combínalo con un hold-time razonable —ni tan bajo que una microcongestión te tire la sesión, ni tan alto que un corte real quede colgado.

Route reflectors para no escalar iBGP a la fuerza

iBGP exige malla completa: cada router habla con todos. En un ISP eso no escala. La instancia BGP puede actuar como route reflector definiendo cluster-id y usando el rol ibgp-rr en las conexiones hacia los clientes de reflexión. Así centralizas la distribución de rutas internas sin llenar la red de sesiones. Es una decisión de arquitectura: dónde poner los reflectores, cuántos por redundancia y cómo evitar loops de reflexión son preguntas de diseño, no de copiar comandos. Si te interesa el detalle de cómo abordamos estos escenarios, revisa nuestro trabajo con BGP en RouterOS.

Verificar antes de dar por cerrado

Una implementación no está terminada hasta que la verificas. Después de levantar la sesión:

• Estado de la sesión: /routing/bgp/session/print debe mostrar la sesión en established. Si queda en un estado intermedio, revisa AS, direcciones y MD5.
• Rutas recibidas y anunciadas: confirma en /routing/route que recibes lo esperado y —crítico— que solo anuncias tus prefijos. Verifica desde el lado del vecino o con un looking glass externo qué ve internet de ti.
• Sin fugas de tránsito: asegúrate de no estar reanunciando rutas de un upstream hacia otro. Este es el error clásico que genera incidentes de reputación y saturación.
• Prueba de failover: baja controladamente un enlace y mide cuánto tarda la reconvergencia. Si es demasiado, revisa BFD y temporizadores.

Errores frecuentes de BGP que vemos en terreno

• Sin filtros de salida. El más peligroso. Anunciar de más convierte tu red en tránsito no deseado.
• Confiar en el default de aceptar todo en entrada. Aceptar prefijos más específicos que /24 o bogons ensucia tu tabla y te expone a hijacks.
• Ignorar el next-hop en iBGP. Rutas iBGP inactivas casi siempre son next-hop no resuelto por el IGP. Ahí entra nexthop-choice=force-self o un IGP bien armado.
• Hold-time sin BFD en enlaces críticos. Convergencia lenta que se siente como "internet lento" en cada corte.
• No dimensionar memoria para full table. Recibir varias tablas completas sin filter-nlri ni límites puede tumbar routers chicos.

Conversemos tu diseño BGP

BGP no es un protocolo que se "prende" y funciona: es una decisión de arquitectura donde el filtrado, la política de anuncios y la estrategia de failover pesan tanto como la sintaxis. Una configuración de BGP en MikroTik correcta te da control fino sobre por dónde entra y sale tu tráfico; una descuidada te expone a fugas, hijacks y caídas silenciosas. Si estás diseñando tu peering, migrando de RouterOS 6 a 7, o quieres una segunda opinión sobre tus filtros antes de anunciar a producción, en MikroTik Chile trabajamos exactamente eso todos los días. Revisa nuestra consultoría en ingeniería de redes MikroTik y cuéntanos tu topología. Conversemos, de ingeniero a ingeniero, sobre cómo dejar tu BGP estable, documentado y listo para crecer.