PIM-SM RP Discovery

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.

Auto-RP

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.

What is an RP Mapping?

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.

#All routers
no ip pim rp-address 6.6.6.6

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.

R4#show ip mroute

(*, 239.1.1.1), 00:12:01/00:02:01, RP 0.0.0.0, flags: SC
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    GigabitEthernet2, Forward/Sparse, 00:12:01/00:02:01
          
(*, 224.0.1.40), 00:03:36/00:02:11, RP 0.0.0.0, flags: DCL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    GigabitEthernet1, Forward/Sparse, 00:03:36/00:02:11

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.

#R2
int Lo0
 ip address 2.2.2.2 255.255.255.255
 ip pim sparse-mode
!
ip pim send-rp-discovery lo0 scope 255

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.

R2#show ip pim autorp 
AutoRP Information: 
  AutoRP is enabled.
  RP Discovery packet MTU is 1500.
  224.0.1.40 is joined on Loopback0.

PIM AutoRP Statistics: Sent/Received
  RP Announce: 0/0, RP Discovery: 0/0

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.

R4#show ip mroute

(*, 239.1.1.1), 00:20:13/00:02:51, RP 0.0.0.0, flags: SC
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    GigabitEthernet2, Forward/Sparse, 00:20:13/00:02:51
          
(*, 224.0.1.39), 00:01:08/00:02:55, RP 0.0.0.0, flags: DC
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    GigabitEthernet1, Forward/Sparse, 00:01:08/00:02:55

(*, 224.0.1.40), 00:11:48/00:02:59, RP 0.0.0.0, flags: DCL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    GigabitEthernet1, Forward/Sparse, 00:11:48/00:02:59

Let’s now configure R6 to advertise itself as a candidate RP to 224.0.1.39.

#R6
int Lo0
 ip pim sparse-mode
!
ip pim send-rp-announce lo0 scope 255

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.

R2#show ip pim autorp 
AutoRP Information: 
  AutoRP is enabled.
  RP Discovery packet MTU is 1500.
  224.0.1.40 is joined on Loopback0.

PIM AutoRP Statistics: Sent/Received
  RP Announce: 0/2, RP Discovery: 10/0

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.

R4#show ip pim rp 
Group: 239.1.1.1, RP: 6.6.6.6, uptime 00:01:54, expires 00:02:01

R4#show ip mroute 239.1.1.1

(*, 239.1.1.1), 00:25:57/00:02:06, RP 6.6.6.6, flags: SC
  Incoming interface: GigabitEthernet3, RPF nbr 10.4.6.6
  Outgoing interface list:
    GigabitEthernet2, Forward/Sparse, 00:25:57/00:02:06

Take a look at R5, it has not learned the RP.

R5#show ip pim rp
Group: 239.100.100.100, RP: 0.0.0.0

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(config)#do sho ip mroute 224.0.1.40

(*, 224.0.1.40), 00:24:54/stopped, RP 0.0.0.0, flags: DCL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    GigabitEthernet1, Forward/Sparse, 00:24:54/00:02:52
          
(2.2.2.2, 224.0.1.40), 00:09:59/00:02:57, flags: PLTX
  Incoming interface: GigabitEthernet1, RPF nbr 10.2.4.2
  Outgoing interface list: Null

R4(config)#ip pim autorp listener 
    
R4(config)#do sho ip mroute 224.0.1.40


(*, 224.0.1.40), 00:00:02/00:02:57, RP 0.0.0.0, flags: DCL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    GigabitEthernet4, Forward/Sparse, 00:00:02/stopped
    GigabitEthernet3, Forward/Sparse, 00:00:02/stopped
    GigabitEthernet1, Forward/Sparse, 00:00:02/stopped

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:

R5#sho ip pim rp
Group: 239.100.100.100, RP: 6.6.6.6, uptime 00:03:13, expires 00:02:42

R5#show ip pim rp mapping 
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
  RP 6.6.6.6 (?), v2v1
    Info source: 2.2.2.2 (?), elected via Auto-RP
         Uptime: 00:03:16, expires: 00:02:39

Selective RP Mappings and Multiple RPs

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.

#R6
ip access-list standard RP_GROUP_ACL
 permit 239.0.0.0 0.255.255.255
!
ip pim send-rp-announce lo0 scope 255 group-list RP_GROUP_ACL

#R1
int lo0
 ip pim sparse-mode
!
ip access-list standard RP_GROUP_ACL
 permit 239.0.0.0 0.255.255.255
!
ip pim send-rp-announce lo0 scope 255 group-list RP_GROUP_ACL

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.

R2#show ip pim rp mapping 
PIM Group-to-RP Mappings
This system is an RP-mapping agent (Loopback0)

Group(s) 239.0.0.0/8
  RP 6.6.6.6 (?), v2v1
    Info source: 6.6.6.6 (?), elected via Auto-RP
         Uptime: 00:02:37, expires: 00:02:18
  RP 1.1.1.1 (?), v2v1
    Info source: 1.1.1.1 (?), via Auto-RP
         Uptime: 00:01:35, expires: 00:02:20

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.

R4#sho ip pim rp map
PIM Group-to-RP Mappings

Group(s) 239.0.0.0/8
  RP 6.6.6.6 (?), v2v1
    Info source: 2.2.2.2 (?), elected via Auto-RP
         Uptime: 00:04:05, expires: 00:02:48

BSR (Bootstrap Router)

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

BSR Lab

Let’s see BSR in action. Remove all Auto-RP configuration from R1, R2, and R6.

#R1
no ip pim send-rp-announce Loopback0 scope 255 group-list RP_GROUP_ACL

#R2
no ip pim send-rp-discovery Loopback0 scope 255

#R6
no ip pim send-rp-announce Loopback0 scope 255 group-list RP_GROUP_ACL

Configure R2 to be a Candidate BSR:

#R2
ip pim bsr-candidate lo0

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:

R5#show ip pim bsr-router 
PIMv2 Bootstrap information
  BSR address: 2.2.2.2 (?)
  Uptime:      00:03:02, BSR Priority: 0, Hash mask length: 0
  Expires:     00:02:09

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.

#R1, R6
ip pim rp-candidate lo0 group-list RP_GROUP_ACL

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:

R5#show ip pim rp mapping 
PIM Group-to-RP Mappings

Group(s) 239.0.0.0/8
  RP 6.6.6.6 (?), v2
    Info source: 2.2.2.2 (?), via bootstrap, priority 0, holdtime 150
         Uptime: 00:01:19, expires: 00:01:37
  RP 1.1.1.1 (?), v2
    Info source: 2.2.2.2 (?), via bootstrap, priority 0, holdtime 150
         Uptime: 00:01:26, expires: 00:01:36

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.

BSR Hashing

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.

#R2
ip pim bsr-candidate lo0 30

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

R5#show ip pim rp-hash 239.0.0.0  
  RP 1.1.1.1 (?), v2
    Info source: 2.2.2.2 (?), via bootstrap, priority 0, holdtime 150
         Uptime: 00:22:22, expires: 00:01:37
  PIMv2 Hash Value (mask 255.255.255.252)
    RP 6.6.6.6, via bootstrap, priority 0, hash value 1004960524
    RP 1.1.1.1, via bootstrap, priority 0, hash value 1087452433

R5#show ip pim rp-hash 239.0.0.150
  RP 6.6.6.6 (?), v2
    Info source: 2.2.2.2 (?), via bootstrap, priority 0, holdtime 150
         Uptime: 00:22:16, expires: 00:01:35
  PIMv2 Hash Value (mask 255.255.255.252)
    RP 6.6.6.6, via bootstrap, priority 0, hash value 681586776
    RP 1.1.1.1, via bootstrap, priority 0, hash value 492543941

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.

Conclusion

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.

Further Reading

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipmulti_pim/configuration/imc-pim-xe-3e/imc_autorp.html

https://ine.com/blog/2009-04-07-understanding-bsr-protocol

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipmulti_pim/configuration/xe-16-5/imc-pim-xe-16-5-book/imc-basic-cfg.html#GUID-D1656247-AFA8-4F67-8114-FB290E579FDD

PreviousPIM DR and the Assert MessageNextPIM-BiDir

Last updated