Filtering Auto-RP Messages

Auto-RP uses special dense-mode groups to disseminate RP information, and the information is flooded across the multicast domain. The only way to control the scope of the information is by setting the TTL to the value that roughly represents the diameter of the multicast domain. However, the problem is that this does not enforce strict administrative limits on the information scope, and per-link flooding is not controlled.

R1(config)# ip multicast-routing distributed
R1(config)# ip pim autorp listener
R1(config)# ip pim send-rp-announce Loopback0 scope 10

The other way to filter Auto-RP announcements is to use the ip multicast boundary . he multicast boundary feature allows for setting administrative borders for multicast traffic. This feature applies filtering to both the control plane traffic (IGMP, PIM, AutoRP) and the data plane (installing multicast route states out of the configured interface). It is much more flexible than using Auto-RP TTL scoping and allows the application of finer and more granular access control. Using this feature, you may contain multicast traffic within the boundaries of your administrative domain, without relying on TTL-based filtering.

When you apply the command ip multicast boundary <access-list> [filter-autorp] to an interface, the following filtering rules apply:

  • If the access-list is a standard ACL, any ingress IGMP or PIM messages are inspected to see if the group being joined or tree being built has a match in the access-list. This might be an (S,G) or (*,G) join. Additionally, the interface is used as an outgoing interface to forward a group “G” only if the group matches the access-list.
  • If the access-list is an extended ACL, it specifies both multicast sources and groups, using the format permit ip <src-ip> <src-wildcard> <group-address> <group-mask> . Any incoming PIM/IGMP messages are inspected, and if both the source and group are matched, they are permitted. At the same time, the interface could be used as outgoing for multicast traffic sourced off the IP addresses matching the extended access-list with the group matching the same access-list entry. If you want to match only (*,G) shared tree signaling, specify the source IP address of 0.0.0.0; this will affect PIM Join/Prune messages.

PIM Register messages are not affected by the multicast boundary configuration by default and must be filtered using the respective add-on feature, filter-autorp.

Starting with version 12.3(17)T, you may use in or out options with the multicast boundary command (this does not work with the filter-autorp option, though). When applied as an ingress filter, the command affects control plane traffic, IGMP/PIM Joins, and Auto-RP messages. When configured as an egress filter, it will control the interface being added to the OIL for multicast groups, allowing only the groups permitted by the access-list.

R1(config)# ip access-list standard PERMITTED
R1(config-acl)# deny 232.0.0.0 7.255.255.255
R1(config-acl)# permit any
R1(config-acl)# exit
R1(config)# interface GigabitEthernet0/1
R1(config-if)# ip multicast boundary PERMITTED filter-autorp
R1(config-if)# exit

Filtering BSR

Filtering BSR messages is much easier than filtering Auto-RP messages since BSR messages are carried in PIM messages. When you apply the command ip pim bsr-border on a link, BSR messages are no longer flooded or received on that link. This means that any RP or BSR advertisements are filtered, effectively creating two isolated domains of RP information exchange.

R1(config)# ip multicast-routing distributed
R1(config)# interface GigabitEthernet0/1
R1(config-if)# ip pim sparse-mode
R1(config-if)# ip pim bsr-border
R1(config-if)# exit