Let's begin a demonstration to see this tool in action.
For this demonstration, I've broken the link between R1 and R2 intentionally.
This adds R3 into the path, which gives traceroute more hops to evaluate,
and thus a more interesting packet capture.
Time to test the multicast traceroute feature on the live network.
As a reminder,
this version of multicast traceroute was designed for multicast routers,
not clients.
So please be aware what the dual purpose of the client in this case.
Let's just feed in the Wired Brain Coffee source IP address of 10.2 .5 .5.
The traceroute completes very quickly,
but let's spend some time exploring the output.
Much like unicast traceroute,
each hop in the network generally gets one line of output.
Ignoring the first line, which specifies the source IP used in the trace,
the following lines identify the multicast reverse path
from the receiver back to the source.
In our output,
the reverse path goes from the Globomantics client acting as a router,
then towards R1, then towards R3, and finally towards R2,
which was the expected path.
In a more complex network with more routers,
more links, and variable routing metrics,
discovering the multicast traffic path could be very
laborious without such a tool.
The end of the traceroute shows the target IP address,
which is the multicast source, on a line by itself.
This indicates success.
This output is rather terse,
so I'll enable IGMP debugging and run another traceroute.
The debug provides a bit more detail.
In the upcoming packet capture,
I'll expose you to a tremendous volume of information,
so I'll keep it high level for now.
Let's just focus on the packet flow.
The client first assembles the mtrace request packet with a
variety of parameters we will soon explore.
It then sends the mtrace request to 10.1 .4 .1,
which is the first Globomantics router in the path.
Unlike unicast traceroute,
mtrace has to get a detailed set of information from every hop in the network.
A simple ICMP unreachable message won't suffice.
R1 answers the detailed questions and passes the request onto R3,
which does the same.
R3 answers the questions and forwards the request to R2,
which terminates the traceroute.
That's why we see the mtrace response from 10.2 .5 .2 and
not from any of the intermediate routers,
since R2 has the full report being at the end of the traceroute path. Let's explore these packets in detail.