Auto Rendezvous Point Configuration

[davidhuynh5]

I have a router with the ip adddress of 10.4.1.80 that I would like it to be the RP. Can someone give me a sample Auto RP configuration and a easy to understand explaination? I've already read a couple of articles, but it's still unclear. For example, what is the send-rp-announce and send rp-discovery used for? Thanks in advace.

[Peter Paluch · Accepted solution]

Hello David,

In the AutoRP architecture, there are two types of active entities: the RP candidates and mapping agents. An RP candidate is a router that is willing to take on the role of an RP for a particular multicast group. Its willingness does not guarantee that it will become the RP if there are multiple candidate RPs for the same group but at least it is clear that this router can perform as an RP. Having multiple RP candidates for a group guarantees that if the current RP fails, other candidate can replace it. An RP candidate is configured using the ip pim send-rp-announce command.

The mapping agent is an arbiter that decides which one from the multiple RP candidates for a group will be the definitive RP. Again, there can be multiple mapping agents present in the network to make sure that if the discovery of definitive RPs is not dependent on a single mapping agent. A mapping agent is configured using the ip pim send-rp-discovery command.

A router can be an RP candidate, a mapping agent, it can even be both, or it can be none (just a multicast-capable router without any special function in the AutoRP mechanism). In a smaller network running AutoRP, usually a single router can be both an RP candidate and a mapping agent and all other routers simply learn about the definitive RP automatically, without any special configuration. In larger networks, multiple (possibly physically distinct) routers would be configured as RP candidates or mapping agents, respectively.

The simplest configuration would be simply to make a single router to be both RP candidate and mapping agent as follows:

ip multicast-routing
ip pim send-rp-announce Loopback0 scope 255 ! RP Candidate
ip pim send-rp-discovery Loopback0 scope 255 ! Mapping Agent

assuming that the IP address 10.4.1.80 is configured on the Loopback0 interface. If it is located on a different interface, simply substitute the Loopback0 in the example above with the precise interface name and number. That interface must have the multicast routing enabled using the ip pim sparse-dense-mode. All other routers in your network will not be configured with any special ip pim commands regarding the AutoRP.

In order for the AutoRP to work, all interfaces on all routers in your network must be configured using the command ip pim sparse-dense-mode which allows PIM-DM operation for all multicast groups for which no RP is known. This solves a chicken-and-egg problem in AutoRP: the AutoRP itself uses two multicast IP addresses, 224.0.1.39 and 224.0.1.40 to disseminate information about RP candidates and resulting RP-to-group mappings. However, if no RP is known for a group, no multicast delivery can be performed, so the AutoRP itself cannot work in sparse mode. This is solved by allowing the routers to fall back to PIM-DM for all groups for which the RP is currently unknown, including the "bootstrapping" AutoRP groups.

Note please that the AutoRP is Cisco-proprietary mechanism that has been superseded by the so-called Bootstrap Router (BSR) mechanism in current PIM-SM RFCs that is open and supported by most vendors. In new deployments, I recommend running the BSR.

Best regards,

Peter

[davidhuynh5]

Hi Peter,

I've read several online articles, but none was as concise nor clear as your RP explanation. I must have a teaching backgroud. One last question, do you have a reccommend sample BSR configuration? Thanks again for your help.

[Peter Paluch · Accepted solution]

Hi David,

Thank you very much for your compliments. Actually, I am teaching networking topics at a university.

Regarding the BSR mechanism, it is quite similar to the AutoRP: there are RP candidates and bootstrap router candidates. RP candidates are willing to act as RPs for selected groups and they are configured using the ip pim rp-candidate command. A BSR router collects and distributes a list of RP candidates to all multicast-capable routers in a network. A BSR candidate is configured using the ip pim bsr-candidate command.

The difference is that in the BSR mechanism, the information about existence of BSR candidates is transmitted in PIM messages in a hop-by-hop fashion. A single BSR is then elected from among all BSR candidates. Being advertised in its PIM messages, all multicast routers then learn about the existence of the BSR, including RP candidates. The RP candidates then unicast information about their existence to the BSR, and the BSR subsequently advertises the entire list of RP candidates in its PIM messages, again flooded in a hop-by-hop fashion. The interesting thing here is that no dense mode for spreading the information about RPs is necessary (at the cost of slightly increased complexity of this mechanism), and also, each multicast router knows about all RP candidates, and makes its own decision as to what RP candidate is considered to be final RP for a multicast group.

The configuration is quite similar to the AutoRP:

ip multicast-routing
ip pim bsr-candidate Loopback0 ! BSR candidate
ip pim rp-candidate Loopback0 ! RP candidate

All interfaces on all routers should now be configured using the ip pim sparse-mode (you could also use the ip pim sparse-dense-mode but the fallback to the dense mode is not necessary in this case).

Best regards,

Peter

[davidhuynh5]

Paul, thanks again. You're the best.

[alexandro.angel@softtek.com]

As always @Peter Paluch  thank you so much for your awesome helpful feedback you provide, your students are lucky guys by having you as a networking teacher (not sure if you are still doing that). Side question, do you provide any sort of webinar? or do you sell any sort of podcasts or training about networking?

Kind Regards,