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 terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#ip multicast-routing
Router1(config)#access-list 15 deny 239.255.0.0 0.0.255.255
Router1(config)#access-list 15 permit any
Router1(config)#interface FastEthernet0/0
Router1(config-if)#ip multicast boundary 15
Router1(config-if)#end
Router1#

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 ...

Get Cisco IOS Cookbook, 2nd Edition now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.