Cuando tenemos un AS que utiliza como IGP iBGP todos los routers que hablen iBGP han des estar directamente conectados «full mesh». Ésto no siempre posible y para ello se han inventado los Route Reflectors.
Utilicemos un ejemplo
En el siguiente ejemplo vemos que R1, R2 y R3 están usando iBGP para comunicarse, pero entre R2 y R3 no hay conexión directa, luego las rutas que aprenda o publique R3 nunca llegarán a R2 y vice versa.
Despues de configurar todas las ips de todas las interfaces tenemos que configurar un IGP que no sea iBGP porque si una ruta por iBGP no están respaldadas por un IGP no serán marcadas como válidas
R1
router ospf 1
log-adjacency-changes
network 10.0.0.0 0.0.0.3 area 0
network 10.0.0.4 0.0.0.3 area 0
network 10.0.0.8 0.0.0.3 area 0
R2
router ospf 1
network 10.0.0.0 0.0.0.3 area 0
network 10.0.0.12 0.0.0.3 area 0
R3
router ospf 1
network 10.0.0.4 0.0.0.3 area 0
network 10.0.0.16 0.0.0.3 area 0
Una vez tenemos ospf funcionado y comprobado establecemos las relaciones eBGP e iBGP
R1#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
10.0.0.17 1 FULL/DR 00:00:36 10.0.0.6 FastEthernet1/0
10.0.0.13 1 FULL/DR 00:00:30 10.0.0.2 FastEthernet0/0
R1
router bgp 65000
no synchronization -> me ahorro el problema de la sincronización
bgp log-neighbor-changes
neighbor 10.0.0.2 remote-as 65000 -> iBGP
neighbor 10.0.0.6 remote-as 65000 -> iBGP
neighbor 10.0.0.10 remote-as 15000 -> eBGP
no auto-summary
R2
router bgp 65000
no synchronization
bgp log-neighbor-changes
neighbor 10.0.0.1 remote-as 65000 -> iBGP
neighbor 10.0.0.14 remote-as 25000 -> eBGP
no auto-summary
R3
router bgp 65000
no synchronization
bgp log-neighbor-changes
neighbor 10.0.0.5 remote-as 65000 -> iBGP
neighbor 10.0.0.18 remote-as 35000 -> eBGP
no auto-summary
Vemos que los peers están conectados y recibiendo actualizaciones
R1#show ip bgp summary
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.0.0.2 4 65000 19 23 19 0 0 00:02:51 2
10.0.0.6 4 65000 19 23 19 0 0 00:02:39 2
10.0.0.10 4 15000 12 18 19 0 0 00:02:30 2
Ahora bien, R2 tendrá los updates de su peer eBGP, de R1 y del peer eBGP de R1.
R3 tendrá los updates de su peer eBGP, de R1 y del peer eBGP de R1.
Pero entre R2 y R3 no habrá intercambio de rutas
R1#show ip bgp
Network Next Hop Metric LocPrf Weight Path
*> 172.16.0.0 10.0.0.10 0 0 15000 i
*> 172.17.0.0 10.0.0.10 0 0 15000 i
*>i172.18.0.0 10.0.0.14 0 100 0 25000 i
*>i172.19.0.0 10.0.0.14 0 100 0 25000 i
*>i172.20.0.0 10.0.0.18 0 100 0 35000 i
*>i172.21.0.0 10.0.0.18 0 100 0 35000 i
R2#show ip bgp
Network Next Hop Metric LocPrf Weight Path
*>i172.16.0.0 10.0.0.10 0 100 0 15000 i
*>i172.17.0.0 10.0.0.10 0 100 0 15000 i
*> 172.18.0.0 10.0.0.14 0 0 25000 i
*> 172.19.0.0 10.0.0.14 0 0 25000 i
Aquí faltan 2 rutas aprendidas por iBGP
R3#show ip bgp summary
Network Next Hop Metric LocPrf Weight Path
*>i172.16.0.0 10.0.0.10 0 100 0 15000 i
*>i172.17.0.0 10.0.0.10 0 100 0 15000 i
*> 172.20.0.0 10.0.0.18 0 0 35000 i
*> 172.21.0.0 10.0.0.18 0 0 35000 i
Aquí lo mismo que con R2
Para que haya comunicación iBGP entre R2 y R3 hay que configurarlos como clientes route reflectors. Para ello nos vamos al router que conecta a ellos dos.
R1#
router bgp 65000
neighbor 10.0.0.2 route-reflector-client
neighbor 10.0.0.6 route-reflector-client
Ahora en R2 y R3 deberíamos ver todas las rutas.
R2#show ip bgp
Network Next Hop Metric LocPrf Weight Path
*>i172.16.0.0 10.0.0.10 0 100 0 15000 i
*>i172.17.0.0 10.0.0.10 0 100 0 15000 i
*> 172.18.0.0 10.0.0.14 0 0 25000 i
*> 172.19.0.0 10.0.0.14 0 0 25000 i
*>i172.20.0.0 10.0.0.18 0 100 0 35000 i
*>i172.21.0.0 10.0.0.18 0 100 0 35000 i
R3#show ip bgp
Network Next Hop Metric LocPrf Weight Path
*>i172.16.0.0 10.0.0.10 0 100 0 15000 i
*>i172.17.0.0 10.0.0.10 0 100 0 15000 i
*>i172.18.0.0 10.0.0.14 0 100 0 25000 i
*>i172.19.0.0 10.0.0.14 0 100 0 25000 i
*> 172.20.0.0 10.0.0.18 0 0 35000 i
*> 172.21.0.0 10.0.0.18 0 0 35000 i
A continuación os dejo un ejemplo hecho con gns3 y con sus respectivas configuraciones por si alguien quiere practicar. Link

