(Book) Networking with MikroTik RouterOS: A Practical Approach to Understanding and Implementing RouterOS
Study material for the MTCNA Certification Course, updated to RouterOS v7
$19,97
Entendiendo el Route Reflector en BGP MikroTik: El truco BGP que reduce sesiones
- Darwin Gabriel Barzola Abad
- No hay comentarios
- Comparte este artículo
Facebook
Twitter
LinkedIn
WhatsApp
Telegram
Route Reflector en BGP MikroTik resuelve el problema de escalabilidad del full-mesh iBGP en redes grandes. En ISP, WISP y backbones corporativos, el número de sesiones internas crece en forma cuadrática. Por tanto, la operación se vuelve frágil y costosa.
Con un reflector de rutas (RR), los iBGP peers no necesitan formar vecindad entre todos. En su lugar, los clientes iBGP establecen una sesión con uno o varios RRs. Luego, el RR refleja las rutas a los demás clientes dentro del mismo clúster.
Este patrón mantiene la política centralizada y reduce la complejidad. Además, disminuye la convergencia percibida cuando el plano de control se congestiona. Aun así, el diseño exige rigor.
Cuándo usar un RR
Resulta ideal cuando el número de routers iBGP supera algunos decenas. También aparece cuando la topología incluye anillos, núcleos jerárquicos y sitios distantes. En redes con MPLS L3VPN, EVPN o grandes políticas de filtrado, la carga del plano de control se incrementa. Entonces, el RR reduce sesiones, CPU y memoria en Routers.
Si el RR se ubica mal, la selección de rutas puede ser subóptima. Por eso, se recomienda implementar dos RRs por clúster, preferiblemente en diferentes dominios de falla.
Asimismo, conviene mantener la conectividad iGP estable y medir latencia hacia los RRs. Además, documenta los clústeres, los IDs y la relación con áreas OSPF o niveles IS-IS. En resumen, úsalo para escalar iBGP, mantener políticas claras y simplificar operaciones, sin perder de vista la resiliencia.
Fundamentos teóricos
Full-mesh iBGP y RFC 4456
El Route Reflector en BGP MikroTik nace para evitar el requerimiento de full-mesh iBGP. En iBGP, por defecto, un router no reanuncia rutas aprendidas por iBGP a otro vecino iBGP. Por tanto, garantizar visibilidad exige una sesión entre todos los pares.
La RFC 4456 introduce el Route-Reflector y sus clientes. El RR puede reanunciar rutas iBGP a otros clientes iBGP. Para evitar bucles, agrega ORIGINATOR_ID (el ID del origen) y CLUSTER_LIST (la cadena de clústeres visitados). Si un RR ve su propio Cluster-ID en CLUSTER_LIST, descarta la ruta. Además, el RR no modifica NEXT_HOP salvo política explícita. Por consiguiente, la interacción con el iGP resulta crítica. La sincronización antigua ya no se usa; hoy el iGP solo debe alcanzar los next-hops.
Finalmente, ten presente que la decisión BGP sigue los atributos estándar: preferencia local, longitud de AS-PATH, MED, costo IGP hacia NEXT_HOP y otros.
Roles, clústeres y jerarquías
Un Route Reflector define tres roles: RR, RR-Client y Non-Client iBGP. Un clúster es el conjunto servido por un RR, identificado por Cluster-ID. Puedes tener clústeres anidados para escalar jerárquicamente. Por ejemplo, RRs de borde pueden alimentar RRs de núcleo. Así limitas la propagación de rutas y las políticas más complejas.
Ventajas
Beneficios operativos y de escalabilidad
RR aporta dos beneficios inmediatos: menos sesiones iBGP y convergencia más controlada. Como consecuencia, los routers consumen menos CPU y memoria. En ISP y WISP, esto permite usar CPE o PE más económicos en el borde. Además, centralizas políticas en el RR y reduces errores de configuración.
También simplificas cambios globales, como blackholes BGP o anuncios de mantenimiento. En redes corporativas, el RR facilita segmentaciones por regiones y data centers. Incluso ayuda a probar nuevas políticas en un clúster de laboratorio.
Finalmente, la operación diaria mejora. Los NOC tienen menos sesiones que monitorear, menos alarmas por inestabilidad y más claridad en la propagación de rutas. Con buenas métricas, el tiempo de resolución de incidentes disminuye.
Desventajas / limitaciones
Riesgos y escenarios no recomendados
Puede introducir rutas subóptimas cuando la topología física no coincide con la lógica. Si el RR refleja caminos lejanos, el tráfico puede tomar desvíos costosos. Además, el RR concentra control y se vuelve un punto crítico si no hay redundancia. Por eso, usa al menos dos RRs por clúster, con Cluster-ID distintos. Otro riesgo es el “path hiding”. Un RR puede ocultar rutas alternativas por el orden de selección. La consecuencia es una resiliencia inferior frente a fallas simultáneas.
Cuadro comparativo (ventajas versus desventajas)
Resumen ejecutivo y matriz
Equilibra simplicidad y control, siempre que apliques redundancia y políticas claras. Para decidir, evalúa tamaño, topología física, iGP subyacente y criticidad del tráfico. Además, define objetivos de convergencia y mide CPU en candidatos a RR.
La siguiente matriz sintetiza factores clave. Después, detallo recomendaciones para cada caso. También considera compliance y auditoría. Centralizar políticas en RRs facilita evidencia y trazabilidad. Sin embargo, incrementa el nivel de exposición. Por lo tanto, integra listas de control, plantillas y revisión por pares.
Finalmente, recuerda probar en laboratorio con capturas BGP y fallas simuladas.
Aspecto | Ventaja principal | Desventaja potencial | Mitigación |
Escalabilidad | Menos sesiones iBGP | Path hiding | Multipath y jerarquía |
Operación | Políticas centralizadas | Exposición del RR | Hardening y RBAC |
Convergencia | Menos churn en hojas | Subóptimos | Ubicación de RR |
Costos | PE más livianos | Capex en RRs | Virtualización y HA |
Resiliencia | Clústeres redundantes | Split-brain | Cluster-ID correctos |
Casos de uso reales
ISP regional y WISP con backbone mixto
La configuración de Route Reflector se adopta con frecuencia en ISP regionales que combinan fibra y radio. Un caso típico coloca dos RRs en el core, separados por ciudad. Cada POP se conecta como cliente, y el iGP usa OSPF con áreas por región. Además, el tránsito y los IXPs llegan a routers de borde.
Estos PE anuncian prefijos agregados al RR, que los refleja a todos los clientes. En un WISP, la idea es similar, aunque el iGP suele ser OSPF con enlaces inalámbricos variables. Por tanto, se recomienda medir jitter hacia los RRs y ajustar timers BGP con cuidado.
En redes corporativas, dos RRs residen en data centers distintos. Las sedes remotas son clientes y aprenden rutas inter-sitio de manera controlada. Finalmente, en laboratorios, un par de RRs virtuales permite probar políticas de comunidades, blackhole y prepends antes de desplegar en producción.
Tablas comparativas
RR vs confederaciones vs route servers
Compite con confederaciones BGP en grandes operadores. Las confederaciones dividen el AS en sub-AS internos, lo que mejora escalabilidad, pero aumenta complejidad de operación. Por otro lado, un route server se usa en IXPs y no empuja tráfico; solo facilita intercambio.
En redes de un solo AS, el RR suele ser la opción más pragmática. La tabla resume diferencias y apoya decisiones. Después de compararlas, considera tus requerimientos de políticas y auditoría. Además, estudia la curva de aprendizaje del equipo de NOC.
Tecnología | Dónde aplica | Complejidad | Escalabilidad | Trazabilidad | Caso típico |
RR iBGP | ISP/WISP/Enterprise | Baja-Media | Alta | Alta | Núcleo único |
Confederaciones | Tier-1/Tier-2 | Alta | Muy alta | Media | AS enormes |
Route Server | IXP | Baja | Media | Media | Intercambio en puntos neutros |
Ejercicios prácticos / laboratorio
Topología, objetivos y pruebas
El RR se validará en la siguiente topología mínima. Dos RRs (R1 y R2) en data centers distintos. Tres clientes iBGP (C1, C2, C3) en POPs regionales.
El iGP será OSPF. Los bordes C1 y C2 tienen tránsito eBGP. Objetivos: formar vecindades, propagar rutas, verificar atributos y simular fallas. Además, podrás observar path hiding y subóptimos con enlaces asimétricos.
Diagrama:
C1 —\
\ /— C2
R1 === R2
/ \— C3
C1/C2: eBGP tránsito; todos: iBGP con R1 y R2
Pruebas básicas: caída de un RR, pérdida de un next-hop, cambio de local-preference, activación de multipath y blackhole controlado con comunidad. Finalmente, captura mensajes BGP OPEN, UPDATE y KEEPALIVE para revisar atributos. Así confirmarás la lógica de Route Reflector en BGP MikroTik y su interacción con el iGP.
Configuración base en MikroTik
En RouterOS v7 usa plantillas limpias. Primero, define BGP y OSPF. Luego, crea roles RR y clientes. Aplica políticas para local-pref y comunidades. A continuación, ejemplos mínimos.
MikroTik RouterOS v7 (RR):
/routing bgp template
add name=RR router-id=10.0.0.1 as=65000
/routing bgp connection
add name=to-C1 template=RR remote.address=10.0.1.1 \
remote.as=65000 route-reflector=yes
add name=to-C2 template=RR remote.address=10.0.2.1 \
remote.as=65000 route-reflector=yes
add name=to-C3 template=RR remote.address=10.0.3.1 \
remote.as=65000 route-reflector=yes
/routing bgp instance set default as=65000 router-id=10.0.0.1
MikroTik (cliente iBGP):
/routing bgp template add name=CLIENT router-id=10.0.X.1 as=65000
/routing bgp connection
add name=to-RR1 template=CLIENT remote.address=10.0.0.1 remote.as=65000
add name=to-RR2 template=CLIENT remote.address=10.0.0.2 remote.as=65000
Buenas prácticas y recomendaciones
Seguridad, optimización y escalado
El uso de Route Reflector en BGP MikroTik exige higiene operativa. Implementa dos RRs por clúster y coloca cada uno en dominios de energía y enlaces distintos. Después, fija Cluster-ID únicos y documentados.
En cuanto a seguridad, usa TCP-AO cuando sea posible o MD5 heredado. Limita la gestión por listas de control. Además, valida prefijos con RPKI en los bordes y propaga solo agregados internos.
Para optimización, define comunidades estándar: blackhole, preferencia regional y no-export. También implementa local-preference consistente y next-hop-self donde aplique.
En escalado, considera jerarquía de RRs y divide clústeres por latencia. Finalmente, habilita multipath en trayectos equivalentes. Con ello, reduces “hot spots” y mejoras el uso de enlaces. Repite pruebas tras cada cambio, y conserva plantillas versionadas en un repositorio controlado.
Errores comunes y cómo evitarlos
Fallos frecuentes y soluciones rápidas
El Route Reflector falla cuando el iGP no alcanza los next-hops. Por eso, verifica reachability antes de culpar al BGP. Otro error clásico es usar el mismo Cluster-ID en clústeres distintos. Esa práctica provoca descartes inesperados. También se olvida next-hop-self en PE internos, lo que rompe el reenvío.
En políticas, cuidado con filtros agresivos que bloquean comunidades o MED. Además, vigila timers muy cortos que provocan flapping en enlaces inestables. Cuando veas “path hiding”, habilita multipath o revisa bestpath en RRs. Si detectas subóptimos, reubica RRs más cerca del tráfico crítico. Finalmente, no dejes a un RR como único punto de administración.
Aplica HA, copias de configuración y pruebas periódicas de failover. Con disciplina operativa, estos problemas se vuelven excepciones y no incidentes recurrentes.
Conclusiones
Síntesis y visión a futuro
Configurar Route Reflector en BGP MikroTik ofrece una vía directa para escalar iBGP sin adoptar confederaciones. Reduce sesiones, simplifica políticas y mejora la operación diaria. Sin embargo, el diseño importa.
La ubicación del RR, el iGP subyacente y la redundancia definen el resultado. A corto plazo, recomienda implementar dos RRs por clúster, con plantillas de políticas y monitoreo. A medio plazo, evalúa jerarquías y multipath para evitar “path hiding”.
A largo plazo, integra validación RPKI, telemetría y automatización. Con ese enfoque, tu backbone se mantiene estable, auditable y preparado para nuevos servicios. Finalmente, prueba todo en laboratorio antes de llevarlo a producción.
Breve cuestionario de conocimientos
¿Qué te pareció este artículo?
¿Te atreves a evaluar tus conocimientos aprendidos?
Libros recomendados para éste artículo
Libro BGP y MPLS RouterOS v7
Material de estudio para el Curso de Certificación MTCINE actualizado a RouterOS v7
$19,97
Autoestudio MikroTik
Estudia las certificaciones MikroTik a tu propio ritmo
Autoestudio
Aprende a tu propio ritmo
advertisement (anuncio)
Artículos Relacionados
MikroLABs
Otros temas que te pueden interesar
Cómo funciona el DHCP Alert y para qué sirve
abril 22, 2026
Qué es el Burst y cómo funciona en redes
abril 21, 2026
advertisement (anuncio)
Escríbenos por WhatsApp (+593 98 700 0604)
¿Quieres sugerir un tema?
Todas las semanas posteamos nuevo contenido. Quieres que tratemos sobre algo específico?
Próximos Cursos
Libros MikroTik (español)
advertisement (anuncio)
MONARC Latin America: Soluciones Tecnológicas - monarclatinamerica.com.gt - Guatemala
1
Haz clic para chatear