From: Bob Sinclair (bob@bobsinclair.net)
Date: Fri Mar 30 2007 - 06:34:33 ART
ian wrote:
> Bob Sinclair,How are you#!
>
> Here is the whole senario:
> There are 4 routers in multicast sparse-mode envireoment.
>
> R1---R2---R3---R4
>
> R4 joins multicast group 224.1.1.1, 224.2.2.2
> R2 is RP for group 224.1.1.1 and 224.2.2.2
> R3 is R2's backup RP.
> R2 and R3 can ping 224.1.1.1 and 224.2.2.2
> However, R1 can not ping 224.1.1.1 224.2.2.2 unless I put R1's loopback 0 in multicast spare-mode.
> I found the difference of these routers is R2&R3 have specific route to reach R4. R1 only have default static route.
>
Remember that in many lab situations the ping to 224.1.1.1 or 224.2.2.2
is playing the part of a multicast source (like a video server) and the
routers are playing the part of multicast clients. The echo-request is
multicast and the echo-reply is unicast. Generally it is best to
troubleshoot just one multicast tree at a time; so only ping from one
router.
I also highly recommend that if you use ping as a multicast source, do a
high repeat count. Otherwise you have only a few minutes to troubleshoot
before all of your state times out. For example: ping 224.1.1.1 repeat
9999. You can always kill the ping with a CTL-SHIFT 6 6 break sequence.
Putting PIM on the R1 loopback should not affect the PIM sparse-mode
tree, unless you are using the loopback as an RP address or to simulate
a multicast client.
I would recommend simplifying: ping only one group, from R1. Have only
one client, on R4. Troubleshoot this using tools like:
sh ip mroute
debug ip mpacket
show ip pim int count
Make sure R4 has a route back to R1 for the unicast replies.
-- Hope that helps!Bob Sinclair CCIE 10427 CCSI 30427 www.netmasterclass.net
This archive was generated by hypermail 2.1.4 : Sun Apr 01 2007 - 06:35:53 ART