Multicast Question

[mdieken011]

I currently have a main switch Catalyst 9500 with a few SVI's configured with pim dense mode.  From all the reading etc. that I have done I understand that pim sparse mode is the lowest overhead version.  I have 2 questions.  I am looking at setting up multicast routing for the future with a 2nd location I have across a WAN.  I configured it with pim sparse mode.

1.  Is that a correct statement?

2.  Can I run dense mode and sparse mode on the same switch?

3.  Can I switch and the devices continue to work except for the brief interruption while switching?

Any help is appreciated.

Thanks,

[Giuseppe Larosa]

Hello @mdieken011 ,

you could use ip pim sparse-dense mode in interface mode.

At that points all group addresses G for which an RP exists wll be treated as Sparse Mode all other multicast addresses would be processed using PIM dense mode.

>> 2. Can I run dense mode and sparse mode on the same switch?

Yes if using ip pim sparse-dense mode see explanation above.  A given group G will be treated as Sparse or Dense globally not on a per interface basis using the criteria: is the RP address for this group known in any way  ( manually configured , learned via auto RP learned via Boostrap protocol) ?

>> 3. Can I switch and the devices continue to work except for the brief interruption while switching?

If you mean moving from dense mode to sparse mode yes you can do it and it will take some time to rebuild all the distribution trees.

PIM sparse mode works based on Explicit Join. Dense mode uses an opposite strategy of flood and prune: it expects all interfaces to have at least one receiver and so downstream routers need to send a Prune message to signal they are not interested in receiving a specific group G.  This creates an overhead as the Pruned state has a 3 minutes timer so dense needs to keep the state for each group Gx of each interface that is multicast enabled.

Hope to help

Giuseppe

[Joseph W. Doherty]

"From all the reading etc. that I have done I understand that pim sparse mode is the lowest overhead version."

BTW, that depends on what you consider to be "overhead".

Dense mode possibly has less of an impact on CPU consumption and/or lower memory footprint, both compute what needs to be done and managing what's done.  Both of which not generally as important as they were years (decades) ago.

[Giuseppe Larosa]

Hello @Joseph W. Doherty ,

my understanding is the following:

PIM Dense mode uses more resources ( state memory ) when :

- you have many groups Gx

- Each Group Gx has a distribution tree also known as the oilist that is a subset of the multicast enabled interfaces on the node.

The reason is that each Pruned state has its own per Group Gx per interface timer that needs to be refreshed ( refresh event can be a PIM Prune message or lack of answer to an IGMP General Query for the specific group Gx, a PIM Graft message or an IGMP report for the group Gx will move the interface to the forwarding state and in the oilist for the group Gx)

PIM Dense mode is more effective when :

every multicast enabled interface has at least one receiver for the group Gx

In a campus network this can be true for each user facing VLAN, but again it depends on what the group Gx content is.

If the group Gx is for example a video message from the company CEO that is going to be seen / received by each employee this group is a good fit for dense mode.

This is the reason why I would suggest to use ip pim sparse-dense mode at interfacre level and to partition the muticast address space having a block of IP addrreses or set of blocks that are associated / served by an RP.

All other Group addresses will be processed in dense mode

In this way it is possible to have the advantages of both PIM SM and PIM DM on the same network.

Hope to help

Giuseppe

[Joseph W. Doherty]

@Giuseppe Larosa "PIM Dense mode uses more resources ( state memory ) when :" . . .

Certainly possible, with/under the conditions you've listed.

Perhaps another condition would be, for SM, whether SM is using a shared tree or a source tree.?

However, again, I suspect resource utilization, or overhead of DM vs.SM, generally isn't often an issue.

Network bandwidth utilization is probably more of a key concern, and for that, generally, SM is the better case.

If network bandwidth utilization is a concern, allowing DM does make your network "vulnerable" to any host flooding your DM multicast domain.

Other then configuration/design simplicity, the only time I've found DM really needed is when doing multicast with other vendor equipment that doesn't support PIM-SM, but support DVMRP.

Oh, and one last network bandwidth utilization issue that can be overlooked is multicast bandwidth consumption between routers, not end hosts (dealt with the IGMP snooping feature).  For that, Cisco offers the PIM snooping feature.

[Giuseppe Larosa]

Hello @Joseph W. Doherty ,

>> Perhaps another condition would be, for SM, whether SM is using a shared tree or a source tree.?

With default settings the SPT threshold that decides when to perform switchover from Shared tree to Source base Tree is so low that as soon as the source of the multicast stream  is known on the PIM DR on receivers VLANs the switchover is started. The source based tree is rooted at the PIM DR serving the VLAN where the source is connected.

Depending on topology and source location the Source Based Tree can even not go via the RP.

In most cases the Source Based Tree reuses the Shared Tree with the additional of the RP joining the SPT sending the PIM Join to the PIM DR serving the source.

Actually, there is not a single solution that fits for all environments.

For example for scenarios where there are many multicast senders the use of Bidirectional PIM provides a lot of benefits saving on states. The shared tree rooted at the RP is used , and the RP can send and receive traffic over the branches ( here the name  Bidirectional).

An example of these many sources can be seen when using video cameras for security and each of them send over a different group Gx.

The video recorder server(s) just need to join one or more of these video sources.

Finally for scenarios that wants to implement the greatest security the use of PIM SSM Source Specific Mode in combination with IGMPv3 is preferred.,

With PIM SSM a channel is defined not only by the Group address Gx but also by the source Sy   the (Sy, Gx)    stream is not mixed with ( Sz, Gx) .

The IGMPv3 here is needed so that final receivers can use the include or exclude option to specify the source they want or the source(s) they do not want to receive.

In MPLS service provider environments the latest solutions is the NG MVPN that allows to support multicast for customers in their L3 VPN without running PIM in the backbone and without consuming precious multicast addresses in the Global routing table as it was done in first generation solution called draft Rosen  ( actually using  GRE encapsulation putting customer multicast packet within a service provider multicast packet).

>> Network bandwidth utilization is probably more of a key concern, and for that, generally, SM is the better case.

Yes I agree

Hope to help

Giuseppe