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 SPT. And it isn't sufficient to simply discover the problem and prune the tree at the previous node because of the possibility that the packets will still reach the destination by another path. The result is that the routers at the TTL boundary become "sinks" that receive all multicast traffic but cannot process it. If there is a lot of multicast traffic, this can cause performance problems.
Another problem is caused by misconfigured multicast servers causing multicast applications to leak out of their domains. This problem can occur either accidentally or deliberately, and in either case the result is that multicast applications in neighboring network regions will not work properly. And a similar problem occurs when the routers at the boundary are not configured properly, allowing even well-behaved multicast applications to leak out of their domains. Clearly a better solution is required.
The alternative proposed in RFC 2365 is to set aside particular ranges of multicast group addresses for unregistered use, similar to the RFC 1918 system of unregistered IP addresses. The RFC takes the range from 239.0.0.0 to 239.255.255.255 for this purpose. It defines how to use particular ranges of these addresses for multicast applications with different scopes. These ranges are summarized in Table 23-3.
We note in passing that the IANA has registered several other multicast addresses for specific applications. The range from 224.0.0.0 through 224.0.0.255 is reserved for routing protocols and other network maintenance applications that are confined to the local network segment. The multicast addresses between 224.0.1.0 and 224.0.1.255 have been designated for Internetwork control applications such as Cisco's RP discovery protocol. And the range from 224.0.2.0 through 224.0.255.255 is set aside for miscellaneous well-known registered application purposes. Refer to the IANA web site, http://www.iana.org/assignments/multicast-addresses, for specific well-known addresses.
| Scope | Address range | Access list |
|---|---|---|
| Site local | 239.255.0.0/16 | access-list 15 deny 239.255.0.0 0.0.255.255 |
| Expanding site local | 239.254.0.0/16, 239.253.0.0/16, etc. | access-list 15 deny 239.254.0.0 0.0.255.255, access-list 15 deny 239.253.0.0 0.0.255.255, etc. |
| Organization local | 239.192.0.0/14 | access-list 15 deny 239.192.0.0 0.3.255.255 |
| Expanding organization local | 239.128.0.0/10, 239.64.0.0/10, 239.0.0.0/10 | access-list 15 deny 239.128.0.0 0.63.255.255,access-list 15 deny 239.64.0.0 0.63.255.255,access-list 15 deny 239.0.0.0 0.63.255.255 |
The configuration example shows a Site Local boundary. The ip multicast boundary command affects the packets sent and received on this interface. So you would configure this command on all interfaces that connect to other sites. For interfaces that connect to other organizations, the only difference is in the access-list, as shown in Table 23-3.
If you needed more multicast address space, you would add 239.254.0.0 first, then 239.253.0.0, and so forth.
In many organizations you will see both TTL (see Recipe 23.14) and Administratively Scoped Addressing used simultaneously to control the reach of multicast applications. The two methods work well together, which makes it relatively easy to accomplish a transition from one method to the other.
One final point is worth noting here. The ip multicast boundary command is not the same as simply putting an access list on the interface to block the exchange of packets. The actual multicast packets are not the only thing that you want to prevent from crossing this boundary. You also want to prevent PIM from joining any of these multicast distribution trees across the boundary. That is what this command does for you.