Controlling Multicast Scope with Administratively Scoped Addressing
Problem
You want to use RFC 2365 administratively scoped multicast addressing to control how multicast traffic is distributed through your network.
Solution
To configure regions of multicast scope using addressing rather than TTL, using the ip multicast boundary interface command:
Router1#configure terminalEnter configuration commands, one per line. End with CNTL/Z. Router1(config)#ip multicast-routingRouter1(config)#access-list15deny 239.255.0.0 0.0.255.255Router1(config)#access-list15permit anyRouter1(config)#interface FastEthernet0/0Router1(config-if)#ip multicast boundaryRouter1(config-if)#15endRouter1#
Note that the access-list uses a deny statement to specify which groups are to be dropped. Because access-lists have an implicit deny on all addresses not explicitly matched, you must include a permit ip any at the end of the access-list to allow all other multicast groups to pass normally.
Discussion
RFC 2365 defined a new way of handling the problem of controlling the scope of multicast applications. The IETF realized that you can’t count on applications to have the right initial TTL value. The other important reason that they give for avoiding TTL scoping has to do with pruning in dense mode multicast protocols such as PIM-DM or DVMRP.
The problem is that the router at the boundary is dropping all multicast packets, but it can’t tell its upstream neighbors that it no longer wants to be a member of this ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access