Multicast PIM questions

[vv0bbLeS]

Hello all,

Diving into the PIM "routing protocol" and have a few questions:

1. PIM neighborships - if PIM does not send out any routing updates to its neighbors, what is the point of a PIM neighborship? (In my packet captures, all I ever see are PIM "Hello" messages and that's it).
2. Is PIM what puts the dynamic routes in the mroute table? (according to the "method" you chose of course, e.g. dense-mode, sparse-mode, etc.)

[Giuseppe Larosa · Accepted solution]

Hello @vv0bbLeS ,

1) PIM neighborships are needed and they are mantained by PIM Hello packets. A multicast enabled router needs to know on what interfaces are connected live PIM neighbors because for example in PIM sparse mode the PIM join message has to be sent on the path towards the RP address (at first ) and the source addess of a (S,G) pair. As for other protocols like IGPs the PIM neighborships has a key role . Sending  a PIM join out of an interface where no PIM router is present would be useless.

2) Is PIM what puts the dynamic routes in the mroute table?

PIM does not advertise IP prefixes for multicast purposes like it happens with MP BGP address family ipv4 multicast. 

Rather the ip multicast routing table is populated by seen traffic for all alive (S,G) pairs or (*,G) pairs depending on the PIM mode.

To be accepted traffic must pass the RPF check for the source of the (S,G) or for the RP address for (*,G) when applicable.

The PIM protocol expresses the current interests of each PIM router depending on downstream receivers and other PIM routers as PIM joins for PIM sparse mode or as PIM prune ( "I'm not interested on this Group G") for PIM dense mode.

All these interests have to be renewed and mantained over time by sending again a PIM join or a PIM prune towards the upstream device ( nearest to the source)

To be noted the RPF check is performed on the actual source S of the (S,G) pair.

The group G is examined only if there is some form of filtering on the receiving interface or if the network is configured for a mix of PIM modes like PIM sparse mode and PIM SSM or PIM sparse mode and PIM Bidir .

For example you can have a range of groups for PIM SSM  default is 232.0.0.0/8 

A range of groups for PIM Bidir and so on.

So the router acts on a (S,G) examining the source for the RPF check and the group G to see how to handle the pair.

Hope to help

Giuseppe

[Joseph W. Doherty]

#1

. . . what is the point of a PIM neighborship?

That's explained in @Giuseppe Larosa 's reply.

(In my packet captures, all I ever see are PIM "Hello" messages and that's it).

Two possible reasons for that.

First, Packet Tracer often is missing features, and/or they don't function correctly.

Second, as you haven't explained what you've tried using multicast, cannot say what PIM should be sending as its packets.

#2

Somewhat overlapping with @Giuseppe Larosa . . .

PIM doesn't need place dynamic routes into its mroute tables, but it does record active multicast flows information, though.  PIM uses unicast routing information for routing information.

Possibly, calling this table a mroute table, for PIM, is somewhat inaccurate, as it's unlike other supporting multicast protocols, like DVMRP which actually do its own routing.  "mroute" table, as a name for it, seemed suitable.  I.e. don't assume whatever something is named, is always the best possible name, especially as technology evolves.

An example of naming, perhaps not being ideal, in the past, on these forums, one poster was somewhat indignant that I referred to HSRP as not really being a virtual router (which some platforms now support) as it's just a virtual address.  What the person noted was that the "R", in the acronym was for "router"!  That, of course, is correct.  But at the time Cisco named it, it was, pretty well, representative of its common functional usage.  Later, Cisco provided GLBP, which doesn't use "router" which is also true in the generic acronym name FHRP, for this kind of protocols.

[vv0bbLeS]

Excellent, thank you both! I'm playing around in Cisco Modeling Labs (CML) and setting up multicast between 2 IOL switches, but for PIM I only ever see the Hello messages (which is leading to my confusion), so I may need to try a different switch image like the 9000v to see other PIM messages.

But essentially it sounds like for #1 "Why do we need PIM neighborships" it seems like the PIM neighborships are a critical part of the router building the "tree" that PIM will use, i.e. "what other multicast routers are out there running PIM, so I know who to send join/prune messages to"

And for #2 "Is PIM what puts the dynamic routes in the mroute table" - it sounds like there are a few things going on (not sure if these are correct or not):

1. The "mroute" table is just a list of "valid" (S,G) or (*,G) messages the router has seen on its PIM interfaces (valid = RPF check passes).
2. The entries in the "mroute" table are just an expression of the current "interests" of each PIM router in the topology, i.e. the "mroute" table is how a PIM router keeps track of who is interested in what. To actually route the multicats traffic, the unicast routing table is used.
   
   
3. The "mroute" table is poorly named, since it is not actually used for "routing" ? @Joseph W. Doherty  if you had to give the "mroute" table a more accurate name, what would you call it? (this will probably help my understanding of it)

[Joseph W. Doherty · Accepted solution]

---

@vv0bbLeS wrote:

1. The "mroute" table is poorly named, since it is not actually used for "routing" ? @Joseph W. Doherty  if you had to give the "mroute" table a more accurate name, what would you call it? (this will probably help my understanding of it)

---

Hmm, I didn't write the mroute table is poorly name, I wrote "Possibly, calling this table a mroute table, for PIM, is somewhat inaccurate, as it's unlike other supporting multicast protocols, like DVMRP which actually do its own routing."  I note this because, "possibly", denotes, IMO, and "somewhat inaccurate", denotes, (also possibly) it's not the "best" name.  However, for choosing a "better" name, IMO, perhaps "multicast flow table".

To quote The Bard, "What's in a name?".  I'll reserve comment on roses, but in technology, it's not common there are multiple "names" for the same concept, especially between equipment vendors.  ; )

What's more important than the name, is, as you write, "understanding of it".

For understanding (classical) multicast, it's important to remember, how multicast works, as least basic Cisco PIM multicast.

In PIM dense mode, actually no "routing" is required at all.  The source transmits, and all multicast hops relay the flood.  So, multicast goes, by default every where.  What DM hops do, if they don't want a particular flow, they tell their PIM transmitting neighbors, to stop sending them the multicast flow.  It gets more involved in topologies that support multiple paths, as if a multicast flow is desired, duplicate flows are pruned.

Possibly, DM can be thought somewhat like working like spanning-tree, were flows are from the "root" (multicast source), to the edge, and hops are blocked or not, per particular multicast flows.

Key to understanding, though, what's the best interface toward the "root".  That needs to be available in the unicast route table.

PIM is "routing", but using the unicast route table.  PIM, itself, need not concern itself with maintaining a multicast topology, because it uses the unicast routing topology.  (BTW, with something like DMVRP, the multicast topology can be logically different from the unicast routing topology, as they are not shared.  [The latter, somewhat like running two unicast routing protocols, side by side, "sharing", or not, paths.]) 

In PIM sparse mode, when a PIM hop detects a multicast flow is desired, a message needs to be relayed to the RP, so the best path to the RP is needed.  When the RP received that message, it needs to relay a message to all PIM neighbors, along the best path, to the source network, to send the multicast flow, to it (and it in turn forwards the flow back along the path from the original request).  So, SM needs to "know" the path to the source network, which it doesn't have (unlike DMVRP), but which it expect that information to be found in the unicast routing table.  I.ve just described PIM using a "shared" tree (flows to/from RP), but it's capable of redirecting the multicast to flow along a "source" tree, i.e. possibly bypass the RP and to form a more direct path between source and recipients (i.e. a DM flow topology, but without flood/prune cycles).  Basically, PIM nodes need to coordinate not only to allow a multicast flow to flow, but its path.

The coordination, between PIM neighbors, requires more than just "I'm alive" messages, but PIM nodes, also need to know of their alive neighbors.  They don't need to "know" PIM neighbors, beyond their neighbors, because, certain information, is relayed between specific PIM neighbors, based on need and unicast routing tables.

For example, how would a DM RP know the "source" tree for every possible flow?  It doesn't, but the PIM nodes, starting with the last recipient node, can find the best next PIM node, toward the PIM source node, using its unicast route table.  I.e. it finds it way, PIM hop by PIM hop, and each PIM note, can find the RP and controls its interfaces, i.e. those it will replicate a multicast stream to.

Unsure the above will help your understanding, but multicast routing is somewhat backwards to unicast routing, it uses different rules, and PIM has its own rules because it uses the unicast routing table.

Laugh, and just to muddy the water further, Cisco doesn't transmit multicast to DVMRP nodes, but it can accept multicast from them, and can, I recall, inform a DVMRP router what multicast stream(s) it wants (or not).

To truly understand multicast routing, it's somewhat like learning routing all over again.

[Giuseppe Larosa]

Hello @vv0bbLeS ,

in reverse order :

>> The "mroute" table is poorly named, since it is not actually used for "routing" ?

see the show ip mroute as the multicast flows forwarding table for each (S,G) or (*,G) you have the incoming interface the OLIST = list of current outgoing interfaces 

>> and setting up multicast between 2 IOL switches, but for PIM I only ever see the Hello messages (which is leading to my confusion), so I may need to try a different switch image like the 9000v to see other PIM messages.

You would need at least some receivers or some devices acting as receivers

A trick that can be used in a lab is to use

ip igmp join-group x.x.x.x on a downstream interface to make a device to send out PIM joins upstream

To have also a PIM source in a physical lab you can use VLC to send out a UDP multicast stream ( attention to TTL)

Hope to help

Giuseppe

[Joseph W. Doherty]

---

@Giuseppe Larosa wrote:

>> The "mroute" table is poorly named, since it is not actually used for "routing" ?

see the show ip mroute as the multicast flows forwarding table for each (S,G) or (*,G) you have the incoming interface the OLIST = list of current outgoing interfaces 

"see the show ip mroute as the multicast flows forwarding table for each (S,G) or (*,G) you have the incoming interface the OLIST = list of current outgoing interfaces "

Exactly!

The "rub" is, is a forwarding table the same as a route table?  What's a L2 MAC/Interface table (used for L2 forwarding)?  Is that routing?  What does the spanning-tree table track which ports to block or not?  Is that routing?

If we were discussing DVMRP, that maintains a topology, but PIM uses unicast routing table to maintain topology.

It's not so much a question whether PIM "routes", it does, but, as to the contents of the mroute table,  it's usually after an active multicast flow presents itself, not precomputed routes, as maintained in a unicast route table.

I guess, what I'm hung up on, multicast routing is both unlike and like unicast routing, but to call this particular table a multicast route table, when, without any active multicast flows, it's empty, makes it much unlike a unicast route table.

Anyway, I like "multicast flows forwarding table", although a quick Internet search also uses the term Multicast Routing Information Base (MRIB).

---

@Giuseppe Larosa wrote:

A trick that can be used in a lab is to use

ip igmp join-group x.x.x.x on a downstream interface to make a device to send out PIM joins upstream

Indeed!

Also, it's the way I gotten DVMRP to obtain a flow FROM PIM.

Anyway, in a separate thread (?) recently, I mentioned dealing with a thread in the past were one poster believed HSRP (Hot Standby Router Protocol) was creating a virtual router.  At the (back then) time when there were no actual virtual routers, and you equated a gateway with a "router", possibly the name, then, was fine.  Today, though, we call such protocols First Hop Redundancy Protocol (FHRP), which better, I believe, describes them, without leading to possible confusion.

Likewise, when I think of routing, I think unicast routing, because multicast "routing" is so different, that having a (unicast) route table, and a (multicast) mroute table, makes them (possibly) seem, more alike than they are.  Laugh, of course, when I learned routing, I recall just having a "route table", but then, we now have Routing Information Base (RIB) and the Forwarding Information Base (FIB).

Maybe the above will shed some light both why I'm not 100% happy with "the mroute table" as a name, yet I don't consider it poorly named, just, perhaps, not as well named as it might have been.  Also, the name was likely chosen way, way back, early on, when you didn't "need" a "better" functional descriptive name.

[vv0bbLeS]

---

@Joseph W. Doherty wrote:

as to the contents of the mroute table,  it's usually after an active multicast flow presents itself, not precomputed routes, as maintained in a unicast route table.

I guess, what I'm hung up on, multicast routing is both unlike and like unicast routing, but to call this particular table a multicast route table, when, without any active multicast flows, it's empty, makes it much unlike a unicast route table.

---

Yes that is an interesting philosophical question!

I suppose if we consider that unicast routing is "destination-based," then it makes sense that we can have pre-computed routes in the unicast routing table, since we already know where we're going and we don't need traffic flows to tell us that. On the other hand, if we consider that multicast routing is "source-based," then I suppose it also makes sense that we can't have pre-computed routes in our multicast table, since with multicast we never really know our source OR our destination (laugh), since the traffic can of course be sourced from anywhere and be going anywhere.

But as with the Cisco screenshots above, multicast still maintains an MRIB (as you mentioned) and also an MFIB, just like unicast, and apparently multicast also makes use of CEF, just like unicast. But multicast routing is still freaky as it doesn't route "to" a multicast address like 224.4.4.4 (since 224.4.4.4 doesn't technically "exist" anywhere), so multicast essentially routes "backwards" (i.e. facing the source, i.e. Reverse Path Forwarding, which even that name uses the term "forwarding" and not "routing!").

So, is a "source-based" routing table, a.k.a. the multicast routing table, still a "routing" table, or is it more a "forwarding" table as in the name Reverse Path Forwarding? I can see why you "don't consider it poorly named, just, perhaps, not as well named as it might have been."

Thanks again for the discussion! This has definitely helped solidify the concept for me!

[Joseph W. Doherty]

I've still been thinking about the mroute table.  For me, the Cisco mroute name, in conjunction with PIM, just seems, intuitively, possibly not the best choice.  Mainly because of unicast routing, where we know what to immediately to do with any packet, using a unicast route table (or RIB).  Either we have route information, to forward toward the destination, or we don't, and if the latter, we drop the packet.

So, one would think, a multicast route table, would work much the same.  Either we have all the information within it, to route (forward) a multicast packet, or not.  It's been decades since I've used DVMRP (on non-Cisco hardware), but I recall, its multicast route table had all you needed to route, or not, a multicast packet.  (NB: actually, the route information was used for source RPF, to  construct distribution tree.)

PIM, though, "cheats", by accessing network topology information using the unicast routing tables.  This is explicitly described in the Cisco documentation you earlier quoted as:  "PIM uses the unicast routing information to create a distribution tree along the reverse path from the receivers towards the source."

PIM's multicast route table, by design, is incomplete.  Yet, PIM, using the unicast route table, can build its mroute table entries that can be used for multicast routing/forwarding.  Conceptionally, the PIM mroute table, possibly could be consider more a mfib rather than a mrib.  Or, possibly, if you prefix or suffix mroute with some form of "cache", that might better describe, "seeing" an active multicast flow's ingress interface and its output interface(s).

Oh, and for another aspect of PIM, have you stumbled across PIM snooping (not to be confused with IGMP snooping)?

I mention PIM snooping, because you've been looking for PIM messages beyond just "hello".  PIM snooping examines PIM messages to see if it should block particular mutlicast flows.

[vv0bbLeS]

---

@Joseph W. Doherty wrote:

Conceptionally, the PIM mroute table, possibly could be consider more a mfib rather than a mrib.

---

Yes I think you're right, and to make it more confusing, the mroute table is its own entity apart from the mfib and mrib. To quote that same Multicast book chapter on IOSXE 17.12.x - Configuring Basic IP Multicast Routing :

Multicast Forwarding Information Base Overview

The uses the Multicast Forwarding Information Base (MFIB) architecture and the Multicast Routing Information Base (MRIB) for IP multicast.

The MFIB architecture provides both modularity and separation between the multicast control plane (Protocol Independent Multicast [PIM] and Internet Group Management Protocol [IGMP]) and the multicast forwarding plane (MFIB). This architecture is used in Cisco IOS IPv6 multicast implementations.

MFIB itself is a multicast routing protocol independent forwarding engine; that is, it does not depend on PIM or any other multicast routing protocol. It is responsible for:

• Forwarding multicast packets

• Registering with the MRIB to learn the entry and interface flags set by the control plane

• Handling data-driven events that must be sent to the control plane

• Maintaining counts, rates, and bytes of received, dropped, and forwarded multicast packets

The MRIB is the communication channel between MRIB clients. Examples of MRIB clients are PIM, IGMP, the multicast routing (mroute) table, and the MFIB.

---

So, I guess much like unicast IP protocols have RIB's (EIGRP RIB, BGP RIB) and the main unicast IP "routing table" and also the IP unicast FIB, so it appears that multicast also has a multicast RIB (MRIB), a multicast "routing table", and a multicast FIB. We can even look at these individually with their respective "show" commands:

• multicast RIB - show ip mrib { client | route | vrf }
• multicast routing table - show ip mroute
• multicast FIB - show ip mfib

But I agree that the mroute table is more a "forwarding" table than a "routing" table, in that we don't send packets based on IP, but rather based on the "outgoing interface list" on the multicast "route." So in multicast we're not really "routing" to an IP - we're "forwarding" out an interface.

But then you have to wonder why Cisco chose the name mroute table? Is there something we're missing here, or was it just to keep the concept similar to the unicast IP routing table? I may open up a TAC case on that to see what they say LOL

And no I haven't heard of PIM snooping! I'll have to read up on that!

[Joseph W. Doherty]

But then you have to wonder why Cisco chose the name mroute table?

I suspect, it was named that way, back when, there might not have been all the myriad tables we have today.  I.e. if you have a route table (show IP route), for unicast routing, then a multicast routing table would be its twin (show IP mroute).

Two additional things to keep in mind.  First, even something as "simple", as naming, isn't all that simple when it's a new thing.  Second, as technology evolves, shades of meaning also sometimes evolve too, which can distort a technical term meaning.

Simple example, "subnet" has a very specific meaning within classful addressing, but it's now used generically for any address block.  (For similar evolutionary reasons, "supernet" isn't much, if at all, used.)

If you investigate PIM snooping, insure you understand the issue it's solving.

[vv0bbLeS]

---

@Joseph W. Doherty wrote:
Hmm, I didn't write the mroute table is poorly name, I wrote "Possibly, calling this table a mroute table, for PIM, is somewhat inaccurate, as it's unlike other supporting multicast protocols, like DVMRP which actually do its own routing."  I note this because, "possibly", denotes, IMO, and "somewhat inaccurate", denotes, (also possibly) it's not the "best" name.

---

Ah yes, I used the phrase "poorly named" as the gist of what I understood you to be saying there, but that comes across a bit harsher than what you said, so apologies there, and I'm glad you put the correction.

Thank you so much for the great overview of multicast PIM routing! I've got a lot of notes on the subject already but writing it here in this forum as a discussion does help the concept sink in a bit more, and I appreciate all the time you took to write all that out! Very helpful indeed.

And you're right, multicast routing is strange in the traditional sense. Traditional unicast routing is concerned about routing traffic to the destination, while multicast routing is concerned about routing traffic away from the source. If unicast routing is like driving down the road toward a town, Multicast routing is almost like driving down the road while looking in the rear-view mirror back to your house. This article IP Multicast Technology Overview - Cisco had a good section that solidified that concept for me:

Multicast Forwarding

In unicast routing, traffic is routed through the network along a single path from the source to the destination host. A unicast router does not consider the source address; it considers only the destination address and how to forward the traffic toward that destination. The router scans through its routing table for the destination address and then forwards a single copy of the unicast packet out the correct interface in the direction of the destination.

In multicast forwarding, the source is sending traffic to an arbitrary group of hosts that are represented by a multicast group address. The multicast router must determine which direction is the upstream direction (toward the source) and which one is the downstream direction (or directions). If there are multiple downstream paths, the router replicates the packet and forwards it down the appropriate downstream paths (best unicast route metric)—which is not necessarily all paths. Forwarding multicast traffic away from the source, rather than to the receiver, is called Reverse Path Forwarding (RPF). RPF is described in the following section.

Reverse Path Forwarding (RPF)

PIM uses the unicast routing information to create a distribution tree along the reverse path from the receivers towards the source. The multicast routers then forward packets along the distribution tree from the source to the receivers. RPF is a key concept in multicast forwarding. It enables routers to correctly forward multicast traffic down the distribution tree. RPF makes use of the existing unicast routing table to determine the upstream and downstream neighbors. A router will forward a multicast packet only if it is received on the upstream interface. This RPF check helps to guarantee that the distribution tree will be loop-free.

---

Anyway, in terms of my OP, I was still struggling with #2, basically "where" do the entries in the mroute table come from. Your overview inspired me to go look at the literal Cisco documentation for Multicast.

There is a great overview of IOS 17.12.x multicast here: https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9300/software/release/17-12/configuration_guide/ip_mcast_rtng/b_1712_ip_mcast_rtng_9300_cg/ip_multicast_routing___technology_overview.html 

In that article, there are a few great sections that describe how multicast is handled in hardware and how the multicast tables are built. I've pasted 2 screenshots from the article below that deal with this #2 question of "Is PIM what puts the dynamic routes in the mroute table?" (I tried to be brief with the screenshots below, so as not to blow up this thread, and this post is already getting long, yikes! ) :

First, a screenshot showing some tables in hardware that are used by Multicast:

This second screenshot is showing how IOSXE builds the MFIB table (basically it takes the CEF concept and applies it to the Multicast tables also). It seems to say that PIM/IGMP are the ones that create the entries in the mroute table.

So, to the OP questions, it seems the answers are:

1. PIM uses neighbors to send PIM Join/Prune messages for building the multicast tree.
   
   
2. PIM and IGMP are what populate the entries in the Multicast Routing Table (or the Multicast "Flow Table" - ha). This was mentioned by @Giuseppe Larosa in his first post above when he said "Rather the ip multicast routing table is populated by seen traffic for all alive (S,G) pairs or (*,G) pairs depending on the PIM mode." - just took me a while for that to sink in I guess! lol
   1. Also, PIM makes use of the unicast routing table when populating the Multicast Routing table as noted by @Joseph W. Doherty in his first reply, "PIM uses unicast routing information for routing information."
      1. This can also be seen in the Cisco quote above the screenshots (Multicast Forwarding and Reverse Path Forwarding (RPF) ).
         
         
   2. The fact that PIM populates the Multicast Routing Table is also seen in the same IOS 17.12.x link above, just in the chapter on Configuring Basic IP Multicast Routing :
      1. "You must configure the PIM version and the PIM mode. The switch populates its multicast routing table and forwards multicast packets it receives from its directly connected LANs according to the mode setting."