Multicast mtrace command


This short post illustrates how the cisco command “mtrace” works.

Let’s consider the following topology  :

Multicast topology with successful RPF check.

With the multicast source at 10.0.0.1 and a multicast member at 20.0.0.1 requesting multicast content from 10.0.0.1.

10.0.0.1 and 20.0.0.1 can reach each other ONLY through R5-R2-R4 which also enabled for PIM.

According to : http://www.cisco.com/en/US/docs/ios/12_3/ipmulti/command/reference/ip3_m1g.html#wp1068645

Usage Guidelines

The trace request generated by the mtrace command is multicast to the multicast group to find the last hop router to the specified destination. The trace then follows the multicast path from destination to source by passing the mtrace request packet via unicast to each hop. Responses are unicast to the querying router by the first hop router to the source. This command allows you to isolate multicast routing failures.

mtrace

Let’s execute mtrace command from R1 :

mtrace 10.0.0.1 20.0.0.1 239.1.1.1

This will send multicast traffic from 10.0.0.1(multicast source) to 20.0.0.1 (multicast member) and then query back the source starting from the last hop router (directly connected to the member)

R1#mtrace 10.0.0.1 20.0.0.1 239.1.1.1Type escape sequence to abort.Mtrace from 10.0.0.1 to 20.0.0.1 via group 239.1.1.1From source (?) to destination (?)Querying full reverse path…0  20.0.0.1  ————> where mtrace started tracing back toward the multicast traffic source 10.0.0.1

-1  192.168.24.5 PIM  [10.0.0.0/24]  ————> 1st hop toward the multicast traffic source 10.0.0.1

-2  192.168.24.6 PIM  [10.0.0.0/24]  ————> 2nd hop toward the multicast traffic source 10.0.0.1

-3  192.168.52.5 PIM  [10.0.0.0/24]  ————> 3rd hop toward the multicast traffic source 10.0.0.1

-4  192.168.15.6 PIM  [10.0.0.0/24]  ————> last hop to which the multicast traffic source is connected

-5  10.0.0.1 ————> multicast traffic source itself

R1#

R4->R2->R5->R1 is the unicast traffic path

R1->R5->R2->R4 is the multicast traffic path.

This in an indication that the RPF check succeed!

We can also use ping <mgroup> that will generate the multicast traffic toward the multicast member and the result shows confirmation from the multicast member for receiving the multicast traffic.

R1#ping 239.1.1.1 source 10.0.0.1 repeat 9999999Type escape sequence to abort.Sending 9999999, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:Packet sent with a source address of 10.0.0.1Reply to request 0 from 192.168.24.5, 88 ms   ——-> last hop Multicast router is confirming the reception

Reply to request 0 from 192.168.24.5, 92 ms  –——> last hop Multicast router is confirming the reception

Reply to request 1 from 192.168.24.5, 108 ms  ——-> last hop Multicast router  is confirming the reception

Reply to request 1 from 192.168.24.5, 108 ms  ——-> last hop Multicast router  is confirming the reception

Here is the result of mtrace in both cases

Here is  two ad-hoc explanatory videos illustrating both cases of successful and failed RPF check :

Case1 : unicast path = multicast path (successful RPF)

R1#mtrace 10.0.0.1 20.0.0.1 239.1.1.1Type escape sequence to abort.Mtrace from 10.0.0.1 to 20.0.0.1 via group 239.1.1.1From source (?) to destination (?)Querying full reverse path…

0  20.0.0.1

-1  192.168.24.5 PIM  [10.0.0.0/24]

-2  192.168.24.6 PIM  [10.0.0.0/24]

-3  192.168.52.5 PIM  [10.0.0.0/24]

-4  192.168.15.6 PIM  [10.0.0.0/24]

-5  10.0.0.1

R1#

Case2 : unicast path # multicast path (RPF failure)

R1#mtrace 10.0.0.1 20.0.0.1 239.1.1.1Type escape sequence to abort.Mtrace from 10.0.0.1 to 20.0.0.1 via group 239.1.1.1From source (?) to destination (?)

Querying full reverse path…

0  20.0.0.1

-1  192.168.24.5 None No route

R1#

the resulting traceroute request will report all RPF successes in the path back to the multicast source and stop there where an RPF failure.

Advertisements
%d bloggers like this: