The response packet is almost identical to the
request packet in terms of format.
I will highlight the differences along the way.
First, notice the source address is R2, the remote Wired Brain Coffee router.
Specifically, it is R2's LAN interface towards the server,
which is where the multicast traceroute terminates.
The destination is the Globomantics client, indicating this is return traffic.
The type of this packet is 1E in hex or 30 in decimal,
differentiating itself from the request packet we explored previously.
The rest of this data is almost identical to the traceroute request,
so I won't cover it again.
Check out the query ID of 8, which is the same value from the request packet.
This marries up the request and reply on the client's operating system.
Before we expand the list of data blocks,
let's evaluate the summary information provided by Wireshark.
The first block in this response is identical to the
block we examined in the request,
revealing that PIM is in use with the static route
for RPF and no errors were seen.
The second two blocks are intermediate hops that aren't
terribly interesting at a glance.
The first block shows R1's interfaces that connect the Globomantic and R3,
indicating that PIM is used with no errors seen.
The second block shows R3's interfaces that connect R1 and R2,
likewise using PIM with no errors.
The final block is a little strange, since it claims that core-based tree,
or CBT multicast routing, is used.
That's simply not true, but in reality,
R2 is the last hop and has a connected route to the multicast source.
This version of Cisco iOS just identifies it as CBT for some reason.
You can equate CBT with connected in this context.
More importantly, there are no errors.
Let's explore the bottom two data blocks in greater detail.
I'll begin with the block from R3.
First, notice the incoming and outgoing interfaces differ.
This makes sense because the incoming interface is the link to R2,
which is towards the source and thus the incoming interface.
The outgoing interface is towards R1,
which is downstream towards the Globomantics client.
The previous hop in the upstream path was R2,
which is the device that sent us the multicast.
We haven't sent traffic along this path recently, so all counters are 0.
Not a big deal.
The routing protocol is regular PIM,
since behind the scenes I am using a basic routing
protocol to hold the network together.
Its details are beyond the scope of this course.
Let's jump down to the source mask.
We see 18 in hex, which is 24 in decimal.
I'm a simple man, and I like to use /24 prefix links in my lab environments.
This field is effectively saying my RPF to 10.2 .5 .5,
the source of the multicast, is covered by a /24 route.
Specifically, the network is 10.2 .5 .0 /24,
which houses the Wired Brain Coffee servers.
Note that this mask could change at different hops in the network if
we were performing route aggregation along the way.
R3 reports no errors.
That means no axis lists, no TTL scoping,
no pruned multicast state,
or any other issue that would cause multicast
transport from source 10.2 .5 .5 to fail.
Let's quickly cover the final block in this successful multicast traceroute.
This message represents R2, the first hop router.
Traffic arrives from the LAN interface from the multicast
server and is sent downstream towards R3.
There is no previous hop anymore,
because R2 is the first hop router in the multicast flow,
so this is zeroed out.
Again, let's skip over the 0 packet counters.
The routing protocol reports CBT, but as discussed before,
this is just a connected route with servers on it.
We can see the hex value of 18 again,
which is 24 in decimal and represents a /24 prefix for the servers.
Finally, the error code of all 0s means everything worked, and multicast should flow correctly.