Guest

IP Multicast

Using Apps with Low TTL in Dense-Mode, Multicast Environments

Table Of Contents

Application Note


Application Note


Using Applications with a Low TTL in a Dense-Mode, Multicast Environment

An application that uses expanding Time To Live (TTL) searches can cause problems within a dense-mode multicast network. Network administrators are currently finding examples of this problem in a well-known disk imaging utility.

When using this disk imaging utility, if a router receives an IP packet where TTL = 1, and the packet is not destined for that router, the router discards the packet before it can be forwarded to the Cisco IOS® software.

The client sends out multicast requests seeking the server. First, it sends sequential requests, beginning with TTL = 1, then TTL = 2, and so on, until it receives a response from the server. The server then multicasts to the client using the same TTL value.

Using the exact TTL value, as described above, can cause problems in certain circumstances. When the problem occurs, there will be no prunes from downstream routers while packets continue to flood segments that do not require that data.

Figure 1 gives an example of the topology you need to look for:

Figure 1 Sample Topology

In Figure 1, the client succeeds in finding the server with a TTL value of 3. In this case, the server will multicast toward the client with a TTL of exactly 3. The TTL will decrement by 1 as it traverses router X. The packet is then replicated and flooded with a TTL of 2. In this case, there are now two copies of the packet, each with a TTL of 2 traveling on the network.

A copy of the packet arrives at both routerZ and routerY. RouterY decrements the TTL by 1 and forwards the packet to the client. RouterZ also decrements by 1 and forwards the packet toward the client. The packet arrives at routerY by way of routerZ with a TTL of 1. RouterY receives the packet, but discards it.

If the TTL is greater than 1, routerY can process the packet, see that the RPF check was incorrect, and then send an S,G Prune. Because of the TTL, the packet has not been processed; therefore, no S,G Prune occurs. Without the S,G Prune, routerZ continues to flood.

Note that routerY will also replicate the packet and forward it to both routerZ and the client. RouterZ is unable to process the packet or generate a prune because of the TTL value of 1.

The workaround for this situation is to force the application to use a higher TTL value. This is accomplished with the following command:

>ip multicast ttl-threshold ttl-value

This command stops the router from forwarding multicast packets unless the TTL is above a specific value. In this case, that means that the initial search, using expanding TTL values, will require a TTL value greater than the number of router hops needed to locate the host, thus ensuring that pruning can take place.

For more information about this command, read the online documentation posted at the following URL:

/en/US/docs/ios/11_2/np1/command/reference/5riprout.html#xtocid1200377