BGP 09 Route Reflector Theory

Just a reminder that if we look at the BGP summary command we can see how many routes we are recieving from our neighbour, in this case R1 is receiving 4 routes from R5

tag(s)

route aggregation, state / pfxrcd, aggregate-address, resetting clearing bgp peer connections, internal bgp synchronization, full meshes and route reflectors, transit area,

BGP 10 Route Reflector Lab

We are advertising R4's loopback into BGP, the route shows as as a local originated route (weight metric 32768)

As expected R3 can see the route with the correct next hop (as it is an eBGP peer), but R1 can see the route but note its not best, only valid ... due to the next hop address being retained from the eBGP peering that R3 has with R4 .... (as a route learnt from an eBGP peer retains the next hop address when advertised to an iBGP peer)

R1 cannot reach R4! So we can fix that with the next-hop-self on R3 (under BGP with the neighbour command)

And as expected R2 has no BGP routes, 

why ....... because R1 is learning that route from another iBGP peer - this is where BGP split horizon is kicking in, R1 (an iBGP peer) cannot learn about a route from an iBGP and then advertise it to another iBGP peer.

tag(s)

route reflector clients, route refresh, soft reset,clusters originator id attribute