Auto-RP

Auto-RP was first supported in Cisco IOS Software Release 11.1(6) and was developed by Cisco to provide automatic discovery of the RP before the bootstrap protocol was specified for PIM-SM. It supports IPv4 RPs and although still occasionally found in multicast networks it is mostly obsolete.

Candidate RPs (C-RPs) are designated in the PIM-SM domain and are identified by designated IP addresses, usually assigned to a loopback interface.

R1(config)# ip pim send rp-announce <Interface> scope <TTL> [group-list <STD-ACL>] [interval <seconds>]
R1(config)# exit

If using the group-list ACL, the deny statement has a special meaning. It means all groups matching the range should be treated as dense mode groups.

One or more RP Mapping Agents are also designated, unlike in bootstrap where the mapping agents are elected. These mapping agents map groups to RPs.

R1(config)# ip pim send-rp-discovery <Interface> scope <TTL> [interval <seconds>]
R1(config)# exit

Auto-RP uses two reserverd multicast addresses, 224.0.1.39 and 224.0.1.40.

When a Cisco PIM-SM router is configured to be a candidate RP for one or more groups, it advertises itself and the groups for which it is a C-RP in RP-Announce messages. These messages are multicast every 60 seconds to the reserved Cisco-RP-Announce address 224.0.1.39 (UDP port 496). The configured mapping agents for the domain listen for this address. From all the received RP-Announce messages, the mapping agent selects an RP for a group based on the numerically highest IP address of all the group’s C-RPs.

The RP mapping agent then advertises the complete list of group-to-RP mappings in RP-Discovery messages. These messages are sent every 60 seconds to the reserved Cisco-RP-Discovery address 224.0.1.40. All Cisco PIM-SM routers listen for this address and thus learn the correct RP to use for each known group. If there are multiple MAs in the network, they will hear each other, and then all of them, except the one with the highest IP address, will cease sending RP-Discovery Messages.

The Mapping Agents follow a few rules when building their discovery messages:

  • If there are two announcements with the same group range but different RPs, the MA will select the announcement with the highest RP IP address.
  • If there are two announcements where one group is a subset of another but the RPs are different, both will be sent.
  • All other announcements are grouped together without any conflict resolution.

All regular routers join the multicast group 224.0.1.40 and listen to the discovery messages. Based on their content, they populate their Auto-RP cache and learn about Group-to-RP mappings. The cache contains both “negative” and “positive” entries. When looking for an RP, Auto-RP code will first scan through negative entries. If a match is found, the group is considered to be dense. Note that RP information for the negative entries will be effectively ignored. If the group is not found in the “negative” list, the code looks it up in the positive list. Because every group in the list is bound to a particular RP, there could be conflicts when multiple RPs try to service overlapping group ranges. The receiving router uses the longest- match rule to resolve all conflicts: if there are multiple matches, only the one with the longest prefix length is selected.

Note that “negative” statements could be defined at any cRP and affect all routers in the multicast region. For example, if a single group list contained the deny any statement, all groups would be treated as dense, even if there are “positive” entries.

The last thing to discuss about Auto-RP is how the multicast groups 224.0.1.39 and 224.0.1.40 are propagated across the network. Because there is no explicit RP information for these groups, they must use dense mode forwarding. This requires the use of pim sparse-dense-mode on all interfaces within the multicast domain. As discussed before, this is not the safest thing to do in a large-scale network. You may want to use the no ip dm-fallback global command in such situations or use the Auto-RP Listener feature, discussed later.

Auto-RP: Sparse Dense Mode

With Auto-RP, the multicast groups 224.0.1.39 and 224.0.1.40 are central to announcing multicast group and RP information across the network. But because there is no explicit RP information for these groups, they must use dense mode forwarding. This requires the use of pim sparse-dense-mode on all interfaces within the multicast domain. As discussed before, this is not the safest thing to do in a large-scale network. You may want to use the no ip dm-fallback global command in such situations or use the Auto-RP Listener feature, discussed in the next topic..

Auto-RP Listener

Auto-RP listener is a solution designed to allow using Auto-RP without risking any groups falling back to dense mode forwarding. This feature works in tandem with PIM sparse mode enabled on all interfaces (not PIM SM/DM). However, two Auto-RP multicast groups 224.0.1.39 and 224.0.1.40 are flooded in dense mode. No other groups are allowed to use dense mode and thus dangerous flooding fallback is eliminated. Its configuration is straighforward.

R1(config)# ip pim autorp listener
R1(config)# exit

Auto-RP Multiple Candidate RPs

Usually multiple candidate RPs are set up on a network with the intention of either load balancing or redundancy, or both.

For load balancing, configure the group-mapping access-lists so that every RP services a range of groups.

For redundancy, make both RPs service the same group ranges.The one with the highest IP will be selected by the Mapping Agent, but the other is still available for failover.

Auto RP: Filtering Candidate RPs

The Auto-RP mapping agent allows for the filtering of incoming RP announcements sent by RP candidates. This type of filtering applies only to Auto-RP announcements received by listening to the 224.0.1.39 multicast IP address and thus is only effective on Mapping Agents.

You configure a filtering statement using the following syntax: ip pim rp-announce-filter [group-list <access-list> | rp-list <access-list>] . All access-lists are either numbered or named standard ACLs. RP announcements are inspected, and if a match is found for the group and the RP IP address, the action is taken based on the “permit” or “deny” statement. If you omit the rp-list keyword, any announcements containing groups matching the group-list are matched. If you omit the group-list parameter, all updates from the RPs in rp-list are matched.

R1(config)# ip access-list standard R10_GROUPS
R1(config-acl)# deny 224.110.11.100
R1(config-acl)#exit
R1(config)# ip access-list standard RP1
R1(config-acl)# permit 150.1.1.6
R1(config-acl)#exit
R1(config)# ip pim send rp-discovery Loopback0 scope 10
R1(config)# ip pim rp-announce-filter rp-list RP1 group-list R10_GROUPS
R1(config)# exit

Auto RP: RP & MA Placement Problems

PIM by default treats NBMA interfaces as if they were broadcast capable. Taken further, it assumes all neighbors on a WAN cloud can hear multicast packets sent by any neighbor. However in Hub and SPoke designs this is not the case - when a spoke send multicast traffic over the NBMA segment, only the hub can hear it. Because of split-horizon, the hub will not forward the multicast stream back out its interface to the other spokes. This problem could be solved using PIM NBMA mode, but this is only available with PIM Sparse Mode.

Since Auto-RP uses dense mode for RP information dissemination, the PIM NBMA option will not help with Auto-RP designs. The workaround is proper design - the Mapping Agent should always be palced at the hubon NBMA designs. RPs can still be palced at the spokes without a problem, as long as the MA is at the hub.

If placing the MA correctly is not possible, another solution is creating tunnels between the hubs and the spokes.