Controlling Multicast Scope with TTL
Problem
You want to ensure that your multicast traffic remains confined to a small part of the network.
Solution
You can define a TTL threshold value for each interface on a router. The ttl-threshold command instructs the router to drop any multicast packets that have a TTL value less than or equal to the specified value. The router will receive packets on this interface normally. This command only affects transmission of multicast packets:
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 multicast ttl-threshold 16
Router1(config-if)#end
Router1#
This technique works for all multicast routing protocols.
Discussion
The first popular method for controlling the scope of multicast transmissions made use of the standard IP TTL header variable. This is an 8-bit variable that each router decrements by one as it forwards the packet. If a router receives a packet with a TTL value of 1, it won't forward it any further. The main use of TTL in unicast IP networking is to help to kill loops. In a loop situation, a packet may go around a few times, but the TTL value keeps decrementing and will eventually reach 1, when the network will drop it.
In multicast networking, TTL has a more subtle use. Most multicast applications include the ability to define an initial TTL value other than the default 255. This leads to a common method for keeping multicast traffic within a certain well-defined part of the network. The customary technique is to configure the multicast applications with an initial TTL value that defines the scope, as shown in Table 23-2.
| Scope | Initial TTL value |
|---|---|
| Local segment | 1 |
| Site, department, or division | 16 |
| Enterprise | 64 |
| World | 128 |
You would configure these values on your multicast server to define how far you want the application to reach. Then you must enforce these limits with your routers. For multicast traffic that is purely local to the server's network segment there is no need to do anything special on the routers. When a router receives a packet with a TTL value of 1, it decrements this value to get 0, and drops the packet without forwarding it any further.
The example above shows how you would configure the routers along the boundary between two departments. If a department has a multicast application that is intended to serve only this department, they would configure the routers that connect to other departments or to the network backbone to drop any multicast packets with a TTL value less than or equal to 16, as shown in the example:
Router1(config-if)#ip multicast ttl-threshold 16
It doesn't matter where in the internal departmental network this server is located, the boundary routers will always prevent these packets from reaching the rest of the network. This way another department in the same enterprise can have an application using the same multicast group address without conflict.
Similarly, if a multicast application serves an entire enterprise network, you would configure the server to use an initial TTL value of 64. Then you would configure the border around the edges of your enterprise network to drop any multicast packets with a TTL value greater than or equal to 64.
The reason for suggesting an initial TTL value of 128 for worldwide applications is simply to allow for future implementation of new multicast domains.
The TTL values shown in Table 23-2 are just suggestions based on common usage. There is no mandated standard, nor is there an IETF Best Current Practices document on this subject.
There are a couple of important problems with using TTL thresholds to control multicast scope. The most critical is that you must rely on the server configuration. If a new server is turned on to offer multicast services within a network, you have to cross your fingers and hope that the systems administrators have configured the initial TTL values properly to prevent leakage. The worst case is when two or more departments use applications the same multicast group numbers. If the traffic from one manages to leak to the other, it can cause serious confusion to the application. It is also relatively easy to have conflicts between global and local multicast applications using the same group addresses.
TTL scoping can also cause serious problems for multicast routing protocols at the network boundaries. The routers at these boundaries will have trouble pruning themselves from unwanted SPT trees in dense-mode routing because they effectively act as a sink for all multicast traffic. This can cause CPU problems on the border routers as they handle extra multicast traffic, only to drop it.
For these reasons, it is generally better to use Administratively Scoped Addressing for controlling multicast scope, as shown in Recipe 23.15.
Note that when a router needs to drop a unicast packet because of a TTL limitation, it sends an ICMP TTL Exceeded error message back to the source. However, according to RFC 1812, such messages are not generated for multicast packets. This is good because it would otherwise cause a continuous barrage of ICMP errors from the perimeter of the network that could potentially cause network congestion and CPU problems on the multicast source device.