Let's switch gears away from protocol formatting and
operations in this final module.
I'd like to share some troubleshooting and security advice,
which I am certain you will find useful in your daily work.
This final module deals with IGMP and MLD tools that help
administrators operate their networks.
Most of this module is focused on a powerful tool which can
reveal complex multicast problems that arise.
The utility is called multicast traceroute,
and while similar to unicast traceroute in theory,
has some stark differences in operation.
Multicast traceroute generates some truly incredible packets,
which are crammed full of useful data.
We'll explore those in depth.
In order to see the tool's true power,
I'll break the network and we'll use multicast traceroute to find the fault.
Of course, we'll explore the packets it generates, too.
I'll round off this course by talking about IGMP and MLD security,
including a high-level design template for your real life usage.
Let me paint a high level picture of how multicast traceroute works.
I'll use our real life network, since it's a perfect example,
except that I've removed a router to simplify the diagram.
The Globomantics client wants to ask the network what is the
reverse path from me towards a given source.
To do that, it needs to communicate with every router along the path.
A new IGMP message, known as the traceroute request,
is sent up the reverse path in the general direction
of the Wired Brain Coffee server, but targeting the first router.
R1 answers the detailed questionnaire contained in the traceroute request,
but instead of responding back to the client,
it regenerates a new traceroute request up the reverse path towards the server.
The destination this time is R2.
It's kind of like passing a signature sheet around your job to
get multiple managers to sign off on something.
You'll get the sheet back with all the signatures
at the very end of the process.
R2 receives the traceroute request from R1,
answers the question,
and realizes that it is the last multicast router in the path.
Traceroute terminates here,
and R2 sends a long-range IGMP message back to the
client known as a traceroute response, or reply.
The reply has a list of responses from each router in the path,
effectively creating a full report of all relevant data along the path.
Any transit routers, such as R1 in this example,
are regular unicast routers with respect to this packet.
Detailing unicast traceroute would be quite time-consuming and off topic,
so I'll stress one point.
There is no ICMP used in the multicast traceroute process.
No pings, no unreachables, none of that.
This utility is supported entirely by IGMP and is limited to IPv4.
RFC 8487 details the next generation of this feature called mtrace 2,
which includes IPv6 support. It was recently published and is not wildly supported yet.