Hello Samad
I’m not completely clear on which router can see which prefixes, and what you were expecting to see. However, keep the following in mind:
iBGP does not advertise prefixes from one iBGP neighbor to another iBGP neighbor. This is called the iBGP split-horizon rule. So in a topology like the one in the lesson, if you have a peering between R1 and R2 and a peering between R2 and R3, R2 will not advertise to R3 anything it learns from R1. There are two solutions to this:
- Create a full mesh of iBGP peerings within the AS. This is actually a requirement for iBGP.
- Alternatively, you can make use of a route reflector, which avoids the full mesh iBGP peering requirement. This is useful for VERY large ASes.
Thus, as shown in the lesson, the prefix 1.1.1.1/32 does appear in the BGP table of R3.
Now how do you get that into the routing table of R3? Well, one of the prerequisites is to ensure that the next hop IP is in the routing table of the local router. The next-hop IP that appears in the BGP table of R3 for the 1.1.1.1/32 prefix is 192.168.12.1, which is the IP address of Fa0/0 of R1. This next-hop IP address is correct because the specific prefix was learned from R1. However, in the lesson, we haven’t configured any other routing. So R3 has no route to 192.168.12.1, therefore it does not put it in the routing table.
Remember, the purpose of this lesson is to examine how the BGP table is affected by the use of an RR. In a production network, routing between all routers within the AS must be established, typically using an IGP.
I hope this has been helpful!
Laz