Problem solve Get help with specific problems with your technologies, process and projects.

PIM RP configuration methods

How to configure Auto-RP, a method of setting the RP, or rendezvous point, on a PIM-SM network.

This article is the last of a short series of multicasting tips. In the previous article I outlined the functions of the Protocol Independent Multicast (PIM) protocol and showed how to configure PIM in its simplest form. This week I want to focus on some other options for configuring a rendezvous point (RP) in your multicast network.

RP Function
Recall from last week that the RP is essentially responsible for the registration of multicast sources and receivers throughout the network and also helps to move the traffic down the trees to the multicast receivers. The actual registration process is a function of both a source and a receiver within the network. Well, actually, it is the next hop router that initiates the PIM register for the hosts. Remember from the earlier articles that IGMP is used by hosts and their next hop routers.

RP Options
Last week I showed you how to configure the RP in a PIM network using the "ip pim rp-address" command in Cisco IOS. What this command essentially does is manually point each multicast router to an RP, which for all intensive purposes actually configures the RP. This concept and command is ok to use throughout small networks where RP placement isn't that important and change doesn't happen often. There are other options you can use to set up the RP on a PIM-SM network: Auto-RP, Bootstrap Router (BSR) and Anycast RP. In this article I will only focus on Auto-RP.

Unlike with static RPs, Auto-RP allows multicast routers in large PIM-SM to be automatically mapped to an RP using mapping agents. The advantage of this is that changes to an RP address need only be made on the RP itself and not on the leaf routers. With Auto-RP, configured mapping agents listen to announcements made by the RPs; the RP with the highest IP address in the list becomes the RP for that PIM-SM domain. The automatic discovery mechanism used by the leaf routers actually uses a multicast address of and to announce and discover the RPs. Below is a simple configuration for Auto-RP:

R1(config)#ip multicast-routing
R1(config)#ip pim send-rp-announce fa0/0 scope 255
R1(config)#interface fa0/0
R1(config-if)#ip pim sparse-dense-mode

R2(config)#ip multicast-routing
R2(config)#ip pim send-rp-discovery scope 10
R2(config)#interface fa0/0
R2(config-if)#ip pim sparse-dense-mode

The above configuration allows R1 to become the RP on a PIM-SM network. Notice that unlike a static RP configuration, I use the command "ip pim sparse-dense-mode" on each interface. This is an absolute requirement for Auto-RP to work properly. Note the scope parameter within the configuration as well. Scope refers to the "distance" these announcements and discoveries can travel, with the actual number signifying the hops allowed. It's important to make this value close to the exact distance you need.

Filtering on the RP
Using Auto-RP, there are many possible filtering techniques which can be used to allow an RP to be the RP for a certain multicast group. The configuration below can be used on the RP:

R1(config)#ip multicast-routing
R1(config)#ip pim send-rp-announce fa0/0 scope 10 group-list 50
R1(config)#interface fa0/0
R1(config-if)#ip pim sparse-dense-mode
R1(config)#access-list 50 permit
R1(config)#access-list 50 permit

This configuration allows R1 to be the RP for groups and This configuration can be helpful if you know exactly what multicast group you have on your network.

This concludes the multicast series for now, hopefully you have a firm grasp on the basics of IP multicast and PIM. Maybe next time I will expand on the advanced features and design aspects from each vendor. Until then, good luck with your multicast network.

Doug Downer (CCIE #9848) is a Sr. Consultant with Callisma, INC, a wholly owned subsidiary of SBC Communications. Doug has over 7 years in the industry and currently provides high level business and technology consulting for various federal clients in the Washington D.C. area.

This was last published in April 2005

Dig Deeper on Telecommunication networking