Cisco's original implementation of DVMRP was a simple one; it performed DVMRP route exchanges and effectively ran Dense-Mode PIM over the resulting routing table, using DVMRP prune/graft messages instead of PIM messages.
DVMRP builds broadcast trees using its route exchanges; these trees are then pruned back to remove links which do not lead to group members. In contrast, Dense-Mode PIM floods traffic to all neighbors, and uses prunes both to remove branches that aren't in the broadcast tree and to remove links which do not lead to group members. Cisco's original DVMRP implementation simply built the routing table, ignoring the broadcast tree.
In loop-free trees, these algorithms are effectively equivalent, since there are not any links in the topology that are not part of the broadcast tree. However, in more complex topologies, Cisco's implementation will flood packets towards DVMRP neighbors which may have chosen a different parent for that source. The DVMRP neighbor will ignore the packet, since it knows that the broadcast tree is aready built and simply drops any packets arriving on an incorrect interface. Meanwhile the Cisco is waiting for a prune from the DVMRP neighbor, since the Cisco is still running Dense-Mode PIM.
Cisco implemented the DVMRP tree-building protocol, calling it "DVMRP conditional flooding." This has Bug ID CSCdj16719, and is fixed in IOS 11.2(6.4F), 11.3ED, and recent versions of 11.1MFIB. Any list of recommended IOS versions on this page would quickly become out of date; Cisco has a list of recommended IOS versions on their FTP server.
Cisco's documentation of the "DVMRP conditional flooding" feature
The 3.5 multicast kernel patches for Solaris (including what's shipped in Solaris 2.6) have an unfortunate bug: only the physical interface is used in the RPF check. This means that all tunnels on the same physical interface are considered to be the same interface for the RPF check. Packets that arrive on the wrong tunnel will be accepted if that tunnel terminates on the same physical interface as the right tunnel.
With DVMRP, this should not be a problem, as the duplicate-free broadcast tree is built by route exchanges. However, in combination with Cisco IOS's flooding behavior, this bug can cause duplicate packets and forwarding loops. Sun has a beta-test patch which is available below.
This combination of problem affects you if you are using Solaris for your multicast router and you have neighbors running Cisco IOS versions that do not have the bug fix for CSCdj16719.
RELEASED Patches:
PLEASE back up the following files before testing the beta patches!
/kernel/drv/ip /kernel/drv/arp /kernel/drv/tcp /kernel/drv/udp /kernel/drv/icmp
Bill Fenner - <fenner@research.att.com>
This material is based upon work supported by the National Science Foundation under Grant No. 9729498. Any opinions, findings and conclusions or recommendations expressed in this material are those of the author and do not necessarily reflect the views of the National Science Foundation (NSF).