Hello!
It looks like your trying to mtrace from one of your FR spoke routers to a multicast source and it's not working for you. I've ran into a similar problem before based on your mtrace output where multicast traffic flow worked fine but Mtrace did not work. If that is the case then I believe it has to do with how mtrace does the initial query on the local router and that the first RPF hop is over a Frame Relay interface.
First here's your output:
From source (?) to destination (?)
Querying full reverse path... * switching to hop-by-hop:
0 10.10.10.2
-1 * * * Timed out receiving responses
The zero hop is a local IP on your router. If I'm right this is probably the IP on your FR interface. The -1 hop represents the local RPF information found by querying the local router. So this output above means that mtrace cannot query RPF information from the local router itself. I can't say for sure how this works programatically but I think that what happens is the router not only sends unicast packets upstream to query those routers about their RPF information but it also sends unicast packets to the local router when initiating the query because it must first check the local RPF information.The 0 hop is the IP it queries the router at and the -1 shows the local RPF info that was found from the query. The -2 entry that would be next if this was working is the first upstream router in the path to the source. So the problem you maybe running into is that it's trying to talk to the local router through an IP on a multipoint frame-relay interface. If this is a multipoint FR interface then that will not work unless the local IP on the interface has its own DLCI mapping.
So if that is the cause of the problem for you there's two ways to fix this:
1. When issuing the "mtrace" command specify the multicast source address and also a destination address. The destination should be an interface on the router your running the mtrace command from that is not a FR interface. When I had this problem specifying a local loopback that was running pim (not sure if pim on the loopback matters) made the command work fine. It would look something like this in cli: mtrace x.x.x.x y.y.y.y, where x.x.x.x is the multicast source and y.y.y.y is the local loopback on the local router. In the output when you do this the IP address listed in the zero hop changes to the loopback address and then the command can work. I would try this first before mucking around with the FR configuration. If this fixes the issue you can try step two if you don't want to always have to specify the destination when mtracing on this router. If this didn't fix the issue than step two will not fix it either.
2. Another fix for this problem is mapping the local IP address on the multipoint frame-relay interface to one of the DLCI's that is already in use. This fixes the issue because when a router generates a packet destined to a local interface that packet is actually routed out that interface and therefore needs layer 2 mapping. You may have ran into the issue where you can't ping the IP address of a multipoint FR interface from the local router. This is caused by the same problem. To fix this you can add layer 2 mapping for this IP address with the frame-relay map command. You just map the local IP to any existing/working DLCI on the interface. So when the packet is generated by the local router it is actually forwarded down that DLCI to the router on the other side of the PVC and that router forwards it right back. It's kinda weird but it is just how it works progamatically. IMPORTANT: You should lab up this solution first before deploying this to a production device. Also, if your not very comfortable with this concept or Frame Relay than you should just use the first solution. Lastly, if the first solution did not fix your issue than the second solution will not either and you shouldn't do it in that case.
I hope that helps. Obviously my solution only applies if your mtracing over a multi-point frame-relay interface (the physical or a multi-point subinterface) but I felt that the unique output of your mtrace probably pointed to this being case even if you didn't mention it explicitly.
Mark DeLong
