Multicast questions - PIM passive & IGMP

[ChrisNewnham_]

Hello, 2 questions about multicast:

1) When configuring PIM passive, can you configure it on the source router, destination router, and intermediate nodes? I believe you can.

2) I believe IGMP is only required to be configured on the destination device, however many SSM examples I've seen show IGMPv3 being configured on the source device as well - is this really required?

Thanks

[MHM Cisco World]

Hello, 2 questions about multicast:

1) When configuring PIM passive, can you configure it on the source router, destination router, and intermediate nodes? This I will check PIM passive with IGP path by lab.

2) I believe IGMP is only required to be configured on the destination device, however many SSM examples I've seen show IGMPv3 being configured on the source device as well - is this really required? You meaning router as PC receiver and need igmp' Yes only receive not sender need igmp with mutlicast group number.

[MHM Cisco World]

change the e0/0 in IOU1 to be IP PIM PASSIVE
e0/0 is used as IGP path from sender to receiver  when I config ip pim passive immediate the multicast drop 

[MHM Cisco World]

same lab but this time I change the e0/1 to be pim passive and since e0/1 is not IGP path between sender and receiver the multicast not effect at all. 
so you must be carefull in selecting which port be pim passive 

[MHM Cisco World]

For igmp why you are confused?

Any router recieve igmp inquiry must config with igmp.

can I config in all router? YES you can but it not need.

[Peter Paluch]

Hi Chris,

PIM Passive on an interface means no PIM packet exchange over that interface but multicast and IGMP still enabled.

So, it makes sense on the first-hop router toward the source, and on the last-hop router toward the subscribers. It does not make sense on intermediary routers and router-to-router links because there, active PIM message exchange is vital.

As for IGMP in any version, you are completely correct - it is purely a subscriber mechanism, so it only serves a useful purpose in the destination network where the end subscribers are. It does not make sense to enable it in source networks. The thing is, though, that on IOS/IOS XE devices, you cannot individually enable and disable IGMP to my best knowledge; you need to start PIM on an interface and optionally make it passive if you don't want PIM messaging there, but IGMP will still be running.

Best regards,
Peter

[Joseph W. Doherty]

"2) I believe IGMP is only required to be configured on the destination device, however many SSM examples I've seen show IGMPv3 being configured on the source device as well - is this really required?"

"As for IGMP in any version, you are completely correct - it is purely a subscriber mechanism, so it only serves a useful purpose in the destination network where the end subscribers are. It does not make sense to enable it in source networks."

Possibly another consideration might be source and destination might be on the same network, and as IGMP snooping isn't uncommon, and as IGMPv3 is used with SSM, SSM examples might show it active on a SSM source host and/or source network for that reason.  Also keep in mind a SSM receiver also could be a multicast source.

In other words, SSM examples might show IGMPv3 enabled, to insure correct operation even when, technically unnecessary.

[Peter Paluch]

Hi Joe,

Fair point : ) A network with combined sources and receivers and IGMP Snooping would require IGMP operable - and again, doesn't matter if it's Any Source Multicast with IGMPv2, Any Source Multicast with IGMPv3 or Source Specific Multicast with IGMPv3.

Note IGMP isn't there for the sources and subscribers on the common network to "find" each other - that's not necessary. Without IGMP Snooping, such multicast would be flooded across the entire common network. It's just the IGMP Snooping here that tries to optimize the multicast delivery - but for that purpose, it depends on IGMP.

Best regards,
Peter

[Joseph W. Doherty]

Peter, exactly!

As you've highlighted the technical workings, again, particular SSM examples, to avoid all that, just probably show IGMPv3 when actually not needed.

Possibly somewhat similar to why STP might be shown enabled/suggested when there are no redundant L2 paths.

[ChrisNewnham_]

Thanks Peter and all for commenting on this, much appreciated!

So on some examples I saw for SSM, IGMPv3 had been enabled on a completely different router and interface which happened to be the source interface, just "ip igmp version 3" - see https://networklessons.com/multicast/source-specific-multicast-ssm

I couldn't understand why the source would need this, and indeed, it appears it does not. The confusion seemed to come from this Cisco article with the line:

"To run SSM with IGMPv3, SSM must be supported in the Cisco IOS router, the host where the application is running, and the application itself."

https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750x_3560x/software/release/15-2_2_e/multicast/configuration_guide/b_mc_1522e_3750x_3560x_cg/b_mc_3750x_3560x_chapter_0100.html

However this is talking about SSM, not IGMPv3.

Also something else I've observed - if you enable the command "ip igmp join-group X source X" without using "ip igmp version 3", it also seems to work, despite only apparently having IGMPv2 on the interface. I will need to lab this up to understand why this is, but that is my experience.

---

@Peter Paluch wrote:

Hi Chris,

PIM Passive on an interface means no PIM packet exchange over that interface but multicast and IGMP still enabled.

So, it makes sense on the first-hop router toward the source, and on the last-hop router toward the subscribers. It does not make sense on intermediary routers and router-to-router links because there, active PIM message exchange is vital.

As for IGMP in any version, you are completely correct - it is purely a subscriber mechanism, so it only serves a useful purpose in the destination network where the end subscribers are. It does not make sense to enable it in source networks. The thing is, though, that on IOS/IOS XE devices, you cannot individually enable and disable IGMP to my best knowledge; you need to start PIM on an interface and optionally make it passive if you don't want PIM messaging there, but IGMP will still be running.

Best regards,
Peter

---

[Ramblin Tech]

When it comes to multicast, do not think in terms of source and destination routers. Instead, think in terms of sources and receivers which are end systems. The distinction I am making is that in destination-based routing, the path is created starting from the source, whereas in multicast this is turned around backwards.  That is, receivers express their intent (via IGMPv3/MLDv2) to receive multicast messages and a path (multicast distribution tree) is built from the receiver back toward the source. In your case, routers along the path from a receiver to the source build an MDT back to the source using PIM-SSM to create (S,G) and OIL state all the way to the source's PIM designated router. Putting an interface into a PIM-passive state tells a router not to send PIM control messages and not to form PIM adjacencies over that interface. This can reduce unnecessary traffic in some cases, but can also break uRFP checks if the ucast routing table says the best path to the source is over a PIM-passive interface. So, yes, you can make any interface PIM-passive, but be very careful as to why you are doing it.

[Peter Paluch]

Hello @Ramblin Tech ,

Thanks for joining!

This can reduce unnecessary traffic in some cases, but can also break uRFP checks if the ucast routing table says the best path to the source is over a PIM-passive interface.

This caught my eye. So you claim that the RPF (note - not uRPF as uRPF is related to unicast traffic verification through "ip verify source" per-interface command) may be broken if the incoming interface (IIF) is a PIM passive interface.

This is an interesting statement. It does make sense in a way, as an additional sanity check on the incoming traffic, but it also implies that the IIF was enforced through a static "ip mroute" command since it could not have been signalled by PIM - that one is disabled through the passive mode. Is this the scenario you have in mind? Are there any other scenarios? Can you perhaps also reference any documentation confirming this behavior?

Oh, and regarding sources on PIM passive interfaces - there is no problem there. Directly attached sources on PIM passive interfaces are accepted without problems, I've tested it.

Best regards,
Peter

[Ramblin Tech]

Hi @Peter Paluch The scenario I was envisioning was an intermediate hop where, let's say, the ucast routing table says the best path to the source is a next-hop out g0/0. If for some reason you configured g0/0 to be pim passive, then a mcast packet from that source would not ever arrive on g0/0 (ie, no PIM join ever sent upstream on g0/0 toward the source for this (S,G); upstream router consequently never has this link on its OIL for this (S,G)). Any mcast packet arriving at this intermediate hop from this source would not have come over g0/0 and therefore would fail the RFP check (my bad on multicast RPF vs uRPF). No question that PIM passive can work on an interface directly connected to the source and is a case where some amount of resources can be saved by going passive.

[Joseph W. Doherty]

Hopefully not to appear to pick on Ramblin, as Peter has already queried his post, but with:

"The distinction I am making is that in destination-based routing, the path is created starting from the source, whereas in multicast this is turned around backwards.  That is, receivers express their intent (via IGMPv3/MLDv2) to receive multicast messages and a path (multicast distribution tree) is built from the receiver back toward the source."

For those new to multicast, Ramblin is providing a high level description, because (I believe) actual mechanics are a bit more involved, work a tad differently based on the "kind" of multicast routing and/or options within some of the particular "kind" of multicast routing.

For example, with PIM-DM, the protocol works out a source tree structure, from the source to all possible destination networks regardless of receiving hosts, which may even be zero.  If fact, PIM-DM will "flood" a multicast stream, everywhere, again, regardless of whether any host wants the multicast stream or not.

For networks, that have no hosts desiring the multicast stream, PIM-DM will "prune" an active multicast stream from the edges back toward the source.  (NB: the source's gateway multicast router, always, I believe, gets the source's active stream[s].)

Multicast routing "knows" the topology, and possible paths, independent of active sources and/or active receivers, but how multicast packets are actually routed across the topology depends on the multicast protocol and where are the sources and receivers.

That's, what I believe Ramblin is describing when building a path in regard to "(multicast distribution tree)".

For another example, of differences, PIM-SM, PIM will have a RP which becomes the common point that sources (possibly only initially) direct their traffic to, and receivers (possibly only initially) will draw through (which Cisco refers to as a shared tree).

A PIM-SM multicast stream, that connects though the shared tree, though, might be converted over to something closer, if not an actual, source tree, on-the-fly.

Again, just wanted to clarify, some of what Ramblin described is high level conceptional, not necessarily, actually how it's actually accomplished.

[Ramblin Tech]

Hi @Joseph W. Doherty I am assuming PIM-SSM since SSM was referenced along with IGMPv3, so MDT is built from receiver's first-hop router back to source's first-hop router using PIM-SM; no dense mode flooding, no sparse mode RPs. But really, in 2023, why would anyone use anything but PIM-SSM?

BTW -- no worries about picking on my responses. My wrong and/or stupid comments are fair game.