Multicast source behind PIM sparse mode router causes (*,G) state to be created - why?

[Sam Brynes]

I have the following topology in my lab:

All routers in this topology are using 2.2.2.2 as the RP. The RP is loopback0 on R2 (not shown on topology).

I'm just getting my feet wet with multicast. I did a ping to 239.3.3.2 from S1, and here's what I saw on R1:

R1#sh ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector, p - PIM Joins on route,
x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.3.3.2), 00:00:03/stopped, RP 2.2.2.2, flags: SPF
Incoming interface: Ethernet0/1, RPF nbr 192.168.12.2
Outgoing interface list: Null

(192.168.1.1, 239.3.3.2), 00:00:03/00:02:56, flags: PFT
Incoming interface: Ethernet0/3, RPF nbr 0.0.0.0
Outgoing interface list: Null

R1#

S1 is sending to 239.3.3.2, and there are no clients who want to receive traffic for group 239.3.3.2.

I expected to see the (S,G) entry. But why was the (*,G) entry created? I don't have any routers or clients behind R1 that are requesting traffic for the multicast group 239.3.3.2. It says the incoming interface is Ethernet0/1, but isn't R1 trying to send multicast traffic for group 239.3.3.2 towards the RP?

[Jon Marshall]

When R1 receives the multicast stream from S1 it has to send that traffic to the RP on the shared tree otherwise the RP would not be aware of the stream. 

It encapsulates this traffic into PIM register packets and when the RP receives them it records source but as there are no active receivers in your setup the RP does not need to continue receiving the packets so it sends a register stop message to R1 which you can see from the flags next to the (*, G) entry. 

Jon

[Sam Brynes]

Hi Jon,

Thanks for your reply. Can you possibly explain in a different way the part about S1 having to send traffic to the RP on the shared (RPT) tree? I thought joining a shared tree was always from an RP, to get multicast data, not "pushing" it there.

Also, I did a "show ip mroute" on R2. What does "stopped" in place of a time for the age-out for the mroute entry mean?

R2#sh ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector, p - PIM Joins on route,
x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.3.3.2), 00:00:11/stopped, RP 2.2.2.2, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null

(192.168.1.1, 239.3.3.2), 00:00:11/00:02:48, flags: P
Incoming interface: Ethernet0/1, RPF nbr 192.168.12.1
Outgoing interface list: Null

R2#

[Jon Marshall]

Sam 

Apologies for adding confusion to what is already a confusing subject. 

As pointed out the shared tree is not used by the source to send traffic to the RP,  it is initially sent as encapsulated unicast packets as mentioned. 

Jon

[sarahanand]

Hi Sam,

Regarding this:

But why was the (*,G) entry created?

I’m quoting the below from the Developing IP Multicast book (Pg 242):

General Rule 1 : Whenever it is necessary to create an (S,G) entry and a corresponding parent (*,G) entry does not exist, a new (*,G) entry is automatically created first.

This is the way IOS works. Even if, for example, the RP does not have a prior (*,G) entry created (meaning no receivers for the group are active in the multicast topology), as the rule states above, IOS automatically creates a (*,G) entry when it receives a (S,G) REGISTER message from the FHR/DR. For the same reason, Cisco IOS routers always preserve a (*,G) entry along with (S,G) in dense mode even though the (*,G) entry has no purpose in PIM-DM.

Through my testing though I have noticed the same does not happen with IPV6. As an eg. below, R7 is the RP and has received the REGISTER message from R2. Observing the IPv6 mroute table we notice that on an (S,G) entry exists on the RP, and no (*,G). This is of course the behaviour when the RP has not received any PIM joins for the multicast groups.

R7#show ipv6 mroute
Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group,
C - Connected, L - Local, I - Received Source Specific Host Report,
P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set,
J - Join SPT, Y - Joined MDT-data group,
y - Sending to MDT-data group
g - BGP signal originated, G - BGP Signal received,
N - BGP Shared-Tree Prune received, n - BGP C-Mroute suppressed,
q - BGP Src-Active originated, Q - BGP Src-Active received
E - Extranet
Timers: Uptime/Expires
Interface state: Interface, State

(2001:19::19, FF08::19), 00:00:10/00:03:19, flags: SP
Incoming interface: Ethernet0/0.47
RPF nbr: FE80:47::4
Outgoing interface list: Null

In fact, I notice in case with IPv6, the (*,G) entry does not exists at all on the routers that are a part of the source tree. Of course, if any of these routers are also on the RPT path, they will have both the (S,G) and the (*,G) state instantiated. This agains differs from IPv4 where the (*,G) state is kept on all the devices on the RPT and the SPT for PIM-SM.

I am not sure if this is a specific IOS version behavior with IPv6 or a bug. It's also possible that the behavior was modified with IPv6 to prevent the router from maintaining the unnecessary state information.  I’ve been trying to locate any document that talks about this discrepancy between IPv6 and IPv4 PIM behavior, however, haven't found any as yet.

Regarding this :

Can you possibly explain in a different way the part about S1 having to send traffic to the RP on the shared (RPT) tree? I thought joining a shared tree was always from an RP, to get multicast data, not "pushing" it there.

You are correct in your statement above. For PIM-SM shared trees are joined only to receive multicast traffic from the RP and aren’t used to forward traffic to the RP. There are other operational modes of PIM that allow traffic to flow up and down shared trees.

[sarahanand]

Duplicate -- Please see my other reply.