Configuración de Route Reflectors para eliminar la necesidad de full-mesh iBGP.

Regla iBGP: Los prefijos enviados a un vecino iBGP no son reenviados a otro vecino por iBGP.

Solucion: Los RR recibe una ruta de un vecino iBGP y la reenvia a otro vecino iBGP.

Izquierda: Caso comun de iBGP. / Derecha: Solucion con RR.

Router R1 (RR): Sera el encargado de enviar todas las rutas iBGP, no todos los Routers Clients tendran que hacer conexion entre ellos, solo entre el Router R1 ademas las rutas que reenvia Router R1 (RR) las reenviara sin modificaciones.

Pueden existir routers que no son clientes adentro del Cluster.

Atributos de loop prevention

Al reflejar rutas, el RR agrega Originator ID (Router-ID del router que originó la ruta) y Cluster List (Cluster IDs recorridos). Estos atributos previenen loops en un entorno con RR. El Cluster ID equivale al Router-ID del RR por defecto.

Redundancia y jerarquía

Se puede tener más de un RR por cluster (redundancia), y un RR puede ser cliente de otro RR (RR jerárquicos). También pueden coexistir no-clientes en el mismo entorno.

Recordatorio de las reglas de reflexión

  • Ruta aprendida de un no-cliente iBGP → se refleja solo a clientes.
  • Ruta aprendida de un cliente → se refleja a todos (clientes y no-clientes), excepto al cliente que la originó.
  • Ruta aprendida de un eBGP → se refleja a todos (clientes y no-clientes).

Consecuencia: dos no-clientes no reciben mutuamente sus rutas a través del RR, por lo que siguen necesitando peering directo entre ellos.

  • Explicacion de regla:

R3 no le dara las rutas aprendidas de R5 a R7 debido a que ambos no son clientes. un no-cliente no le dara rutas a otro no-cliente.

Configuración

El comando route-reflector-client va únicamente en el Route Reflector. Los clientes no llevan configuración especial.

  • Comando: R1(config-router)# neighbor <ip-cliente> route-reflector-client
  • Ejemplo: R1(config-router)# neighbor 2.2.2.2 route-reflector-client

Ejemplo

Caso 1

R1 es el route reflector; R2 y R3 son sus clientes. R1 designa a ambos como clientes; R2 y R3 solo configuran su sesión iBGP normal hacia R1.

R1(config)# router bgp 65001
R1(config-router)# neighbor 2.2.2.2 remote-as 65001
R1(config-router)# neighbor 2.2.2.2 route-reflector-client
R1(config-router)# neighbor 3.3.3.3 remote-as 65001
R1(config-router)# neighbor 3.3.3.3 route-reflector-client
R2(config)# router bgp 65001
R2(config-router)# neighbor 1.1.1.1 remote-as 65001

Con esto, R2 y R3 ya no necesitan peerear entre sí: el RR les refleja mutuamente las rutas.

Caso 2

R2(config)# router bgp 20
R2(config-router)# neighbor 3.3.3.3 remote-as 20
R2(config-router)# neighbor 3.3.3.3 update-source loopback 1
R2(config-router)# neighbor 3.3.3.3 next-hop-self
R4(config)# router bgp 20
R4(config-router)# neighbor 3.3.3.3 remote-as 20
R4(config-router)# neighbor 3.3.3.3 update-source loopback 1
R4(config-router)# neighbor 3.3.3.3 next-hop-self
R3(config)# router bgp 20

! --- Sesión iBGP con R2 ---
R3(config-router)# neighbor 2.2.2.2 remote-as 20
R3(config-router)# neighbor 2.2.2.2 update-source loopback 1
R3(config-router)# neighbor 2.2.2.2 route-reflector-client

! --- Sesión iBGP con R4 ---
R3(config-router)# neighbor 4.4.4.4 remote-as 20
R3(config-router)# neighbor 4.4.4.4 update-source loopback 1
R3(config-router)# neighbor 4.4.4.4 route-reflector-client

Verificación

  • Confirmar que un prefijo se recibió de un cliente RR y ver Originator ID / Cluster List: R1# show ip bgp <ipv4-RR>

La salida detallada muestra la información de Originator ID y Cluster List de las rutas reflejadas.

  • Ver el estado de las sesiones iBGP con los clientes: R1# show ip bgp summary