Multicast Dense-Mode

[Munesh Daryanani]

Hi All,

I'm having a play around with Cisco Dense mode and trying to understand multicast in mode detail.

I've attached a sample network diagram, where R5 router is a multicast server and R4 is a multicast receiver for address group 239.1.1.1.

When i run "show ip mroute" from router R3 which is the uplink for R4, I'm getting the below two outputs

R3#show ip mr 239.1.1.1
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,
       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
Outgoing interface flags: H - Hardware switched, A - Assert winner
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.1.1.1), 00:07:26/stopped, RP 0.0.0.0, flags: DC
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    FastEthernet0/1, Forward/Dense, 00:07:26/00:00:00
    FastEthernet0/0, Forward/Dense, 00:07:26/00:00:00

(10.1.2.2, 239.1.1.1), 00:04:17/00:02:57, flags: T
  Incoming interface: FastEthernet0/1, RPF nbr 10.1.3.1
  Outgoing interface list:
    FastEthernet0/0, Forward/Dense, 00:04:18/00:00:00

R3#

I understand that the last entry (10.1.2.2, 239.1.1.1) has to do with the SPT.

What confuses me is that why is there another entry (*, 239.1.1.1), 00:07:26/stopped. The question I've got is:

What does the flag "stopped" means here ?

Also why is there this entry to begin with when there's already a (10.1.2.2, 239.1.1.1) entry.

I've gone through Cisco multicast troubleshooting and configuration guide, but there's no explanation for (*, 239.1.1.1). Is this a cisco IOS version specific output ? I'm using IOS version 12.4(15)T14 in GNS3 to understand multicast.

PS: A multicast newbie here :)

Thank you for your help.

[Jon Marshall · Accepted solution]

You should ignore the (*, G) entries (where G = the group address) when running PIM dense mode because they are not relevant.

Those entries are only used when running PIM sparse mode because they represent a shared tree. They are there with dense mode simply to maintain consistency in the mroute output as far as I am aware and you will see them with all IOS versions.

When you get round to sparse mode you will see that both entries are relevant because you have a shared tree represented by the (*, G) entry and a source specific entry after the SPT switchover assuming there is one (which there should be by default).

Jon

[Munesh Daryanani]

Thank you for the answer and help Jon.

[Peter Paluch · Accepted solution]

Hi Jon,

My friend, I cannot even put into words how glad I am to see a post from you again! It is so good to see an answer from you in these forums once more!

One detail regarding the (*,G) entries in Dense Mode: This is likely vendor-specific, but in IOS, these entries are actually used as templates, and the (S,G) entries are cloned off these templates.

Think of this:

• When a PIM-DM router receives an IGMP Any Source Multicast Join for a group G it does not know about and for which it has no (*,G) or (S,G) entries, it cannot directly act on it because the source is not known. In that case, a (*,G) entry is created with an empty IIF (Incoming Interface), and in the OIL (Outgoing Interface List), it will contain all interfaces that would be eligible to flood down the multicast for this group. These interfaces would include interfaces toward other PIM neighbors, and interfaces where an IGMP Join for this group was received.
• Later, when a particular (S,G) packet comes in through a proper RPF interface, the router will clone an (S,G) entry off the (*,G) entry by moving the RPF interface from the OIL into IIF, and forward the traffic according to this (S,G) entry.
• Similarly, assuming that the router knows nothing about a group G yet, and even no IGMP Join was received for it, then when a particular (S,G) packet comes in, the router will first create a (*,G) group with an empty IIF and OIL consisting of all interfaces toward neighboring PIM routers, and then, if the packet came through proper RPF interface, it will clone an (S,G) entry off the (*,G) entry, again moving the RPF interface from the OIL into IIF, and using it to forward data.
• IGMP Joins and Leaves for Any Source Multicast will affect both the (*,G) and all (S,G) entries.

Truth be told, I am not entirely sure at this point how this would change for Source Specific Multicast, as obviously, SSM should operate on (S,G) entries only, but IOS always uses the (*,G) entries together with (S,G) - I would need to test this.

Hope to find some time during this week for this.

I sincerely and wholeheartedly hope to see you posting more again! CSC just wasn't the same without you.

Best regards,
Peter

[Peter Paluch]

Hi Jon, Munesh,

Actually, I was able to test the Source Specific Multicast (SSM) pretty fast after all, and the behavior is equally easy to explain: With PIM-DM and SSM, the (*,G) are not created, period. Only ASM prompts the creation of (*,G) entries in PIM-DM.

Best regards,
Peter

[Jon Marshall]

Peter

Apologies for delay in responding but been having troubles with my ISP recently.

Hope all is well and you are enjoying your new job with TAC.

Jon