The issue you are having is that while R1 knows about the BGP route to R3, it is not installing it into the routing table. You can verify this by going on to R1 and issuing a “show ip bgp” and look for the 192.168.0.0 route (it will be missing the “>” symbol).
The reason R1 is not installing the route is due to BGP behaving differently than other routing protocols. BGP really isn’t a true routing protocol in the way that OSPF or EIGRP are. BGP is more of an application that tells you WHERE to go to get to a network, but it does not tell HOW to get there. So, for example, BGP is telling R1 to get to 192.168.0.0/24, go to 184.108.40.206. It is up to R1 to figure out HOW to get to 220.127.116.11. In this case, R1 doesn’t know how to get to 18.104.22.168.
I suspect you know all of this, which is why you are trying to configure R2 to be a next-hop-self for R1. The problem with this solution is that, by default, BGP only modifies this attribute on routes it learns from external neighbors–not internal neighbors.
So to solve this problem, you have four options:
- Configure R3 in a different BGP ASN than R2
- Configure R2 to advertise the 22.214.171.124/24 and 126.96.36.199/24 networks in BGP
- Configure either static routes or an IGP so that R1, R2, and R3 know about all the links connecting them
- If you have a late enough version of the IOS, R2 will have a new option of “neighbor 188.8.131.52 next-hop-self all” where this option allows the modification of either internally or externally learned BGP routes.