Our customer is not able to do MPLS traceroute trough their MPLS core. The peers are on routing instances on both side.
Also they have tried removing the Filter from the interface so it allow all traffic but it is still not working.
root@JTAC> ping a.b.c.d instance Green source a.x.y.z
PING a.b.c.d (a.b.c.d): 56 data bytes
64 bytes from a.b.c.d: icmp_seq=0 ttl=64 time=1.030 ms
64 bytes from a.b.c.d: icmp_seq=1 ttl=64 time=0.868 ms
64 bytes from a.b.c.d: icmp_seq=2 ttl=64 time=0.962 ms
^C
--- a.b.c.d ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.868/0.953/1.030/0.066 ms
{master}
root@JTAC> trace a.b.c.d instance Green source a.x.y.z
traceroute to a.b.c.d (a.b.c.d) from a.x.y.z, 30 hops max, 52 byte packets
1 a.b.c.d (a.b.c.d) 1.213 ms 0.830 ms 0.630 ms
MPLS trace or ping:
root@JTAC> ping mpls segment-routing isis a.b.c.d instance Green source a.x.y.z
...
--- lsping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss
root@JTAC> trace mpls segment-routing isis a.b.c.d instance Green
Probe options: ttl 64, retries 3, wait 10, paths 16, exp 7, fanout 16
ttl Label Protocol Address Previous Hop Probe Status
1 a.e.f.g. (null) No reply
2 (null) (null) No reply
3 (null) (null) No reply
4 (null) (null) No reply
5 (null) (null) No reply
6 (null) (null) No reply
7 (null) (null) No reply
8 (null) (null) No reply
9 (null) (null) No reply
^C[abort]
On all Junos and Junos OS Evolved platforms, when a routing instance is configured at the destination device, an echo request packet is received over this routing instance interface.
This routing instance will have a valid route for the reply to reach the source device. But the reply takes default routing instance instead to reach the source device.
This is because kernel table id corresponding to the routing instance (echo request packet received with this instance) is not passed by RPD (Day-1 code) hence kernel does a lookup in default routing instance to forward the echo reply packet.
This issue is not specific to MPLS ping over SR alone. This issue is applicable for all the protocols MPLS ping.
This is fixed via below PR.
https://prsearch.juniper.net/problemreport/PR1889546