Static Multicast Routes and Group Memberships
Problem
You want to override the dynamic multicast routing and group membership with static entries.
Solution
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 239.5.5.55
Router1(config-if)#end
Router1#
Discussion
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 239.5.5.55
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 239.5.5.55 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.