PIM-SM RP Discovery
Last updated
Last updated
In the previous PM-SM labs, we have been manually configuring the RP address. This is quite burdensom. The larger your network, the more you have to copy and paste the ip pim rp-address command. This also doesn’t allow for multiple redudant RPs.
There are two RP auto-discovery mechanisms. First, Auto-RP was invented by Cisco and is Cisco proprietary. Auto-RP uses Candidate RPs and Mapping Agents. Candidate RPs are routers that are potential RPs, and they advertise their status to Mapping Agents using the multicast group 224.0.1.39. Mapping Agents select the best RP among all candidate RPs and announce this to all PIM routers using the multicast group 224.0.1.40.
Auto-RP requires multicast to be used before an RP is discovered. This presents a chicken-and-egg problem, where you need an RP to build shared trees for 224.0.1.39/224.0.1.40 in order to disseminate the RP information in the first place. The traditional solution was to use sparse-dense-mode, and the new solution is to use the autorp listener feature. We will explore this in the lab.
BSR (Bootstrap Router) was created after Auto-RP and is built into PIM itself. The RP is learned via PIM messages, negating the use of sparse-dense-mode. These days, BSR has replaced Auto-RP, and Auto-RP is considered legacy. Nevertheless we will look at both Auto-RP and BSR.
We will re-use our lab from the previous PIM-SM articles:
Auto-RP uses the following roles:
Candidate RP
Advertises candidate RP status to Mapping Agents using 224.0.1.39 (Cisco-RP-Announce)
Configured using ip pim send-rp-announce
Mapping Agent
Listens for candidate RPs at 224.0.1.39
Advertises the best RP for each group mapping to routers using 224.0.1.40 (Cisco-RP-Discovery)
Configured using ip pim send-rp-discovery
“Regular” PIM-SM router
Listens for RP mappings at 224.0.1.40
You can have multiple mapping agents, multiple candidate RPs, and a single router can preform both the mapping agent and candidate RP function. A mapping agent picks the best RP for a given mapping from all candidate RPs using the highest IP address.
An RP can be mapped to only a selective multicast address range. For instance, one RP can preform the RP role for only 225.1.1.0/24 and another RP can preform the RP role for 239.0.0.0/8. The RP and its associated group addresses for which it will act as an RP, is called an RP mapping. So far we have used the default mapping, which is 224.0.0.0/4 (all multicast group addresses). You can control the mapping by referencing an ACL in the ip pim send-rp-announce command.
Let’s see Auto-RP in action. Remove the static RP configuration on every router. If there exists a static RP address and an auto-discovered RP address via Auto-RP, the Auto-RP address is used. (If you wish to override this behaviour, you can use the command ip pim rp-address 1.1.1.1 override to force the static RP to be used over a dynamically learned RP). Let’s remove the static RP to test whether we need to configure sparse-dense mode.
If you still have any hosts configured to join a multicast group, the shared tree is now broken. Notice that the (*, G) entries have a incoming interface of null.
Also notice the (*, 224.0.1.40) entry which is there by default. All IOS routers have this entry when you enable multicast. I have left this entry out of show commands up until this point, to not create any confusion. This is how all PIM-SM routers will automatically hear RP mappings from the mapping agent - all PIM-SM routers are already subscribbed to 224.0.1.40.
The D flag means that this entry is operating in dense mode. Traditionally, you would need to configure sparse-dense-mode under every interface when using Auto-RP. This instructed the router to use dense mode for all multicast traffic if there was no known RP, and use sparse mode if there was a known RP. This allowed the Auto-RP mechanism to work first using dense mode, and then once an RP was learned, the router would switch to sparse mode.
Let’s configure R2 as the mapping agent, and R6 as the Candidate RP.
You must specify an interface to use for the source address. This interface must have PIM enabled. You also must specify the scope. The scope value will be used for the TTL of the packet. By configuring a low TTL value, you can control the “spread” of the rp-discovery messages.
This output is fairly confusing, because the router actually joined 224.0.1.39. If you check the adjacent neighbors to R2, you can see that new state for (*, 224.0.1.39) has been created. You’ll also notice the D flag on this entry as well.
Let’s now configure R6 to advertise itself as a candidate RP to 224.0.1.39.
R6 floods this RP announcement. Notice that it uses the default 224/4 group:
R2 has now received RP announcements (from R6) and sends its own RP Discovery messages to 224.0.1.40.
Other routers have automatically learned the RP from the RP Discovery messages. It times out in 3 mins, so R2 will flood this every minute.
Take a look at R5, it has not learned the RP.
This is because, by default, only routers which are adjacent to the mapping agent will learn the RP via the RP Discovery messages. These routers are not forwarding the traffic. They need to treat the traffic as dense mode. On adjacent routers, you must either use sparse-dense-mode, or the better option is to use autorp listener. This command is poorly worded in my opinion. It should really be called autorp forwarder because it instructs the router to forwarded the autorp messages as dense mode.
R4 now treates 224.0.1.40 as dense mode and floods it out all interfaces where it has a PIM neighbor. autorp listener causes the router to treat 224.0.1.39/224.0.1.40 as dense mode.
R5 now has the mapping:
Let’s now experiment with a restricted RP mapping, and also see what happens when we have multiple RPs.
We will configure both R6 and R1 to be a candidate RP for 239/8.
Wait at least 3 mins for the 224/4 entry to time out on R2. Then check the RP mappings. You should see both R1 and R6 with a mapping for 239/8.
The mapping agent will only pick a single RP to advertise to other routers. It picks the RP with the highest IP address. On other routers you should only see 239/8 mapped to R6.
Auto-RP was drafted before BSR existed. Some time later, BSR was added to the PIM specification in PIMv2 (which is the default version now). BSR is a big improvement over Auto-RP, and Auto-RP is now considered legacy.
BSR distributes group-to-RP mappings directly in PIM messages. This means you don’t need to create a dense mode workaround like in Auto-RP. The BSR mapping is flooded to all PIM routers in the network.
BSR has similar roles to Auto-RP:
Candidate RPs (C-RPs)
Just like Auto-RP, each candidate RP can have a specified group mapping.
A candidate RP announces its status to the elected BSR via unicast. The router learns the address of the elected BSR via flooded PIM messages.
Candidate BSR (C-BSR)
Comparable to the Auto-RP Mapping Agent.
A candidate BSR announces its status via PIM messages.
A single BSR is elected. The elected process works similar to spanning-tree root bridge election, in that a candidate BSR will stop announcing its status if a “better” candidate BSR is seen.
A BSR is better if it has a higher priority or higher IP address
The default priority is 0
The BSR receives Candidate RP information and distributes all mappings via PIM messages. This is known as the RP-set.
In Auto-RP, the Mapping Agent only distributes information for the best RP
Let’s see BSR in action. Remove all Auto-RP configuration from R1, R2, and R6.
Configure R2 to be a Candidate BSR:
R2 floods PIM Bootstrap messages out all interfaces every 60 seconds announcing itself as BSR:
This is flooded on a hop-by-hop basis. All routers in the network learn the address of the BSR via these PIM Bootstrap messages. For example, R5 knows the BSR is at 2.2.2.2:
Configure R1 and R6 as candidate RPs again for 239/8. The ACL should still exist in the config if you are re-using the lab.
Each router sends a unicast PIM Candidate-RP-Advertisement message directly to the BSR:
The BSR disseminates information for all RP mappings, called the RP-set. Check R5’s RP mappings:
Hopefully you agree that BSR is much more straight-forward than Auto-RP. BSR embeds the RP discovery process directly into PIM messages, negating the need to play dense-mode tricks as we do with Auto-RP.
By default, when a router has multiple RPs for a given mapping, it will use the RP with the highest priority or highest IP address. What is a little confusing with the RP priorty value, is that the lowest priority is best. For the BSR priority, the highest is best. The default value for both is 0.
BSR has a mechanism to load share among multiple RPs with equal priorty values by using a hash algorithm. When you configure a router as a C-BSR, you can optionally associate a hask mask value with the BSR advertisement. This is used by a router to do load sharing.
An example will help explain this. Configure R2 to use a hash value of 30 in its BSR advertisement. By default, if you do not specify the hash value, it will be 0, meaning no load sharing.
R5 will now use R1 for half the groups and R6 for half the groups. You can test this by using the command show ip pim rp-hash group
The mask value is used to group mappings together. With a 30 mask value, every /30 will produce the same hash value. The idea is that 239.0.0.0/30 will map to one RP, and 239.0.0.4/30 will map to the other RP, alternating for every /30. However, in my lab, it doesn’t appear to work like this. Nevertheless, we can see above that there is some load sharing happening.
Auto-RP is a Cisco-proprietary mechanism for RP discovery that was created before RP discovery was written into the PIM specification. Auto-RP is now considered legacy. In Auto-RP, you must treat the two multicast groups, 224.0.1.39 and 224.0.1.40 as dense mode.
BSR was written into the PIMv2 specification. A single BSR router is elected. Candidate RPs advertise their status and mappings to the BSR via unicast. The BSR disseminates this information in native PIM messages. These are flooded hop-by-hop. BSR also allows for a hash value in order to load share among multiple RPs with the same mapping.
Auto-RP
BSR
How do routers learn RP mappings?
via the mapping agent, which sends mappings to 224.0.1.40
via PIM Bootstrap messages which are flooded hop-by-hop
How many RPs does a router learn for each mapping?
Only the best RP
All RPs (the RP-set)
How do candidate RPs advertise their status?
via 224.0.1.39 which the mapping agent listens to
via Unicast to the elected BSR
How can a router load share among multiple RPs?
Cannot be done
By using the hash value, which is advertised by the BSR. By default it is 0 which means no load sharing, only the RP with the highest IP is used.
