In this scenario, the physical interface of the EX4300 connected to a neighbor device is part of a custom virtual-router routing-instance. The lo0 is in the primary routing-instance and interface routes are leaked from primary routing-instance to the custom routing-instance.  When the device is connected to the EX4300 and initiates an ICMPv6 echo request to the loopback IP address of EX4300, the following behaviors are observed:

• When the received packet's destination and the EX reply's source interface are in different routing-instances, there may be no ICMPv6 echo reply intermittently.
• When the EX4300 responds with echo reply, it responds with the physical interface IP as source instead of loopback as source for ICMPv6 echo reply.

By default, we should get a reply from EX-4300 lo0.0 IPv6 address when pinging the lo0.0 IP of the EX from a neighbor device.  Sometimes two behaviors are seen from the EX4300. One is a response being received from the physical interface IP of the EX4300 switch and another is no response, which generates a "Destination Administratively Unreachable" message on the neighbor device.

The following is a sample ICMP echo initiated from a device directly connected to the EX4300, destined to the lo0 IP of the EX. When the lo0 of EX is part of primary routing-instance and EX interface connected to neighbor is in a routing-instance "TEST":

labroot@NEIGHBOR> ping routing-instance TEST 2000:0:beef:0:ffff:ffff:ffff:e98f  <--- Pinging to EX-4300 lo0.0 IPv6 address

PING6(56=40+8+8 bytes) 2000:0:beef:4::2c38 --> 2000:0:beef:0:ffff:ffff:ffff:e98f
64 bytes from 2000:0:beef:4::2c38:  Destination Administratively Unreachable  <---
Vr TC Flow Plen Nxt Hlim
6 00 00000 0010 3a 3f
2000:0:b:4::2c38->2620:0:1cfd:0:ffff:ffff:ffff:e98f
ICMP6: type = 128, code = 0

16 bytes from 2000:0:beef:4::2c39, icmp_seq=0 hlim=64 time=1.039 ms  <---  Getting reply from physical interface address of EX-4300
 

After moving EX-4300 lo0.0 interface to "TEST" routing-instance (set routing-instances TEST interface lo0.0 ):

labroot@NEIGHBOR> ping routing-instance TEST 2000:0:beef:0:ffff:ffff:ffff:e98f count 1
PING6(56=40+8+8 bytes) 2000:0:beef:4::2c38 --> 2000:0:beef:0:ffff:ffff:ffff:e98f
16 bytes from 2000:0:beef:0:ffff:ffff:ffff:e98f, icmp_seq=0 hlim=64 time=1.196 ms   <--  Reply coming lo0.0 IPv6 address as expected

This issue might be seen if the following conditions are met:

• VRFs are configured.
• When local interfaces (e.g., lo0.0) is configured under primary routing-instance and the interface route is leaked (using rib-group config) to custom routing-instance.

This is unexpected behavior that is triggered or seen when the lo0.0 is configured under primary routing-instance and interface route is leaked to a custom routing-instance.
Note that the issue is not seen when lo0 interface itself is added to the customer routing-instance (instead of leaking interface route).

The issue with incorrect source IP is resolved in the following Junos releases and there is no workaround:

• 18.3R3
• 18.4R3
• 19.1R2
• 19.2R2
• 19.3R1
• 19.4
• 18.1R3-S8
• 18.2X75-D52
• 18.2X75-D65
• 18.4R2-S5

Route leak across VRFs should happen for local IP as well.  In the example mentioned above, the lo0 interface route leaked from default VRF inet6.0 into TEST.inet6.0 is not installed in the PFE (packet forwarding engine) that is causing the route lookup in the routing-instance to hit a default route instead of the lo0 interface route (which is missing). 

root@EX4300> show route table TEST.inet6.0
TEST.inet6.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

::/0 *[OSPF3/150] 00:00:21, metric 0, tag 0
> to fe80::aa00:d100:14b:c1b8 via ae12.1

The default route has a next-hop as the physical egress interface connecting to the neighbor device. 

Installing the lo0 interface route properly in OOB VRF in the packet forwarding engine resolves this issue.

The problem with route leaking issue is resolved via PR1623429 - Route leak from master routing-instance to custom routing-instance failure occurs for local interface.
The only workaround is to move the interface (lo0 in this article) on EX4300 that is the target/destination IP of ICMPv6 echo packets, to the same routing-instance as the egress interface of the echo reply.