Multicast TTL threshold = 0 Packet is forwarded

Multicast TTL threshold = 30 Packet is dropped

TTL scoping has been used on the MB one for some time The MB one is constructed of regional multicast networks connected through the Internet by IP-over-IP tunnels Table 5-6 shows typical TTL thresholds used to restrict multicast traffic in the MBone If you want some traffic to stay within a single site—high-bandwidth reai-time video, for example— you configure the source application to send packets with a TTL no higher than 15

Table 5-6 MBone TTL Thresholds

TTL Value



Restricted to the same host


Restricted to the same subnet


Restricted to the same site


Restricted to the same region




Worldwide limited bandwidth



TTL scoping has several shortcomings First, it is inflexible An interface's TTL threshold applies to all multicast packets If you want some multicast sessions to pass the threshold and others to be restricted by it, the separate applications sourcing the sessions must be manipulated This leads to the second problem Users must be trusted to set the TTLs in their multicast applications correctly If a session is sourced with a too-high TTL, it will pass outside the boundary you have set

Another problem with TTL scoping is that it is difficult to implement in all but the simplest topologies As your multicast internetwork grows in both scale and complexity, predicting the correct thresholds to contain and pass the correct sessions becomes a challenge

Finally, TTL scoping can cause inefficiencies with broadcast-and-prune protocols Figure 5-23 demonstrates the problem The internetwork is a multicast site, and the boundary router has a TTL threshold of 8 configured on the interfaces leading to other parts of the internetwork The multicast source is generating a session in which the TTL of all packets is set to 8, in keeping with local policy, to limit its traffic to the multicast site There are no group members anywhere along the left branch of the tree, so those routers should prune themselves all the way back to the source's directly connected router In fact, you can see that one router has sent a prune message upstream to its neighbor

The problem is with the boundary router and its configured TTL filter When the multicast packets reach this router, the packets are discarded at both downstream interfaces, because the packets' TTL values are less than the TTL threshold This is expected behavior However, the packet discards also mean that no IGMP queries for group members take place Without the queries, the router does not send a prune message back upstream As a result, multicast traffic continues to be forwarded unnecessarily through all the routers leading to the boundary router

Figure 5-23 The TTL Multicast Filter at the Boundary Router Is Preventing It from Sending a Prune Message Upstream

Figure 5-23 The TTL Multicast Filter at the Boundary Router Is Preventing It from Sending a Prune Message Upstream

Was this article helpful?

0 0
100 SEO Tips

100 SEO Tips

100 SEO Tips EVERY SEO Enthusiast Should Know. This Report 100 SEO Tips will help you to Utilize These Tips to Dominate The Search Engine Today.

Get My Free Ebook

Post a comment