Multicast RPF failure

[No_Problem]

Hello all,

I was playing around with multicast and I've run into a situation I would like your comments :)

I have 4 routers connected like this:

R1-R2-R3

-R3 is a static configured RP.

-all interfaces except R1 are running PIM-SM.

From R1, I'm sending a ping to a multicast address using Loopback0 IP as source and sending it out via the interface to R2 (using an extended ping to be sure the exit interface and source addr).

Making no ip mroute-cache and debugging ip mpacket I see that R2 is giving a RPF check error. I've checked R2 with "show ip rpf R1-Lo0" and it shows the correct interface, also correct exit interface in the routing table and CEF.

If I source the multicast ping using the interface (physical) address then everything works fine.

Can someone give me a hint why I can't source it from the loopback? Shouldn't it be possible?

---------------------

R2#

00:06:46: IP(0): s=10.1.7.7 (FastEthernet0/0) d=224.40.40.40 id=17, ttl=254, prot=1, len=114(100), not RPF interface

R2#sh ip route 10.1.7.7

Routing entry for 10.1.7.7/32

Known via "ospf 1", distance 110, metric 2, type intra area

Last update from 10.1.37.7 on FastEthernet0/0, 00:15:04 ago

Routing Descriptor Blocks:

* 10.1.37.7, from 10.1.7.7, 00:15:04 ago, via FastEthernet0/0

Route metric is 2, traffic share count is 1

R2#sh ip rpf 10.1.7.7

RPF information for ? (10.1.7.7)

RPF interface: FastEthernet0/0

RPF neighbor: ? (10.1.37.7)

RPF route/mask: 10.1.7.7/32

RPF type: unicast (ospf 1)

RPF recursion count: 0

Doing distance-preferred lookups across tables

----- now using interface IP (at the moment nobody joined the group)

R2#

00:05:18: IP(0): s=10.1.37.7 (FastEthernet0/0) d=224.30.30.30 id=5, ttl=254, prot=1, len=114(100), mroute olist null

--------

Thanks!

[Giuseppe Larosa]

Hello,

and what happens if you enable PIM on R1 ?

hope to help

Giuseppe

[Giuseppe Larosa]

Hello,

when you use the physical interface source R1 is behaving like a host connected to R2's LAN interface.

When you use the loopback interface you are trying to do something different R1 isn't an host connected to R2 anymore.

In this case if PIM is enabled on R1's interfaces you should see a change because now R1 is a legal PIM neighbor of R2 and your traffic should pass the RPF check.

hope to help

Giuseppe

[No_Problem]

Thanks for the explanation, makes sense.

[Seifeddine-Tlili]

Hi Giuseppe,

regarding your explanation i don`t think if that`s the correct answer or not :) since R1 is not the client but the server and R2 now is receiving a source (1.1.1.1,MLTIADD) and for him it have to listen to this stream only from the RP since 1.1.1.1 or from a connected source and the loop0 isn`t a connected interface.

Since you are using sparse mode so it will perform and RPF check on the RP ignoring the add 1.1.1.1 and it will see that the interface from where it`s receiving the stream isn`t the one for the RP