Hello Evgeny
This is expected behaviour. Remember that there is a difference between routing multicast traffic and processing multicast traffic. In order to process multicast traffic, all you need is a PIM command on the interface. It doesn’t matter if it is sparse mode, dense mode, or passive. In this topology that you have, there is no multicast routing, since we are looking only at a single network segment.
Take a look at the following example. For this, the 239.2.2.2 multicast group was used:
R1#debug ip multicast topology
R1#debug ip pim
R1#debug ip igmpR1 doesn’t have anything in its OIL:
R1#show ip mroute 239.2.2.2
(*, 239.2.2.2), 00:03:05/00:02:55, RP 0.0.0.0, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: NullR2 is the DR:
R1#show ip pim neighbor
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
P - Proxy Capable, S - State Refresh Capable, G - GenID Capable,
L - DR Load-balancing Capable
Neighbor Interface Uptime/Expires Ver DR
Address Prio/Mode
10.12.0.2 GigabitEthernet0/1 00:04:17/00:01:23 v2 1 / DR S P GNow let’s make R1 the DR:
R1(config-if)#ip pim dr-priority 2You see this output:
PIM(0): Changing DR for GigabitEthernet0/1, from 10.12.0.2 to 10.12.0.1 (this system)
%PIM-5-DRCHG: DR change from neighbor 10.12.0.2 to 10.12.0.1 on interface GigabitEthernet0/1
IGMP(0): MRT Add/Update GigabitEthernet0/1 for (*,224.0.1.40) by 3
MRT(0): Update (*,224.0.1.40), RPF (unknown, 0.0.0.0, 0/0)
MRT(0): Set the C-flag for (*, 224.0.1.40)
MRT(0): WAVL Insert interface: GigabitEthernet0/1 in (* ,224.0.1.40) Successful
MRT(0): set min mtu for (0.0.0.0, 224.0.1.40) 18010->1500
MRT(0): Add GigabitEthernet0/1/224.0.1.40 to the olist of (*, 224.0.1.40), Forward state - MAC built
IGMP(0): MRT Add/Update GigabitEthernet0/1 for (*,239.2.2.2) by 3
MRT(0): Update (*,239.2.2.2), RPF (unknown, 0.0.0.0, 0/0)
MRT(0): Set the C-flag for (*, 239.2.2.2)
MRT(0): WAVL Insert interface: GigabitEthernet0/1 in (* ,239.2.2.2) Successful
MRT(0): set min mtu for (0.0.0.0, 239.2.2.2) 18010->1500
MRT(0): Add GigabitEthernet0/1/239.2.2.2 to the olist of (*, 239.2.2.2), Forward state - MAC built
PIM(0): Building Triggered (*,G) Join / (S,G,RP-bit) Prune message for 239.2.2.2R1 now becomes the DR, and the interface is added in the OIL.
Now the reason this same behaviour is seen when we use the passive command is because the PIM neighbor adjacency between R1 and R2 is severed, which means that R1 automatically becomes the DR, and this is the reason why the exit interface appears.
In both your example, as well as the example I described, the result is that R1 becomes the DR, albeit for different reasons. This is the reason for which the interface then appears.
It’s important to note that R1 still receives IGMP membership reports from R2, and so R1 receives them, processes them, and adds the interface to the OIL.
I hope this has been helpful!
Laz