Multicast Sparse Mode (*,G)

[mac_mac_net83]

HI All, 

For PIM sparse-mode environment, does (*,G) entries on the show ip mroute table (last hop router) , means multicast traffic from the RP is flowing down and I can join the group? 

Do I need the (S,G) group to be present in order for the host to receive multicast traffic?

What happens for some reason, that for (S,G) , the incoming interface is Null ,  because there is no known route to the source, but you still have (*,G) entry present and the route to RP is fine?

I believe the host will not be able to join the group , but having the (*,G) present , does it mean that MC traffic continuously flows from the RP down to the last hop router?

Any feedback is appreciated. 

Mac

[Giuseppe Larosa · Accepted solution]

Hello Mac,

receiving multicast traffic from a source S for which there is no explicit route should be possible if you have a default route, in that case the router will be able to pass the RPF check if traffic is received on the interface that is the outgoing interface to the default route.

If no route to the source S exists and also no default route exists or traffic is received on a different interface, RPF check fails and the router device will simply discards the received multicast packets from source S for (S,G) entry.

Edit:

about your other questions the (*,G) entry is enough to join the shared tree rooted at the RP.

However, just after receiving one multicast packet (S,G) the default SPT threshold allows the router to start a switchover to source based tree. The source based tree will reuse the shared tree until possible (until a device will have different RPF paths to the RP address and to the source address)

Once the router is starting to received on the source based tree it will prune itself from the shared tree (RP bit set in PIM prune message) to avoid to receive two copies of each packet.

Hope to help

Giuseppe

[mac_mac_net83]

HelloGiuseppe, 

Thanks for your feedback. 

Yes, assuming for my (S,G) entry , the RPF fails, understand that it will simply discard the packets. 

However, (*,G) entry is still there, which passes the RPF checks, does this mean that the multicast traffic is still flowing from the SOURE -> RP -> downsteam routers -> last hop router , all the time assuming the  receiver continously sends join for the group?

Is that actual multicast traffic or just PIM - join messages?? I am assuming it is MC traffic.

Mac

[Giuseppe Larosa]

Hello Mac,

in my working experience when the RPF Check is failed the traffic is dropped.

So I would say you can see the (*,G) entry on all routers downstream and also on the last router connected to the receiver but the receiver will not be able to receive the traffic from source S if RPF fails.

Multicast packets of (S,G) can flow to the last hop router just to be dropped there if RPF check fails.

The RPF check is needed to avoid unnecessary flooding of multicast traffic.

You can fix the RPF check with an appropriate mroute (multicast static route) for the source IP subnet to point to the interface that receives the traffic.

ip mroute

note: the ip mroute command does not support floating (admin distance parameter)

A single ip mroute command is supported pointing to an interface and next-hop.

Hope to help

Giuseppe

[mac_mac_net83]

HI Giuseppe

I do appreciate all your comments, thank you very much.

Multicast packets of (S,G) can flow to the last hop router just to be dropped there if RPF check fails.

The RPF check is needed to avoid unnecessary flooding of multicast traffic.

From your comment above, yes the receiver will not be able to received the feeds.

But with the (*,G) still present, am I right to say that a stream of Multicast traffic still flows from the Source - RP - Last Hop router and continue to utilize some bandwidth even though the receiver cannot receive them?

Mac

[Giuseppe Larosa]

Hello Mark,

>> But with the (*,G) still present, am I right to say that a stream of Multicast traffic still flows from the Source - RP - Last Hop router and continue to utilize some bandwidth even though the receiver cannot receive them?

Yes, it would be a waste of bandwidth but it can happen, for this reason I have suggested the ip mroute command

Hope to help

Giuseppe

[Hector Gustavo Serrano Gutierrez · Accepted solution]

Hi @mac_mac_net83,

Additionally to the useful information Giuseppe has shared with you.

(*,G) in the LHR (Last Hop Router) actually indicates that a host in the LAN segment (willing to receive the Multicast stream) has sent an IGMP Membership Report packet and this LHR (PIM DR in the LAN segment) has received it. Another command that confirms the LHR has received this IGMP packet is show ip igmp group x.x.x.x where x.x.x.x is the Multicast group.
With the (*,G) created, the LHR attempts to send a PIM Join to the RPF IP towards the Rendezvous Point (RP). Confirm this RPF IP with show ip rpf x.x.x.x where x.x.x.x is IP of the RP for the Multicast Group. Note that this RPF IP must be a PIM neighbor (show ip pim neighbor) for the PIM Join to be sent.
The additional presence of the (S,G) in the LHR's mroute table (show ip mroute) suggests the LHR is receiving the Multicast stream (Shared-Tree to the RP has been built) and forwarding it to the LAN receiver. Note that the LHR does not create any (S,G) and can still be receiving the Multicast traffic only if ip pim spt-threshold infinity is in the configuration.
Counters increasing in show ip mfib count output (under the appropriate Group) are useful to confirm Multicast traffic is being received and forwarded to the LAN.

Once the LHR has started receiving the Multicast traffic via the Shared-Tree, by default it adds the (S,G) additionally to the existing (*,G) as you know.
With the (S,G) created, the LHR attempts to send PIM Join to the RPF IP towards the Source of the Multicast stream (show ip rpf y.y.y.y where y.y.y.y is the IP of the Source of the Multicast traffic) in order to build the Source-Tree. Note that this RPF IP must be a PIM neighbor for the PIM Join to be sent.

Otherwise, if the LHR does not have a route towards the Source (Incoming interface is null) the PIM Join towards the Multicast Source is just not sent and the Multicast traffic is still being received via the Shared-Tree (*,G) and forwarded to the receiver behind the LAN interface.

Remember, this is the LHR. If it were another PIM transit Router then yes, the RPF failure by the multicast arriving to the incorrect incoming interface defined by the S,G would be dropping the traffic.

If you run show ip mroute at this very moment, you should see the J flag set(J - Join SPT) but not the T flag (T - SPT-bit) next to the (S,G)

As a conclusion:
In this specific scenario where the Incoming interface is Null for the (S,G) in the LHR, traffic to the receiver's behind the LAN interfaces is still forwarded by the Shared-Tree (*,G).

I hope this helps to resolve your concern and bring more clarity in how to troubleshoot this portion of the PIM control-plane logic.

[mac_mac_net83]

Thank you...so this concludes that (*,G) with combination of (S,G) with IIF status is NULL , still indicates that MC traffic is still forwarded via the shared tree. 

Also, I noticed that other combination along the shared tree branch...

(*, G) S , and (S, G) PR , does not forward any multicast traffic at all, since it is a result of a switchover possible made by the last hop router. I believe they are pruned...