Configuring Routing for a Low-Frequency Multicast Application

Problem

You have a multicast application where the servers send packets less frequently than the standard PIM timeout intervals.

Solution

PIM-SM is best suited to this type of application. The configurations of the RP and BSR or Auto-RP routers for this example are identical to those shown in Recipes 23.2 and 23.3. The differences appear on the other routers in the network. So this recipe shows only the configurations for these other routers:

Router1#configure terminal 
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#ip multicast-routing
Router1(config)#ip pim spt-threshold 10 group-list 15
Router1(config)#access-list 15 permit 239.5.5.55
Router1(config)#access-list 15 deny any
Router1(config)#interface FastEthernet0/0
Router1(config-if)#ip address 192.168.1.1 255.255.255.0
Router1(config-if)#ip pim sparse-dense-mode
Router1(config-if)#exit
Router1(config)#interface Serial1/0
Router1(config-if)#ip address 192.168.2.5 255.255.255.252
Router1(config-if)#ip pim sparse-mode
Router1(config-if)#end
Router1#

 

Discussion

Discussion of multicast applications usually focuses on high-bandwidth applications. But some multicast applications have the opposite behavior. For example, some news broadcast type applications allow message servers to send short messages to a large group of users. This sort of service might be used for administrative purposes ("the server is going down in five minutes") or for business purposes ("stop selling widgets, the warehouse is empty," or "buy more Cisco stock"). In either case, all of the users in the group need to receive the message.

But there are three problems. First, in this sort of application you can't afford to waste the first packet while setting up your multicast distribution trees because it may be the only packet sent. Second, you don't want to worry about finding a more optimal tree after you've delivered the first packet because there isn't going to be another packet for a long time. And third, by the time the next packet comes along, all of the routing that the network set up for the first packet may have timed out.

There are many possible solutions to this problem. You could statically configure the entire multicast network using static multicast routes and group memberships, and not use a multicast routing protocol at all. But this is clearly an administrative nightmare to keep updated, and it would make it difficult to use the same network for other multicast applications. So the recipe shows a better solution.

It is useful to step through the network from group member to sender and back to see all of the places where a low-frequency multicast application can cause problems. A router will assume that there are no group members on a network segment if it doesn't receive any IGMP messages for a defined period of time. However, the devices on the segment are responsible for sending periodic IGMP reports to ensure that this doesn't happen unless there really aren't any more members for a given group on the segment. So unless the timers are not configured properly on the end devices, the low-frequency multicast application should not represent a problem here. In particular, it should not be necessary to configure a static IGMP statement on the router interface. If it turns out that IGMP timeouts are a problem for an application, refer to Recipe 23.9 for information about setting up static IGMP statements on a router.

At this point, it is useful to think about whether you should use a dense mode or sparse mode multicast routing protocol. Recall that the difference between these modes is that a dense mode protocol forwards all multicast packets to all neighboring routers until they announce that they don't want to be members. In sparse mode, on the other hand, routers must explicitly join a group before they can receive it.

If you were to use PIM-DM in this network, the multicast packets themselves would help to establish the multicast tree structure. If a router didn't receive any packets for a group within a standard timeout period of three minutes, it would tear down this tree structure. So this is the first important place where the low-frequency application can cause problems. The network either has to be constructed so that it can build and tear down this forwarding tree for every individual multicast packet, or it has to keep the tree up.

All of the end devices in the low-frequency application pre-join the group, so before the first packet is sent, it is already clear where it should be delivered. If you used dense mode, the routers that did not have members would respond to the first packet with a round of Prune messages asking to be removed from the tree. Since we don't expect another packet anytime soon, these Prune messages are really just a waste of network resources. The entire tree structure will have been removed before the next packet arrives. So, all things considered, it is better to use PIM-SM than PIM-DM for this type of application. Note that the example actually uses "sparse-dense" mode so that it can function in dense mode if an RP is not available. This is discussed in Recipe 23.3.

As discussed in the introduction to this chapter, every PIM-SM router sends a fresh Join up the tree toward the RP once per minute. This ensures that the tree to the RP stays up even if there is no traffic. When the source device is finally ready to send a packet, it sends this packet to its first-hop router. The first-hop router encapsulates the multicast packet in a unicast Registration packet that it sends to the RP. The RP pulls the multicast packet back out of the encapsulation and forwards it down the multicast tree to all of the group members. It then extends the tree for this group over to the source so that it can use multicast all the way on subsequent packets.

The only impact of the low-frequency nature of the application here is that the extension of the tree from the RP over to the source will eventually be torn down because of lack of data. But we do need to be careful that the last-hop routers don't try to build a new multicast-forwarding tree rooted at the source. To prevent this, the recipe example shows how to set the SPT threshold value so that only high-traffic multicast streams will rebuild the tree like this.

This threshold is set by the command ip pim spt-threshold:

Router1(config)#ip pim spt-threshold 10 group-list 15

In the example, we set the threshold to 10 Kbps for the groups defined by access-list 15. All other groups will continue to use the default threshold of zero. If you instead wanted to have this command affect all multicast groups, you could simply leave out the group-list:

Router1(config)#ip pim spt-threshold 10

You can also use this command to tell the routers to always use the RP, and never switch over to the source-based SPT by using the keyword infinity for the threshold value:

Router1(config)#ip pim spt-threshold infinity

Or, you could use this option with a group-list statement to prevent the router from building a source-based STP just for a specific set of groups:

Router1(config)#ip pim spt-threshold infinity group-list 15

 

See Also

Recipe 23.2; Recipe 23.3; Recipe 23.9