Sunteți pe pagina 1din 2

Let's consider the following topology :

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 <mcastsource> <mcastmember> <mcast group>

So the following mtrace command from R1 :

mtrace 10.0.0.1 20.0.0.1 239.1.1.1

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.1
Type escape sequence to abort.
Mtrace from 10.0.0.1 to 20.0.0.1 via group 239.1.1.1
From 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 9999999

Type 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.1

Reply 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

S-ar putea să vă placă și