Now that we've learned about how multicast traceroute
works and tested a few in the network, let's explore the packet structure.
I'll warn you that these packets carry a ton of information
far more than anything we've seen so far.
First, the traceroute request.
The packet header doesn't tell us explicitly that
this is a multicast traceroute, and some engineers may,
at a glance, confuse this as a regular unicast traceroute.
The trick is that these packets are actually IGMP packets.
The source is our client that initiated the traceroute,
and remember, many host operating systems don't support it,
since this feature is normally implemented only on multicast-capable routers.
Given that our Globomantics client is actually a Cisco iOS router,
I can use it in this demo.
The destination is the next hop Globomantics router of R1.
Why isn't the destination 10.2 .5 .5, as it would be for unicast traceroute?
Remember that multicast traceroute queries each hop along the way for a
detailed report of multicast RPF information for a given source,
so the request needs to stop at every router along
the way to get this information.
Let's dig deeper.
The traceroute request packet has IGMP type 1F in hex or 31 in decimal.
This allows network devices to identify it as a special type of packet.
The number of hops replaces the 1 byte code field,
which sets an upper bound on the number of multicast hops to trace.
Traceroutes can optionally contain a multicast group to check against.
It is possible that different multicast groups take different
paths through the network or use different RPs.
For simplicity,
I didn't use any group-specific multicast traces in the demonstration
because we aren't focusing on PIM or multicast routing.
The source address represents the target of the multicast trace,
which is the source of multicast traffic.
This is the Wired Brain Coffee server sending multicast into the network.
Receiver versus response address is tricky and it's
very uncommon for them to differ.
The response address can be used when the Globomantics client is not
unicast reachable via the Globomantics router.
The response address could be a multicast address instead,
which would allow the client to receive its data via multicast.
The receiver address is the regular unicast address of the client, though.
The response TTL is typically a copy of the IP TTL, in this case, 64.
The query ID is much like an ICMP echo request identifier,
which prevents concurrent multicast traceroute operations
from being confused with one another.
It is unique for each multicast traceroute operation.
Let's expand this data block next.
We just covered the basic information carried in the
multicast traceroute requests.
We need to explore the individual data blocks those requests can carry.
The query arrival is a network time protocol,
or NTP, derived timestamp from when the request arrived at a given router.
A complex math formula explains how to interpret this number,
so let's not go down that rabbit hole.
The incoming and outcoming interface addresses represent
the IP address in which multicast traffic is expected to
ingress and egress the router, respectively.
Given that this end host sudo router only has one interface,
we see its IP address twice.
This will get more interesting when we look at true multicast routers.
The previous hop router address identifies the upstream router towards
the source from which multicast would be received.
We saw several demos earlier in this course where R1 sent
traffic to the Globomantics client, thus making it the previous hop router.
Inbound and outbound packets are simple counters that measure how
many multicast packets have come in or gone out,
respectively.
The source group pair packet counter measures how many
multicast packets on a given group, if specified,
have traversed the multicast router.
The routing protocol data is very useful.
It reveals which multicast routing protocol is used at each hop in the network.
Decades ago, there were many alternatives to PIM,
though these days it's rare to see anything else.
A few different PIM-flavored codes exist,
such as PIM via static route for RPF, ordinary PIM via unicast routing protocols,
or PIM via multicast border gateway protocol,
or MBGP.
Imagine if unicast traceroute could tell us which routing protocols
were being used at each router along the way.
That is exactly what multicast traceroute does for us.
The FwdTTL identifies any TTL scoping along the path.
Multicast routers can apply policies that say,
I will not send multicast with a TTL less than 7 out of this interface.
Multicast traceroute can report those policies to us.
Next, we have some minor flags.
MBZ means must be zero, and never changes.
The S bit identifies whether the source group
packets are for the source network, a niche topic we won't dig into.
The source mask represents the prefix length of the route used for RPF.
Since the Globomantics client only has a default
route with a prefix length of 0, this field is all 0s.
We will see this change soon.
Finally, and most importantly, the forwarding code.
All 0's means no error, which is good.
Most other values mean an error occurred with a few exceptions.
Multicast traceroute can tell us precisely what happened and where. Before we explore problems, let's explore the response.