You want to override the dynamic multicast routing and group membership with static entries.
By default, PIM will use the same dynamic routing table learned by the unicast routing protocol. However, in some cases you don't want to use these routes. For example, you might have to send multicast traffic through a tunnel to bypass a section of network that doesn't support multicast routing. In this case, the unicast routing table is clearly the wrong path for multicast traffic. So you need to specify a different route for multicast traffic to use:
Router1#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router1(config)#ip multicast-routing Router1(config)#ip mroute 192.168.15.0 255.255.255.0 192.168.98.6 Router1(config)#interface Tunnel0 Router1(config-if)#ip address 192.168.98.5 255.255.255.252 Router1(config-if)#ip pim sparse-dense-mode Router1(config-if)#tunnel mode gre ip Router1(config-if)#end Router1#
You can specify a static IGMP join to ensure that the router always thinks that there are group members on an interface:
Router1#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router1(config)#ip multicast-routing Router1(config)#interface FastEthernet0/0 Router1(config-if)#ip pim sparse-dense-mode Router1(config-if)#ip igmp join-group 22.214.171.124 Router1(config-if)#end Router1#
The static mroute command is used only to describe the Reverse Path Forwarding (RPF) path the multicast traffic should take. PIM doesn't redistribute this information, but all devices on the internal network need to know that this router is the gateway to this particular external network so that they can also build their SPT trees appropriately. So it is likely that other routers will also need static mroutes, if you are using tunnels like this.
Static multicast routes are most frequently used when the unicast network doesn't have the same topology as the multicast network. There are two main reasons why this might be the case. The recipe example suggests one of these reasons: there may be tunnels that bypass nonmulticast sections of the network.
The other common reason for using a static multicast route is to force multicast traffic to take a different path than unicast traffic. For example, you might have a separate network link for multicast traffic. As with all static routing, doing this creates administrative problems because it is very difficult to construct static routes that adapt to network failures.
The static IGMP Join example is most useful when there are devices on the segment that may have poor IGMP implementations or when they join and leave extremely rapidly. Alternatively, as in Recipe 23.19, the receiving devices may not know that this is a multicast application. A static IGMP statement ensures that the router always thinks that there are group members on this interface.
You should be careful about using this command on any links that contain other routers because it may lead to multicast routing loops. This is because the router will always forward packets for this group out this interface, even if PIM would normally prune this link from the tree. So this command should be used with extreme caution.
IOS levels 12.3(2)T and higher include the ip igmp static-group command as an alternative to the ip igmp join-group command. This command can specify an IGMP group, similar to the join-group command:
Router1(config-if)#ip igmp static-group 126.96.36.199
Or, if you are using source-specific multicasts, as allowed in IGMP Version 3, this command allows you to specify a particular source:
Router1(config-if)#ip igmp static-group 188.8.131.52 source 192.168.15.5
The other important difference between the join-group and static-group commands is that join-group forces the router to process switch multicast packets sent through this interface, while the new static-group variant employs the more efficient fast switching.