I've attached a lab diagram that I was playing with this morning, and I can't get it to work.
RTRB is getting a route for RTRD (22.214.171.124) from RTRC. The next hop is showing as RTRD's ip address since iBGP doesn't change the next hop address. I enabled next-hop-self on RTRC:
neighbor 192.168.4.1 next-hop-self
It's not working. To get the RTRD route to RTRB, I had to set up a RR client like:
neighbor 192.168.5.1 route-reflector-client
That brought my route into RTRB, but with the wrong next hop. I know I'm missing something. :-)
If you want to ping from an interface and the interface isn't known by the destination device, you need some kind of advertisement either via BGP or IGP.
I see you are advertising the loopbacks, did you try pinging by sourcing from the loopbacks?
I'm a little confused since our conversation has been around the iBGP mesh yet you bring up RouterA into the picture - an eBGP peer.
When configuring iBGP on multiple BGP speaking routers, one of the rules is to have an iBGP mesh, route-reflector or confederation.
This practice is done to avoid any loops within the BGP environment.
As for the wrong next-hop, the BGP next-hop self does not modify the next-hop on route-reflectors. You can modify the next-hop with a route-map.
Do not use the neighbor next-hop-self command to modify the next hop attribute for a route reflector when this feature is enabled for a route reflector client. Using the neighbor next-hop-self command on the route reflector will modify next hop attributes only for routes that are learned from eBGP peers and not the intended routes that are being reflected from the route reflector clients. To modify the next hop attribute when reflecting a route, use an outbound route map.