In our demo,
we saw the terse output from mtrace that revealed
we had some RPF problems at R3.
Let's see what the packets say.
The traceroute request is generally uninteresting here,
since its purpose is to query each device along the path
to gain a sense of what is happening.
We won't investigate it in detail.
Just note that the traceroute request was sent from
the Globomantics client to R1, and as we learned earlier,
each router reoriginates a request upstream towards the source.
Of greater interest is the response message.
Let's examine it at a high level first.
Immediately,
we see the source of the response is R3 rather than R2 as it
was in the successful multicast traceroute.
This may seem odd that R3 is terminating the traceroute by sending
back the response when it should have been R2.
That's our first sign that something is wrong.
Of the three blocks, the first two look quite normal at a glance.
The first node, the Globomantics client,
uses PIM with a static route for RPF without error.
The next node, R1,
uses PIM with basic routing to evaluate RPF towards the source.
Again, no problems.
The third block reports an error of no route using a protocol of unknown.
That is immediately suspicious.
Let's dig more.
This block is riddled with red flags.
The incoming interface is zeroed out,
which suggests that R3 has no idea on which interface
it should be receiving multicast.
Likewise, the previous router is zeroed out,
which suggests R3 doesn't know what its upstream router
should be towards the multicast source.
Normally,
this would be R2 with an IP address of 10.2 .3 .2 as seen in previous captures.
As discussed earlier, the routing protocol for RPF is unknown,
which suggests R3 doesn't have multicast routing between itself and the
upstream hop as specified in the unicast routing table.
The source mask is now 0 instead of /24 from the working traceroute,
further indicating that a multicast routing issue exists.
The code of NO_ROUTE effectively means that R3 doesn't have
a valid RPF path to reach 10.2 .5 .5, the source of the multicast traffic.
The issue I introduced was disabling PIM between R3 and R2,
but leaving the routing protocol up.
I hope this example helps show you the power of multicast
traceroute in finding real network issues without having to log in to all your devices to manually troubleshoot.