Using Auto-RP to Dynamically Map RPs

Problem

Instead of manually configuring the RP, you want the routers to decide among themselves which one should be the RP.

Solution

With auto-RP, the PIM routers determine which one should be the RP, thereby automating the distribution of the group-to-RP mappings. There are three steps for configuring auto-RP. First, configure PIM in sparse-dense mode on all routers in the PIM domain:

[edit protocols pim] aviva@RouterA# set interface all mode sparse-dense

Then, configure the two multicast dense-mode groups 224.0.1.39/32 and 224.0.1.40/32 on all routers:

[edit protocols pim] aviva@RouterA# set dense-groups 224.0.1.39/32 aviva@RouterA# set dense-groups 224.0.1.40/32

Finally, configure auto-RP on each router. One router in the PIM domain must announce auto-RP messages and another must map them. You can also configure the local router to perform both functions:

[edit protocols pim] aviva@RouterA# set rp local address 192.168.13.1 aviva@RouterA# set rp auto-rp mapping

On the remaining routers in the PIM domain, configure sparse-dense mode and configure them to discover the RP:

[edit protocols pim] aviva@RouterG# set interface all mode sparse-dense aviva@RouterG# set rp auto-rp discovery

Discussion

Auto-RP dynamically maps groups to RPs, and PIM routers in the network automatically learn the addresses of the RPs. The auto-RP mechanism is not defined in an IETF RFC but is a proprietary mechanism developed by Cisco Systems for IOS routers and is supported by the JUNOS software so that JUNOS and IOS routers can interoperate within a PIM-SM domain.

Auto-RP provides a failover mechanism in case an RP router fails. You configure several routers as candidates to become the RP, and the routers elect the RP. If the elected RP becomes unavailable, the remaining candidate routers simply elect another RP. You do not need to intervene to modify any router configurations.

One of the first things to notice about this configuration is that auto-RP requires PIM be in sparse-dense mode rather than sparse mode. All routers in the PIM domain must be in this mode. Multicast groups can be in either sparse or dense mode, and PIM handles the groups appropriately. Auto-RP uses dense mode to flood messages throughout the network announcing RP candidates and to discover which routers have been elected as RPs.

If you commit the configuration after configuring just sparse-dense mode, use the show pim interface command to check the PIM mode:

aviva@RouterA> show pim interfaces Instance: PIM.master Name Stat Mode IP V State Count DR address fe-0/0/1.0 Up SparseDense 4 2 DR 1 10.0.15.2 lo0.0 Up SparseDense 4 2 DR 0 192.168.13.1 se-0/0/2.0 Up SparseDense 4 2 P2P 1 se-0/0/3.0 Up SparseDense 4 2 P2P 0

This output from RouterA shows that the three physical interfaces are all in sparse-dense mode.

In the second step in the configuration, configure the two multicast groups 224.0.1.39 and 224.0.1.40 as PIM dense-mode groups. The PIM routers use these two addresses, reserved by IANA for auto-RP, to elect the RP. All PIM routers that are willing to be an RP send RP Announcement messages to group 224.0.1.39. The PIM routers that are acting as RP- mapping agents join this group and select a single RP for each group address range. The group range and RP together are called an RP mapping. The RP-mapping agents then advertise the RP mappings to group 224.0.1.40. All PIM routers join this group to discover the RP for each group.

The final configuration step defines the auto-RP behavior for each PIM router. For auto-RP to work, at least one router in the PIM domain must announce its availability to serve as RP, and at least one router must map which multicast groups the RP wants to receive traffic from. This recipe configures a single router to perform both functions. The set rp local address 192.168.13.1 command establishes the local router as an RP candidate, and the set rp auto-rp mapping command configures the router to map RPs to multicast groups. All the remaining routers in this recipe are configured with the set rp auto-rp discovery command to discover the RP.

Check to see which router is the RP. Start on RouterA, which is the only router that has announced its willingness to be RP:

aviva@RouterA> show pim rps inet Instance: PIM.master Address family INET RP address Type Holdtime Timeout Active groups Group prefixes 192.168.13.1 auto-rp 150 150 2 224.0.0.0/4 192.168.13.1 static 0 None 2 224.0.0.0/4

The output shows that this router is the RP both as a result of static configuration and of being elected by auto-RP. Check which RPs one of the other routers has learned about:

aviva@RouterG> show pim rps inet Instance: PIM.master Address family INET RP address Type Holdtime Timeout Active groups Group prefixes 192.168.13.1 auto-rp 150 150 2 224.0.0.0/4

You see that RouterG has learned from auto-RP that RouterA (192.168.13.1)is the RP.

The net effect of this configuration in this recipe is that only one router in the domain, RouterA, is eligible to be the RP, so this router is still a single point of failure. To provide a backup RP candidate, configure another router to announce that it can be the RP:

[edit protocols pim] aviva@RouterG# set rp local address 192.168.19.1 aviva@RouterG# set rp auto-rp announce

With this additional configuration, if RouterA goes down, RouterG automatically becomes RP. Checking on RouterG after the initial configuration, you see that RouterA is the elected RP:

aviva@RouterG> show pim rps inet Instance: PIM.master Address family INET RP address Type Holdtime Timeout Active groups Group prefixes 192.168.13.1 auto-rp 150 150 2 224.0.0.0/4 192.168.19.1 static 0 None 0 224.0.0.0/4

When RouterA goes down, RouterG become the RP:

aviva@RouterG> show pim rps inet Instance: PIM.master Address family INET RP address Type Holdtime Timeout Active groups Group prefixes 192.168.19.1 auto-rp 150 150 2 224.0.0.0/4 192.168.19.1 static 0 None 2 224.0.0.0/4

If you don want the same PIM router to perform both the RP announcement and group mapping functions, configure one router to announce (as we did with RouterG above) and configure another one to map:

[edit protocols pim] aviva@RouterE# set rp auto-rp mapping

After all routers are running auto-RP, look at the PIM interfaces on the routers. First, look at the RP router:

aviva@RouterA> show pim interfaces Instance: PIM.master Name Stat Mode IP V State Count DR address fe-0/0/0.0 Up SparseDense 4 2 NotDR 2 172.19.121.115 fe-0/0/1.0 Up SparseDense 4 2 DR 1 10.0.15.2 lo0.0 Up SparseDense 4 2 DR 0 192.168.13.1 pd-0/0/0.32769 Up Sparse 4 2 P2P 0 se-0/0/2.0 Up SparseDense 4 2 P2P 1 se-0/0/3.0 Up SparseDense 4 2 P2P 0

Then, look at one of the non-RP routers:

aviva@RouterE> show pim interfaces Instance: PIM.master Name Stat Mode IP V State Count DR address fe-0/0/0.0 Up SparseDense 4 2 NotDR 3 172.19.121.119 fe-0/0/1.0 Up SparseDense 4 2 NotDR 1 10.0.15.2 lo0.0 Up SparseDense 4 2 DR 0 192.168.15.1 pe-0/0/0.32770 Up Sparse 4 2 P2P 0 t1-0/0/3.0 Up SparseDense 4 2 P2P 0

On both routers, you see that all the physical interfaces are running PIM in sparsedense mode. You also see two new interfaces, pd-0/0/0 on the RP and pe-0/0/0 on the non-RP. pd stands for n and pe for PIM encapsulation, and they are interfaces on the tunnel, AS, or link services PICs that handle PIM Register messages. PIM Register messages use these two interfaces to encapsulate and de-encapsulate data packets. PIM-SM RPs create pd interfaces so they can remove multicast data from PIM Register messages, and PIM-SM routers that see a local multicast source on one of their interfaces use pe interfaces to send Register messages.

JUNOS routers perform the encapsulation and de-encapsulation in hardware, using the service PICs, not on the RE. This allows the routers to handle and forward PIM Register messages more quickly than if the RE were doing this. Also, the routing processes running on the Routing Engine do not have to be interrupted to handle PIM Register messages.

See Also

Recipes 16.2 and 16.4