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
Impresionante. Una forma sencilla de explicar claramente que es route reflector.
ResponderEliminarAgradezco tu comentario
ResponderEliminarMuy Bueno!!!! Sirvio de Mucho!!!
ResponderEliminarTengo la duda del BGP DAMPING, este depende del Route Reflector?
No, eso sirve para castigar los enlaces que "flapean".
ResponderEliminarNo soy el mejor para explicártelo ya que no tengo experiencia en ello pero te dejo la info oficial http://www.cisco.com/en/US/docs/ios/12_2/ip/configuration/guide/1cfbgp.html#wp1002395 y disculpa por haber tardado tanto en contestar.
Un saludo
Hola, la verdad es que es muy claro, pero tengo un problema. He configurado BGP en una red parecida a la tuya, pero no consigo que se publiquen los eBGP dentro del iBGP. Es decir, gracias a OSPF puedo alcanzar cualquier punto del AS pero desde un nodo no puedo alcanzar un AS que esté conectado a través de otro.No se si me he explicado bien. Es como si en tu ejemplo no pudiera alcanzar la red 172.16.0.0 desde R2 ya que el comando sh ip bgp no me muestra nada por pantalla.
ResponderEliminarUn saludo.
Claro esa red no es alcanzable tienes que poner en el bgp de R1
ResponderEliminarneighbor (R3) next-hop-self
neighbor (R2) next-hop-self
Espero que el comentario no llegue muy tarde
un saludo!
Muy sencillo, muy claro.
ResponderEliminarGracias
Hola luis, tengo entendido que con OSPF no hace falta utilizar el comando next-hop-self, que ya se encargaba OSPF de reenviar las rutas. Sigo con el mismo problema, y es que al hacer Show ip Bgp en cualquier router este no muestra nada, pero lo que significa nada, ni siquiera una línea de error.
ResponderEliminarUn saludo
no sync prueba con eso, asi una ruta que no este en el igp no tendras problemas si alcanzas al next hop en bgp.
ResponderEliminarUn saludo