Rendezvous Point Engineering

Introduction

A Rendezvous Point (RP) is a router in a multicast network domain that acts as a shared root for a multicast shared tree. Any number of routers can be configured to work as RPs and they can be configured to cover different group ranges. For correct operation, every multicast router within a Protocol Independent Multicast (PIM) domain must be able to map a particular multicast group address to the same RP.

This document attempts to describe, compare and contrast the different methods for deploying RPs. For details on how to configure an RP using any of the methods discussed in this document please refer to the following White Paper: Configuring a Rendezvous Point.

This document discusses the following mechanisms:

• Static RP

• Bootstrap Router (BSR)

• Auto-RP

• Anycast-RP

• Phantom RP

• Embedded RP

Static RP

It is possible to statically configure an RP for a multicast group range. The address of the RP must be configured on every router in the domain. Configuring static RPs is relatively easy and can be done with one or two lines of configuration on each router. If the network does not have many different RPs defined and/or they do not change very often, then this could be the simplest method to define RPs. This can also be an attractive option if the network is small.

However this can be a laborious task in a large and complex network. Every router must have the same RP address. This means changing the RP address requires reconfiguring every router. If several RPs are active for different groups, then information regarding which RP is handling which group must be known by all routers. To ensure this information is complete, several configuration commands may be required. If the manually configured RP fails, there is no failover procedure for another router to take over the function performed by the failed RP. This method does not provide any kind of load-balancing. Static RP can be combined with Anycast RP to provide RP load sharing and redundancy.

Static RP can co-exist with dynamic RP mechanisms (ie: Auto-RP). Dynamically learned RP takes precedence over manually configured RPs. If a router receives Auto-RP information for a multicast group that has manually configured RP information, then the Auto-RP information will be used.

BSR

The Bootstrap Router (BSR) is a mechanism for a router to learn RP information. It ensures that all routers in the PIM domain have the same RP cache as the BSR. It is possible to configure the BSR to help select an RP set from BSR candidate RPs. The function of the BSR is to broadcast the RP set to all routers in the domain.

Figure 1 shows the BSR mechanism, where the elected BSR sends BSR messages with RP set information out on all enabled interfaces, which are flooded hop-by-hop to all routers in the network. The candidate-RPs send their candidate-RP advertisements directly to the elected BSR.

Figure 1. BSR Mechanism

The elected BSR receives candidate-RP messages from all candidate-RPs in the domain. The bootstrap message sent by the BSR includes information about all the candidate-RPs. Each router uses a common algorithm to select the same RP address for a given multicast group.

For more information about bootstrap routers, see RFC5059.

The BSR mechanism is a nonproprietary method of defining RPs that can be used with third-party routers (which support the BSR mechanism). There is no configuration necessary on every router separately (except on candidate-BSRs and candidate-RPs). The mechanism is largely self-configuring making it easier to modify RP information. Information regarding several RPs for different groups is automatically communicated to all routers, reducing administrative overhead. The mechanism is robust to router failover and permits back-up RPs to be configured. In case of RP failure, the secondary RP for the group can take over as the RP for the group.

Auto-RP and BSR protocols must not be configured together in the same network.

Auto-RP

Auto-RP is a mechanism to automate distribution of RP information in a multicast network. The Auto-RP mechanism operates using two basic components, the candidate RPs and the RP mapping agents.

• Candidate RPs advertize their willingness to be an RP via "RP-announcement" messages. These messages are periodically sent to a reserved well-known group 224.0.1.39 (CISCO-RP-ANNOUNCE).

• RP mapping agents join group 224.0.1.39 and map the RPs to the associated groups. The RP mapping agents advertise the authoritative RP-mappings to another well-known group address 224.0.1.40 (CISCO-RP-DISCOVERY). All PIM routers join 224.0.1.40 and store the RP-mappings in their private cache.

Figure 2 shows the Auto-RP mechanism where the RP mapping agent periodically multicasts the RP information that it receives to the Cisco-RP-Discovery group.

Figure 2. Auto-RP Mechanism

All routers automatically learn the RP information making it easier to administer and update RP information. There is no configuration needed on every router separately (except on candidate RPs and mapping agents). Auto-RP permits back-up RPs to be configured enabling an RP failover mechanism.

Auto-RP is not supported for IPv6 Multicast. Auto-RP is a Cisco proprietary mechanism.

BSR and Auto-RP protocols must not be configured together in the same network.

Anycast-RP

Anycast RP is used to define redundant and load-balanced RPs. Anycast-RP has two implementations:

• Using Multicast Source Discovery Protocol (MSDP) described in RFC3446.

• Using Protocol Independent Multicast (PIM) described in RFC4610.

Anycast-RP allows two or more RPs to share the load for source registration and to act as hot back-up routers for each other. Multicast Source Discovery Protocol (MSDP) is the protocol RPs to share information about active sources. With Anycast RP, the RPs are configured to establish MSDP peering sessions using a TCP connection. Group participants use the closest RP that is favored by the IP unicast route table.

Figure 3. Anycast-RP Mechanism

Figure 3 shows the Anycast-RP mechanism. Two or more RPs are configured with the same IP address on loopback interfaces. All the downstream routers are configured to "know" that the Anycast RP loopback address is the IP address of their RP. When an RP fails, IP routing converges and the other RP assumes the RP role. Further details on Anycast-RP can be found in the following White Paper: Anycast RP Overview.

PIM Anycast-RP extends the Register mechanism in PIM so that Anycast-RP functionality can be retained without using MSDP. PIM register messages are sent to the closest RP and PIM join-prune, messages are sent in the direction of the closest RP as determined by the unicast routing protocols. If one of the RPs goes down, unicast routing ensures these messages will be sent in the direction of the next-closest RP.

Anycast-RP provides RP failover and redundancy. Anycast-RP can be used along with static RP or Auto-RP to provide RP redundancy.

Phantom RP

In Bidirectional PIM (Bidir-PIM), the RP does not have an actual protocol function. The RP acts as a routing vector in which all the traffic converges. The RP can be configured as an address that is not assigned to any particular device called a Phantom RP. This means that the RP address does not need to reside on a physical router interface, but can just be an address in a subnet. The RP can also be a physical router, but it is not necessary.

More details on Phantom RP can be found in the Bidirectional PIM Deployment Guide.

Embedded RP

Embedded RP defines an address allocation policy in which the address of the RP is encoded in an IPv6 multicast group address. This allows an easy deployment of scalable inter-domain multicast and simplifies the intra-domain multicast configuration as well. IPv6 Multicast group addresses embedded with RP information start with ff70::/12 where the flag value of 7 means embedded RP.

Figure 4. Multicast Address with Embedded RP

There is no need to pre-configure routers with the RP address information. Routers can automatically extract and use the RP information from the IPv6 multicast group address. This allows for a large number of RPs to be deployed anywhere in the Internet. Embedded RP requires no change in protocol operations. It can be considered an automatic replacement for static RP configuration.

The router can learn only one RP address for a multicast group using embedded RP. It cannot support RP redundancy. Proposals are being considered to introduce RP redundancy by mechanisms other than BSR for IPv6 multicast. Embedded RP does not support Bidirectional PIM. Embedded RP allows the application to dictate which router is the RP. There is the possibility that a low-end router could end up becoming the RP for hundreds of high data rate sources if the application defines an erroneous RP address (this can be prevented by disabling Embedded RP learning).

For more information on Embedded RP, see RFC3956.

Conclusion

There are various mechanisms for disseminating RP information across a multicast network. Each mechanism has different pros and cons. Table 1-1 compares the approaches discussed in this document.

Table 1. Comparison of RP Mechanisms

	Static RP	BSR	Auto-RP	Embedded RP
Must be configured on every router	Yes	No (except on candidate-BSRs and candidate-RPs)	No (except on candidate RPs and mapping agents)	No (except RP routers)
Supports IPv4 addresses	Yes	Yes	Yes	No
Supports IPv6 addresses	Yes	Yes	No	Yes
RP redundancy	No (unless used with Anycast RP)	Yes	Yes	No

Anycast RP can be used to provide redundancy and load-sharing capabilities. Phantom RP can be an attractive solution for Bidirectional PIM.

Related Documents

IP Multicast Technology Overview, Cisco White Paper: http://www.cisco.com/en/US/docs/ios/solutions_docs/ip_multicast/White_papers/mcst_ovr.html

Configuring a Rendezvous Point, Cisco White Paper: http://www.cisco.com/en/US/docs/ios/solutions_docs/ip_multicast/White_papers/rps.html

Anycast RP White Paper: http://www.cisco.com/en/US/docs/ios/solutions_docs/ip_multicast/White_papers/anycast.html

"Configuring Multicast Source Discovery Protocol," Cisco IOS IP Configuration Guide, Release 12.2: http://www.cisco.com/en/US/docs/ios/12_2/ip/configuration/guide/1cfmsdp_ps1835_TSD_Products_Configuration_Guide_Chapter.html

Bidirectional PIM Deployment Guide: http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6552/ps6592/prod_white_paper0900aecd80310db2.pdf

Multicast - Bootstrap Router (BSR)

As we discussed in last post about BSR in PIM sparse mode, Let’s see more detail about BSR in this section...

BSR is standard protocol, which work with PIM to advertise RP in network. But we need to elect BSR first. We can define BSR as -BSR is Router, Which will collect all RP advertisement from network and make a set of RP address and advertise/share in network.  In Cisco Auto-RP - it is different, Auto-RP will select the best RP and advertise only one best RP in all network.

                Both protocols use the same information which is coming from rp candidate advertisement.

Let me explain this process- First you will select a router. Which you want to designate as BSR

Syntax – ip pim bsr- candidate fastethernet0

Using this command we can designate the router as BSR router in network. Then those routers which are near to source or concern router we want to designate as RP. We need to configure this command.

Syntax- ip pim rp-candidate fastethernet0

At this time, router will start sending candidate RP announcements to BSR Routers. BSR will collect the announcements and make a set of all RP announcements and advertise in network through PIM messages.

                BSR advertisement will go thru RPF check same like PIM. Then all routers will have BSR information in network along with RP information. As the join request will come to router, Router will check the RP address and reach to source. BSR is reducing manual overhead to configure static RP in every router.

                          

             We can configure redundant BSR in network. In that case we need to configure priority for BSR. Highest priority will win and elected as Master BSR. As you enable a router as BSR, it will send bootstrap messages in network.BSR message contains BSR address with priority. As other router will receive the bootstrap messages it will come to know that one more BSR router is in network. It will check the priority associated with message and select our role. Depending on priority master will be elected. Higher wins...

Syntax – ip pim bsr-candidate interface [hash-mask-length [priority]]

Priority – 0 to 255

In Maipu Routers - By default, hash-mask-length is 10 and priority is 0.

In Cisco Routers – by default the priority is 0.

                                    In RP also we can configure priority, In RP lowest priority wins. As we require RP for particular group that time we can configure Access-list and bind it with RP and advertise with priority. In case of lower priority BSR will consider that RP and advertise in network.

Default RP priority in Maipu Router – 192

Default RP priority in Cisco - 0 which specifies 192.

                   

                          If some RP is advertising lowest priority like 190, then it will master RP which BSR will be advertise in network.

                          RP send unicast messages to configured BSR routers continuously. So as the RP change happen in network. It will get notified by BSR immediately.

Hope this post clarified you about BSR and RP election and working flow. We will see configuration and scenario for more understanding in coming posts...

If you like this post and for any queries Plz comment with your mail id...

PIM Sparse-Mode / BootStrap Router (BSR) part II

In this lab I’ve setup a basic multicast environment using PIM ( Protocol Independent Multicast ) in a Sparse-Mode Style configuration. What does this mean? Basically, Sparse mode is an on-demand type of multicast routing, as opposed to Dense mode, which is a Push/Prune based mechanism. Most implementations of multicast routing will use Sparse-Mode because it reduces the burst[s] of traffic which occur in PIM Dense mode ( State Refresh helps remedy this behavior in Dense Mode, but that is another topic ).

I’m a big fan of digging deep into the internal operations of network protocols. So Wireshark will be used to uncover the intimate details of PIM, IGMP, and BSR, as a go along. I encourage others to do the same!

1. IGP & Unicast Routing

Before we get started we need to make sure our IGP is configured properly. Hopefully this doesn’t come as a surprise, but in order for Multicast routing to work properly, Unicast routing must be in order. In my configuration all links ( including loopbacks) are advertised into my IGP. I decided to uses OSPF with all links in area 0.

RP Discovery & Configuration

So we have this thing called an RP (Rendezvous Point). The RP facilitates multicast flows between listeners and senders. Simply put, if a multicast source sends traffic, the RP is notified, and if a client is interested in a particular groups traffic, the RP is notified. The RP can then build a tree between a source and listener for multicast traffic to flow through, alleviating the flood and prune behavior of PIM Dense Mode. So how do we setup an RP? There are two ways to configure an RP: Dynamically or Statically. A static RP configuration is very straight forward. Simply pick a router in your network that you wish to be the RP, and configure all of your routers with that information ( In Cisco IOS: ip pim ). Dynamic RP election is a bit more complicated. We have two choices for dynamically learning an RP, Auto-RP & BSR. As the title says, this lab will be discussing BSR, so I wont get into the details of Auto-RP.

BSR Protocol

BSR is a protocol for discovering candidate RPs, and then advertising that information to all other routers in the network. There are two mechanisms in the BSR protocol. You have BootStrap routers which listens for candidate RP advertisements, and you have Candidate RPs which advertise themselves as suitable RPs for any number of multicast addresses ( default 224.0.0.0/4 ). This is a much more scalable solution than static configuration, especially when you have a lot of devices in your network. It is also better than Auto-RP, because you do not need to run the cisco-rp-announce (224.0.1.39) and cisco-rp-discovery (224.0.1.40) groups in dense mode.
Lets go over BSR operation step by step. But first, I will configure R6 (BSR Candidate), and R4 (RP Candidate). Note: BSR/RP Candidate can be the same router, but to demonstrate the full operation I have the roles split between two devices).
BSR Candidate (R6)

?

R6(config)#ip multicast-routing R6(config)#interface loopback 0 R6(config-if)#ip address 6.6.6.6 255.255.255.255 R6(config-if)#ip ospf 1 area 0 R6(config-if)#ip pim sparse-mode R6(config-if)#exit R6(config)#interface FastEthernet 0/0 R6(config-if)#ip address 10.4.4.6 255.255.255.240 R6(config-if)#ip ospf 1 area 0 R6(config-if)#ip pim sparse-mode R6(config-if)#exit R6(config)#interface FastEthernet 0/1 R6(config-if)#ip address 10.6.6.6 255.255.255.240 R6(config-if)#ip ospf 1 area 0 R6(config-if)#ip pim sparse-mode R6(config-if)#exit

?

R6(config)#ip pim bsr-candidate Loopback0 0 0 R6(config)#

ip pim bsr-candidate [interface] [hash-mask-length] [priority]
interface: Interface to source BSR advertisements from
hash-mask-length:This allows you to specify how multicast groups are distributed between RPs, when multiple Candidate RPs have the same Priority. I highly suggest reading TCP/IP Routing Volume II by Jeff Doyle, for more details on this process. (default 0).
priority: BSR Candidate priority. Higher is better (default 0).
RP Candidate (R6)

?

R4(config)#ip multicast-routing R4(config)#interface loopback 0 R4(config-if)#ip address 4.4.4.4 255.255.255.255 R4(config-if)#ip ospf 1 area 0 R4(config-if)#ip pim sparse-mode R4(config-if)#exit R4(config)#interface FastEthernet 0/0 R4(config-if)#ip address 10.4.4.4 255.255.255.240 R4(config-if)#ip ospf 1 area 0 R4(config-if)#ip pim sparse-mode R4(config-if)#exit R4(config)#interface FastEthernet 0/1 R4(config-if)#ip address 10.1.1.4 255.255.255.240 R4(config-if)#ip ospf 1 area 0 R4(config-if)#ip pim sparse-mode R4(config-if)#exit

?

R4(config)#ip pim rp-candidate Loopback0 priority 0 R4(config)#

ip pim rp-candidate [interface] group-list [access-list-number] priority [priority-number]
interface: Interface to source RP advertisements from
group-list: (optional): Specify an ACL which includes the Multicast groups. Default is 224.0.0.0/24
priority (optional): specify RP priority. Lower is better (default 0).
BSR Election
Candidate Bootstrap routers send BSM (Bootstrap Messages) to multicast address 224.0.0.13 ( ALL-PIM-ROUTERS). These messages are forwarded hop-by-hop as long as they’re received on an interface which passes an RPF check for the BSR Candidate IP. Because we only have 1 Bootstrap router there is no BSR election. However if there were multiple Candidate BSRs, the BSR with the highest Priority wins. If there is a tie in priority, highest IP address wins. BSR priority is specified during configuration of the BSR Candidate, see above.
Bootstrap (BSR Election) Message: Sent by R6, multicast to 224.0.0.13 & forwarded by each router.

?

Ethernet II, Src: c2:02:74:55:00:00 (c2:02:74:55:00:00), Dst: IPv4mcast_00:00:0d (01:00:5e:00:00:0d) Internet Protocol, Src: 10.4.4.6 (10.4.4.6), Dst: 224.0.0.13 (224.0.0.13) Protocol Independent Multicast     Version: 2     Type: Bootstrap (4)     Checksum: 0xa8ce [correct]     PIM parameters         Fragment tag: 0x2625         Hash mask len: 0         BSR priority: 0         BSR: 6.6.6.6

RP Candidate Advertisement
Each Candidate RP unicasts their RP Groups & Priority directly to the Bootstrap router.
RP Advertisement to BSR: Sent by R4, unicast to R6.

?

Ethernet II, Src: c2:00:74:55:00:00 (c2:00:74:55:00:00), Dst: c2:02:74:55:00:00 (c2:02:74:55:00:00) Internet Protocol, Src: 10.4.4.4 (10.4.4.4), Dst: 6.6.6.6 (6.6.6.6) Protocol Independent Multicast     Version: 2     Type: Candidate-RP-Advertisement (8)     Checksum: 0xec5c [correct]     PIM parameters         Prefix-count: 1         Priority: 0         Holdtime: 150         RP: 4.4.4.4         Group 0: 224.0.0.0/4

RP Election
The Bootstrap router forwards RP information it receives to the rest of the network via multicast ( 224.0.0.13 ). Each individual router in the network picks the best RP to group mappings. For RP election, lowest priority wins ( contrary to BSR election in which highest priority wins). RP priority is specified during Candidate RP configuration, see above.
Bootstrap Message with RP mappings: Sent by R6, multicast to 224.0.0.13 & forwarded by each router.

?

Ethernet II, Src: c2:02:74:55:00:00 (c2:02:74:55:00:00), Dst: IPv4mcast_00:00:0d (01:00:5e:00:00:0d) Internet Protocol, Src: 10.4.4.6 (10.4.4.6), Dst: 224.0.0.13 (224.0.0.13) Protocol Independent Multicast     Version: 2     Type: Bootstrap (4)     Checksum: 0xcf99 [correct]     PIM parameters         Fragment tag: 0x13b6         Hash mask len: 0         BSR priority: 0         BSR: 6.6.6.6         Group 0: 224.0.0.0/4             RP count: 1             FRP count: 1             RP 0: 4.4.4.4             Holdtime: 150             Priority: 0

Based on the information in the final BSM, it should be fairly easy to figure out the RP to group mappings. We only have one Candidate RP, and it is advertising itself as the RP for the entire multicast range, 224.0.0.0/4. We can confirm this on any of the PIM routers in the network

?

R1#show ip pim rp mapping

PIM Group-to-RP Mappings

 

Group(s) 224.0.0.0/4

  RP 4.4.4.4 (?), v2

    Info source: 6.6.6.6 (?), via bootstrap, priority 0, holdtime 150

         Uptime: 04:03:30, expires: 00:01:31

R1#

Chapter 9: Bootstrap Router (BSR) Protocol

In this chapter of IPv4/6 Multicast Operation and Troubleshooting, the processes and the functionality of the Bootstrap Router (BSR) protocol are examined in great depth. Once the operational characteristics of this important protocol are detailed completely, the focus becomes that of troubleshooting. This includes the careful examination of symptoms, a fault isolation methodology, and the implementation of repairs for the Bootstrap Routing (BSR) protocol. The chapter begins with a thorough review of BSR, and then quickly launches in to an exhaustive analysis of the “art” of troubleshooting this multicast support protocol. This important chapter concludes with sample troubleshooting scenarios, reference materials for the most important show and debug commands, and exciting challenges that allow readers to practice implementing the troubleshooting skills they have obtained.

BSR Technology Review

Bootstrap router (BSR) was created as an open standard solution meant to address many of the shortcomings in the Cisco proprietary AutoRP technology. The Protocol Independent Multicast Sparse Mode (PIM-SM) version 2 specification introduced BSR.
Note: Many texts refer to BSR as simply PIM-SM version 2.
While BSR addresses many issues with AutoRP, it operates in a very similar manner when examined from a high level. There are router(s) that act as candidate-Rendezvous Points (RPs) and router(s) that act similar to the Mapping Agent (MA) found in AutoRP. In BSR terminology, the equivalent to the Mapping Agent is the Bootstrap Router itself.
Note: AutoRP is detailed in Chapter 8: AutoRP.
Figure 9-1 demonstrates a sample BSR topology.

Figure 9-1: A Sample BSR Topology

A major design improvement over Cisco’s AutoRP is the fact that BSR requires no dense mode operation whatsoever. Rendezvous Point (RP) information is within BSR messages, which are carried inside of Protocol Independent Multicast (PIM) messages themselves. These PIM messages are link-local multicast messages. When a router receives a BSR message containing RP information, the router applies the Reverse Path Forwarding (RPF) check and then floods the message out all of the PIM-enabled interfaces. Remember, the link-local multicast address used for PIM messages is 224.0.0.13.
Since the PIM messages that carry the BSR information are link-local in scope, notice that there is no Time to Live (TTL) scoping that can be used with BSR.
Note: BSR and AutoRP cannot interoperate directly with each other.
Obviously, a key element to the BSR process is the device or devices that want to serve as the Rendezvous Point for multicast groups in the Sparse Mode domain. To configure a candidate-RP in BSR, use the following command:
ip pim [vrf vrf-name] rp-candidate interface-type interface-number [bidir] [group-list access-list] [interval seconds] [priority value]
Where:

• vrf – configures the router to advertise itself as the candidate-RP to the Bootstrap Router for the Virtual Routing and Forwarding (VRF) instance specified for the vrf-name argument
• interface-type interface-number – the interface bound to the IP address to serve as the candidate-RP IP address; for availability purposes, consider the use of a loopback interface; this interface needs to be PIM enabled
• bidir - optional – indicates that the multicast groups specified by the access-list argument are to operate in PIM bidirectional mode; PIM bidirectional mode is covered in Chapter 6: Bidirectional PIM
• group-list - optional – specifies the prefixes that are advertised in association with the RP address; note that unlike AutoRP, this list cannot contain DENY entries
• interval - optional – specifies the candidate-RP advertisement interval, in seconds; the range is from 1 to 16383 with a default value of 60 seconds
• priority - optional – specifies the priority for the candidate-RP; the range is from 0 to 255; with a default priority value of 0; the BSR candidate-RP with the lowest priority value is preferred; be aware that other vendor implementations of BSR might default priority to 192 as this is the recommended default priority by the IETF

As stated earlier, the Bootstrap Router itself in the topology is similar to the Mapping Agent in AutoRP with some subtle differences. Like the AutoRP Mapping Agent, the BSR listens to the candidate-RP announcements, but the BSR does not actually select the best RP for every group range. Instead, the BSR builds a set of candidate-RPs for each group range and disseminates this information to the topology using PIM. Multicast routers that receive these BSR messages select the preferred candidate-RP using a special hash function.
To configure the BSR router itself, use the following command:
ip pim [vrf vrf-name] bsr-candidate interface-type interface-number [hash-mask-length [priority] ]
Where:

• vrf – configures the router to advertise itself as the Bootstrap Router for the Virtual Routing and Forwarding (VRF) instance specified for the vrf-name argument
• interface-type interface-number – the interface bound to the IP address to serve as the BSR device IP address; for availability purposes, consider the use of a loopback interface; this interface needs to be PIM enabled and the IP address is sent in BSR messages as the BSR IP address
• hash-mask-length – optional – the length of the mask to be ANDed with the group address before the PIMv2 hash function; all groups with the same seed hash correspond to the same RP; the hash mask length allows one RP to be used for multiple groups; the default length is 0
• priority - priority of the candidate-BSR; the range is from 0 to 255 with a default priority of 0; the candidate-BSR with the highest priority value is preferred; RFC 5059 specifies that 64 be used as the default priority value

It is important to remember that in BSR, the multicast routers determine the RP to use based on RP-set information received from the BSR itself. The RP selection process for a particular multicast group is as follows:
Step 1 - a longest match lookup is performed on the group prefix that is announced by the BSR candidate-RPs
Step 2 - if more than one candidate-RP is found by the longest match lookup, the candidate-RP with the lowest priority (configured with the ip pim rp-candidate command) is preferred
Step 3 - if more than one candidate-RP have the same priority, the BSR hash function is used to select the RP for a group; this hash function is covered in detail in the Operation and Troubleshooting BSR section of this chapter
Step 4 - if more than one candidate-RP return the same hash value derived from the BSR hash function, the candidate-RP with the highest IP address is preferred
Note: RFC 2362 does not specify the longest match lookup step, to ensure compatibility with this standard, configure the same group prefix length for redundant candidate-RPs.
Anthony Sequeira CCIE, CCSI
Twitter: @compsolv
Facebook: http://www.facebook.com/compsolv

IP Multicast and PIM Rendezvous Points

Introduction

For the friends tracking how we're doing, a small group of ex-Mentor folks have formed Chesapeake NetCraftsmen ( http://www.netcraftsmen.net ). We're doing high-end consulting and selected training. See the blurb paragraph for links. In these articles, we've been talking about IP Multicast. This month we'll take a look at options concerning Rendezvous Points, which are needed for IP Multicast using PIM Spare Mode. (As we saw, this is the approach to IP multicast that scales best.)
Previous articles that might be of interest:

• The Protocols of IP Multicast
• PIM Dense Mode
• PIM Sparse Mode

Why Rendezvous Points?

A Rendezvous Point (RP) is used as a temporary way to connect a would-be multicast receiver to an existing shared multicast tree passing through the rendezvous point. When volume of traffic crosses a threshold, the receiver is joined to a source-specific tree, and the feed through the RP is dropped. You can think of this as obtaining copies of something through a friend who already subscribes, and when it proves useful or interesting, it's worth the bother to become a direct subscriber. So: the scalable way to do multicast is PIM Sparse Mode (PIM-SM), and PIM-SM requires that you have at least one RP.

How Many Ways to RP?

There are three ways I know of to set up a RP:

• manual configuration in each leaf routers
• auto-RP
• bootstrap router with PIM version 2

There are actually more combinations and choices, but we don't have space and time for all of them. Nor is it really necessary, when you understand what is possible. See however the online Cisco document at http://www.cisco.com/warp/public/cc/pd/iosw/tech/rppim_rg.htm . It contains configurations for 10 different RP scenarios!

Manual Configuration of RP

This is simple but not very scalable, nor is it robust. Globally configure:

ip pim rp-address rp-address [access-list] [override] [bidir]

For example

ip pim rp-address 172.16.100.100

Supply the RP address on each router in the network. If you supply an access-list, it defines (permits) the multicast groups for this particular RP. Add "override" to over-ride Auto-RP if it is present (see below). If you're doing bidirectional PIM (new, advanced feature), then you can instead specify an access-list and RP for bi-PIM groups.

Auto-RP

Auto-RP automatically distributes information to routers as to what the RP address is for various multicast groups. It simplifies use of multiple RP's for different multicast group ranges. It avoids manual configuration inconsistencies, and allows for multiple RP's acting as backups to each other. Cisco routers automatically listen for this information. Auto-RP relies on a router designated as RP mapping agent. Potential RP's announce themselves to the mapping agent, and it resolves any conflicts. The mapping agent then sends out the multicast group-RP mapping information to the other routers.
How does it does this? It uses multicast to send the mapping information to the other routers! The specific groups used are 224.0.1.39 and .40. The first (.39) is used to advertise, the second (.40) is used for discovery. Of course, there's a chicken and egg problem there: how can you send out multicast information via multicast if the Auto-RP information is needed to make PIM-SM work in the first place?
Generally Auto-RP is used with sparse-dense mode, since then the Auto-RP information can be propagated in dense mode. If your routers are configured with pure sparse-mode on the interfaces, then you can shift to sparse-dense-mode. The other choice with PIM-SM only interfaces is to configure static RP addresses for the Auto-RP multicast groups (the multicast groups used by Auto-RP itself to communicate). That way, the static info gets the Auto-RP multicasts distributed in sparse mode, and then the Auto-RP mapping information allows the other multicast groups to be joined. By the way, you do not need to statically specify a group range for the Auto-RP multicast groups, since normally Auto-RP information takes priority over statically configured information. Thus group mappings advertised via Auto-RP will direct Joins to the correct RP, while the lack of this information for the Auto-RP groups means the statically configured RP for Auto-RP will remain in effect.
Routers that are RP's are configured  with the global configuration command:

ip pim send-rp-announce type number scope ttl-value [group-list access-list] [interval seconds] [bidir]

The type number argument is the name of an interface providing the address for the RP. Scope is the TTL of the announcement (which limits how many router hops it can traverse). You specify which multicast groups the router is RP for with the access-list.
For example:

ip pim send-rp-announce loopback0 scope 16 group-list 10
access-list 10 permit 239.0.0.0 0.255.255.255

By default, such routers advertise themselves every 60 seconds to multicast group 224.0.1.39. They advertise their address, also the range of groups they are RP for. The mapping agents receive this information. They select the highest candidate RP address as RP for each group or range advertised. The mapping agents advertise this, by default every 60 seconds or when changes occur, to multicast group 224.0.1.40. You do have to configure mapping agents (so they know they're the mapping agent):

ip pim send-rp-discovery scope ttl-value

The scope is how many hops the advertisements can take. This allows you to have different mapping agents, each responsible for part of the network. (Some other configuration may also be required to optimize this.) Because the Auto-RP mapping agents use the highest RP for each group or range, you can have redundant RP's. If the one with the highest address fails, the next one will take over (after the cache hold time expires). If you have redundant Auto-RP mapping agents, as long as they advertise the same information, there is no problem. You do need to make sure candidate RP's use a large enough scope to reach all the mapping agents.
If you use administrative scoping (ttl settings), generally you set them on the large side, to make sure the reach every router within the local domain (part of the network). Think of the multicast advertisements as a wave, with scope being the height of the wave. You need to make sure the wave is big enough to reach the fringes of the domain. If you need to keep them from "spilling over" into another part of the network, you can use a boundary command:

interface serial 0
  ip multicast boundary 10 access-list 10 deny 239.0.0.0  0.255.255.255
access-list 10 permit 224.0.0.0 15.255.255.255

This stops specified multicasts from crossing the boundary. You can also use a TTL threshold:

interface serial 0
  ip multicast ttl-threshold ttl-value

Only the packets with TTL greater than the threshold are forwarded out the interface. Routers will act as RP if they receive Join or Prune messages. You can configure your routers to only accept prunes and joins in accord with the Auto-RP mapping information, with:

ip pim accept-rp auto-rp [access-list ]

The access list can be used to control which groups this applies to. You could also statically configure

ip pim accept-rp rp-address [access-list ]

for static RP's, but that gets painful to maintain.

Bootstrap Router

The Bootstrap Router (BSR) capability was added in PIM version 2. It automates and simplifies the Auto-RP process. It is enabled by default in Cisco IOS releases supporting PIMv2. There are interoperability and design issues with PIM v1. See the Configuration Guide for more advice on this. The short form of the advice is to set up your BSR to also be Auto-RP mapping agent, make sure all RP's run PIMv2, and then the PIM versions can interoperate. We'll assume you have upgraded your routers and all are running PIM v2. This means you'll have one active RP per multicast group, compared to several for the same group in PIMv1. You configure sparse-dense-mode on interfaces, since Sparse or Dense are now properties of a multicast group, not an interface.
PIMv1 plus Auto-RP does the same tasks as BSR. But Auto-RP is Cisco proprietary, whereas PIMv2 with BSR is an IETF standards track protocol, which means it should interoperate with routers from other vendors.
To use Bootstrap Router, configure one or more candidate BSR's. These should be well-placed, in the core of your network with good connectivity. Configuration command:

ip pim bsr-candidate type number hash-mask-length [priority]

The type number part of this refers to the interface whose address is used to identify the BSR. The hash-mask-length is how many bits of a multicast group address to use  before consulting a hash table of RP's. The priority is for election as BSR. The hashing allows load balancing across multiple RP's for a range of groups. Only one RP will be used for each group, but the hashing will divide up which RP is used for which group. The hashing scheme is deterministic, so that all routers will use the same scheme and determine the same RP for each group. You also have to configure one or more candidate RPs, as with Auto-RP. RP's should also be  well-connected and in a high-speed and accessible portion of the network.

ip pim rp-candidate type number [group-list access-list] [bidir]

The arguments are identical to those for the send-rp-announce command arguments above. (Interface for RP identity, access list controlling which multicast groups the router is to be an RP candidate for.) The actual operation of BSR is a bit different than Auto-RP. First, a single BSR is elected, based on configured priority. (Highest IP address is used as a tie-breaker.) Candidate RP's then unicast announcements to this BSR, which stores all of the announcements. The BSR periodically floods BSR messages to all the other routers, hop by hop. The flooding is to 224.0.0.13 (all PIM routers) with TTL one. (All 224.0.0.x multicasts are link-local in scope.) Default flooding interval is 60 seconds. If a candidate BSR does not receive a BSR message within 150 seconds, it starts an election. It starts announcing itself until a BSR message with a higher priority is received.
To set up BSR domains, you need to stop BSR messages from going between the domains. This is done simply, via an interface command:

interface serial 0
  ip pim bsr-border

This causes the interface to neither send nor receive BSR messages on that interface. This is much simpler than TTL scoping!

Show Commands

The following show commands may be useful to you in working with RP's and BSR's.

show ip pim rp [mapping | metric] [rp-address]
show ip pim rp-hash [group-address | group-name]
show ip pim bsr

Increasing Redundancy

Static RP allows you to only have 1 RP per group. Forget redundancy with static RP's. Auto-RP allows you to have multiple RP's per group. Only one is used at a time, however. You can also have multiple auto-RP mapping agents, as long as they provide consistent information.
BSR's can be redundantly configured, although only one will be active at any time. You can configure multiple candidate RP's per group range, and the hashing scheme will distribute load across the candidates deterministically. Each group can still only be served by one RP.
PIM RP's have a built-in limitation, which is why all the above approaches only allow one RP per multicast group. The limitation is that when a source for a group starts transmitting, the adjacent edge router has to send unicast PIM Register packets to an RP. If you have multiple RP's, only one could receive the Register packets and learn the source address (and Join towards the source, if there are receivers). The other RP's for the group would remain unaware of the source.
If you configure and run MSDP, Multicast Source Discovery Protocol, it allows source information to be shared among RP's. Thus, when one RP learns of a source for a multicast group, it can pass this information to MSDP neighbors, other RP's. The MSDP neighbors can flood the source advertisement to all RP's in the network.
There's a nice trick that can be used with this. Configure loopbacks on the MSDP-speaking RP's. Configure the loopback interfaces with duplicate IP addresses. Weird! The one place in networking I know of where duplicate IP addresses are actually considered desirable!
Consider what happens if static or Auto-RP or BSR are used with RP's based on the duplicated IP address. When an edge router needs to send a Join, it unicasts it to the duplicated address. When you have a duplicated address, packets go to the closest copy of the address. So Join packets find the nearest RP. If it happens to fail, then packets will just go to another copy of the RP. Since the RP is only used temporarily, followed by a Source-specific Join, should the RP fail, only new Joins will be affected. (Assuming the source-specific threshold isn't set to a high value.) This behavior is called anycast. (As in, get me the packets from anywhere.)
The final degree of flexibility and redundancy for multicast is gained through anycast. It can be added to any of the above techniques for advertising RP's.

Conclusion

For more specific configuration examples, also example of anycast, see the Cisco configuration paper already referenced, at http://www.cisco.com/warp/public/cc/pd/iosw/tech/rppim_rg.htm . As usual, the Configuration Guide is a pretty good resource. The URL follows, as does the URL leading to the 3 relevant sections of the Configuration Reference.

• http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fipr_c/ipcpt3/1cfmulti.htm
• http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fiprmc_r/mult/index.htm

The next article may talk briefly about MBGP, MSDP, bidirectional PIM, and/or source-specific multicast. Or it may not. This subject matter is getting a bit advanced, so we may shift topics to something of broader interest. As always, your emails are welcome. Questions, suggestions for articles, etc. can be sent to pjw@netcraftsmen.net .

Dr. Peter J. Welcher (CCIE #1773, CCSI #94014) is a Senior Consultant with Chesapeake NetCraftsmen. NetCraftsmen is a high-end consulting firm and Cisco Premier Partner dedicated to quality consulting and knowledge transfer. NetCraftsmen has eleven CCIE's (4 of whom are double-CCIE's, R&S and Security). NetCraftsmen has expertise including large network high-availability routing/switching and design, VoIP, QoS, MPLS, network management, security, IP multicast, and other areas. See http://www.netcraftsmen.net for more information about NetCraftsmen. Pete's links start at http://www.netcraftsmen.net/about-us/bios/staff-articles-and-blogs/pete-welcher.html . New articles will be posted under the Articles link. Questions, suggestions for articles, etc. can be sent to pjw@netcraftsmen.net .
Corrections made 1/4/04, from Scott Morris: PIM routers multicast is 224.0.0.13. Note that 224.0.0.x multicasts are link local.
12/5/2001
Copyright (C)  2001,  Peter J. Welcher