Junos OS

Hi all!

I have a network (MPLS, OSPF, LDP, RSVP, BGP) consisting of several routers (R1–R5), two of which (R4, R5) act as Route Reflectors and are also connected to uplinks. BGP sessions between routers R1–R5 are established only in the global configuration context (MP-BGP is used).

Now we're talking about the RI (Routing Instance) "Internet". In this RI, I receive a full-view from the uplinks on all routers (R1–R5).

I need to connect an eBGP client with AS65001 to an interface on router R1, but the BGP session should be established with router R5.
On router R1, I allocate a /30 subnet to the client (123.123.123.1 – R1's interface, 123.123.123.2 – client's router interface), and on router R5 I configure BGP with the multihop option.
The BGP session comes up, I receive the client's prefixes on R5 (on R5, the next-hop is 123.123.123.2), but the problem is that via iBGP I receive the same prefix (from RR R5) on R1, but with a next-hop pointing to R5 instead of 123.123.123.2. This results in a routing loop :(

I'm unable to change the next-hop via policy (vrf-import on R1 or vrf-export on R5 doesn't change the next-hop).

So my question is: Has anyone encountered a similar situation? Is there a way to solve this without setting up a tunnel (e.g., a PW) from R1 to R5 or using static routes?

This would work in a non-VPNv4 environment, since no-one by default would change the next hop IP (that of your external neighbour).  But when exporting into the VPNv4 table the PE (in your case R5) will set the next hop to itself (since it considers itself as the provider edge for that CE).  Of course this is the IGP next hop.   Since your eBGP link in your core exists solely as a VPNv4 prefix, that IP is not a reachable IGP next hop (or more accurately - a labelled IGP next hop).

I think  you're right - you need to "hide" this stretched eBGP session from your core using some kind of tunnel (GRE, PWE3, L2TPV3).  Obviously any traffic destined externally will still go via R5 (even if it originated at R1, for example), since it would be the tunnel endpoint.