Multicast Routing - 2 Vlans over a 6500 couple... Dense Mode?

[hgans]

Hi,

the frequently Dense Mode flooding behavior is not optimal in most scenarios, so the recommendation is to use Sparse or Sparse-Dense with AutoRP in almost all cases.

But if there is only one Routing hop from the Multicast source to the receivers (as shown in my simple drawing attached)....

Do you see any reason why not using the quite more easy Dense Mode on the Vlan Interfaces of both 6500 in that case?

As far as I understand, Multicast traffic is only forwarded from source Vlan to destination Vlan, if there is a Join received on the Client Vlan side- also in Dense Mode.

I don't see advantages in using Sparse Mode PIM Routing with only one Routing hop...

and together with IGMP Snooping on both LANs there is the same efficiency either...

Is there anything else to take account of using Dense Mode instead of Sparse in this scenario?

Thanks in advance for any inputs!

[Peter Paluch]

Hello,

In your case, there is practically no difference in the behavior of PIM-DM and PIM-SM. Considering the fact that you are probably not going to have an exorbitant count of (Source, Group) pairs, I see no advantage in running the PIM-SM in your network.

Personally, I would also opt to use the PIM-DM. Should a need arise, the conversion to the PIM-SM is simple but so far, I think that the PIM-DM is just fine for your needs.

Best regards,

Peter

[Jon Marshall]

As far as I understand, Multicast traffic is only forwarded from source Vlan to destination Vlan, if there is a Join received on the Client Vlan side- also in Dense Mode.

Dense mode does not work this way, whereas sparse mode does. With dense mode the multicast traffic is flooded across all vlans with PIM enabled on the interfaces and it is then up to the routers/L3 switches to send prune messages back if they do not want to receive this traffic. So it is a lot less efficient than sparse mode. And the traffic will be flooded regardless of whether a join has been received or not. In addtion there is also periodic flooding after that which the routers/L3 device must again send back prune messages if they do not want to receive the traffic.

Having said that it really depends on how much multicast traffic you are talking about and it is on the same switch. If the traffic is not great then yes you could use dense mode although to be honest it's not much more config to use sparse mode. If you use dense mode just keep an eye on 6500 performance.

Jon

[Peter Paluch]

Hello Jon,

Can I ask you a few questions? You made me rethink some things that I've understood differently.

With dense mode the multicast traffic is flooded across all vlans with 
PIM enabled on the interfaces and it is then up to the routers/L3 
switches to send prune messages back if they do not want to receive this
 traffic. So it is a lot less efficient than sparse mode. And the 
traffic will be flooded regardless of whether a join has been received 
or not.

This is interesting - I have understood the PIM-DM flooding a little differently. In particular, I thought that the flooding is initially done only on two types of interfaces:

• those that have PIM-DM neighbors identified by receiving Hello packets from them (transit interfaces)
  
• those that have end stations joined to a particular group via IGMP (stub interfaces)

My understanding was that interfaces that are enabled for PIM-DM but which do not have any PIM-DM neighbors identified nor any end stations joined via IGMP will not be placed in the oif list. Am I assuming this wrongly?

In addtion there is also periodic flooding after that which the 
routers/L3 device must again send back prune messages if they do not 
want to receive the traffic.

Actually, this is not true for quite a time. Since the IOS 12.1(5)T, the PIM-DM was enhanced by a so-called State Refresh capability that allows routers to verify the Prune state without reflooding the multicast traffic. The State Refresh capability, first described in a draft by Isidor Kouvelas, was retaken into the current RFC 3973 specifying the entire PIM-DM operation. More info can be found here:

http://www.cisco.com/en/US/docs/ios/ipmulti/configuration/guide/imc_pim_dense_rfrsh_ps6350_TSD_Products_Configuration_Guide_Chapter.html

http://tools.ietf.org/html/draft-kouvelas-pim-refresh-00

http://tools.ietf.org/html/rfc3973

Best regards,

Peter

[Jon Marshall]

Hi Peter

Can I ask you a few questions?

You can always ask questions although usually that is your very polite way of saying "actually Jon, can i just correct you"

Firstly, i wasn't aware of the refresh capability so thank you for that, learn something new every day.

As for PIM-DM flooding, dealing specifically with the downstream router ie.not the IGMP issue which i agree with, you are correct and i was being too simplistic in my explanation. There must be a downstream PIM enabled router for the upstream router to flood the traffic to otherwise there would be no need to flood.

I think perhaps that break i talked about before is fast approaching.

To the OP, apologies for the somewhat misleading information, Peter's explanation is more accurate.

Jon

[Peter Paluch]

Hi Jon,

You can always ask questions although usually that is your very polite way of saying "actually Jon, can i just correct you" 

LOL Jon, you are a true gentleman. Still, we both know that there is a good chance of me being wrong - there's no such thing as a "patent on guaranteed wisdom". It would not be appropriate to start the discussion in any other way, especially considering your vast knowledge and experiences. As a matter of fact, I feel always honored by the opportunity to discuss things with you.

Best regards,

Peter

[Adam Casella]

Hey,

It depends if there are multiple PIM interfaces or not.  You say that this device is only one hop away, but I am not sure if there are multiple PIM neighbors on this device.

If there is only one PIM interface, Dense mode will flood out that interface every 3 minutes and then prune when a join is not heard.   IGMP snooping on the layer 2 switch will restrain this stream until an IGMP membership report is heard and programmed.  So the difference here would be you would flood every 3 minutes to all the PIM  interfaces compared to Spare mode.

With that said, I would recommend PIM sparse mode still, if you ever plan on increasing the size of this multicast domain (add any other PIM interfaces).

The configuration would not be much different in this case.  The only major differnence from a configuration standpoint would be the addition of an RP (which would be either this device or the next hop) and making the interface configuration to specify pim spare mode.  You could either statically set the PIM RP or select the RP via auto-rp or BSR. Setting the device makes this operation simpler, but less redudant.

This would put you in a much better situation for the future if you ever wish to expand this domain.

Thanks,

Adam

[hgans]

Thanks Jon, Peter, Adam for your opinions.

I am also with Peters arguments.

Regardless if I use DM or SM - in both cases the flooding ends at PIM Interfaces where no PIM neighbors are if this "PIM barrier Router" has no joined Hosts on its segments.

Also the Pruning mechanism in PIM-DM is only usable by PIM Routers towards its neighbors- and I have only 2 6500 in my setup- from a PIM perspective I would say they count as 1 box.

With the Assert Messages, that are used if more than one Router is attached to a LAN, there is additional optimization - only 1 of my 2 6500 will forward the Multicast into the Host Vlan.

So, in my case there is no PIM neighbor:

I have 2 Vlans participating in Multicast Routing (PIM on 2 Vlan Interfaces) and their Layer2 are spanned across the 2 6500 (classical HSRP setup) - no additional Layer 3 Components talking PIM with them.

Sure, there is flooding at least on the Vlan were the Multicast sender is located...

Question by the way: Does IGMP Snooping work on the Multicast sender Vlan access switches? - There are no Joins, how is a sender usually reacting on IGMP Report messages?

On the "receiver Vlan" IGMP Snooping should work as expected.

The Access Switches see the Join/Report messages and populate their CAM tables accordingly to forward only on necessary interfaces.

The 2 6500 should administer the IGMP information and decide if Traffic from a specific Multicast group needs to be forwarded or not.

Regarding the easy Configuration:

You are right, its about 3 commands to do Sparse success- but there is a lot of stuff behind it if you have to troubleshoot.

One example is the initial unicast encapsulation from sender Mcast Router to the RP - and this is only a small initial part in an appx.15 step procedure until a (S,G) SPT is finnaly established.

Anybody else disagree with my theory that DM has same efficiency in my setup?