RP Candidate Priority not working

RouterOS Forwarding Protocols
1

Hello, I am having a problem with RP-Candidate selection.
The selection of an RP from amongst several RP candidates does not follow a predictable criterion. I would have thought that the RP-Candidate PRIORITY field (lowest value being the highest priority) would be the primary selection method, but it seems this field value is completely ignored.

I am using OS7.12 but same issue still exists when updating to latest 7.16 release.

Note that the BSR candidate PRIORITY field (highest value is the highest priority) DOES work correctly in all my testing.

I have setup a lab environment for testing per below,
3 * RB3011 OS7.12
The RP candidate interface is a loopback adapter on each Mikrotik.
There are no firewall rules.
Routers were restarted after each configuration change.
The results are the same regardless of which router is selected as the BSR.
The results are the same regardless of where the multicast source comes from.
The results show that in all the tests, Mikrotik2 was selected as the RP

TEST1
Mikrotik1, RP Candidate ADDRESS 10.0.0.10%localhost, PRIORTY 10
Mikrotik2, RP Candidate ADDRESS 10.0.0.20%localhost, PRIORTY 20 - SELECTED AS RP
Mikrotik3, RP Candidate ADDRESS 10.0.0.30%localhost, PRIORTY 30

TEST2
Mikrotik1, RP Candidate ADDRESS 10.0.0.10%localhost, PRIORTY 10
Mikrotik2, RP Candidate ADDRESS 10.0.0.20%localhost, PRIORTY 30 - SELECTED AS RP
Mikrotik3, RP Candidate ADDRESS 10.0.0.30%localhost, PRIORTY 20

TEST3
Mikrotik1, RP Candidate ADDRESS 10.0.0.10%localhost, PRIORTY 20
Mikrotik2, RP Candidate ADDRESS 10.0.0.20%localhost, PRIORTY 30 - SELECTED AS RP
Mikrotik3, RP Candidate ADDRESS 10.0.0.30%localhost, PRIORTY 10

TEST4
Mikrotik1, RP Candidate ADDRESS 10.0.0.10%localhost, PRIORTY 20
Mikrotik2, RP Candidate ADDRESS 10.0.0.20%localhost, PRIORTY 10 - SELECTED AS RP
Mikrotik3, RP Candidate ADDRESS 10.0.0.30%localhost, PRIORTY 30

TEST5
Mikrotik1, RP Candidate ADDRESS 10.0.0.10%localhost, PRIORTY 30
Mikrotik2, RP Candidate ADDRESS 10.0.0.20%localhost, PRIORTY 10 - SELECTED AS RP
Mikrotik3, RP Candidate ADDRESS 10.0.0.30%localhost, PRIORTY 20

TEST6
Mikrotik1, RP Candidate ADDRESS 10.0.0.10%localhost, PRIORTY 30
Mikrotik2, RP Candidate ADDRESS 10.0.0.20%localhost, PRIORTY 20 - SELECTED AS RP
Mikrotik3, RP Candidate ADDRESS 10.0.0.30%localhost, PRIORTY 10

Any thoughts?

2

Bumpidy bump bump

Persisting on the forum for support on this as I’ve had no reply from Mikrotik support.

It would be great if some legend(s) could independently confirm my bug finding to bolster impetus for this issue.

3

More than a year later and this issue still persists.

Using 7.22beta5

There is still a problem with PIM-SM Rendezvous Point (RP) Candidate selection
The "Priority" field value is not used when electing the RP for a multicast group.
The results below are from three different tests, where the RP Candidate priority field value was changed each time.

[admin@SITE10] /routing/pimsm/bsr/rp-set> print
0 instance=pimsm-instance1 group=239.0.0.0/8
rp.address=10.5.0.1,10.5.0.2,10.5.0.3 .priority=10,20,30 .timeout=1m48s,1m48s,1m48s

[admin@SITE10] /routing/pimsm/bsr/rp-set> print
0 instance=pimsm-instance1 group=239.0.0.0/8
rp.address=10.5.0.1,10.5.0.2,10.5.0.3 .priority=20,30,10 .timeout=1m54s,1m54s,1m54s

[admin@SITE10] /routing/pimsm/bsr/rp-set> print
0 instance=pimsm-instance1 group=239.0.0.0/8
rp.address=10.5.0.1,10.5.0.2,10.5.0.3 .priority=30,10,20 .timeout=1m49s,1m49s,1m49s

For each test, the router with the IP address of 10.5.0.3 was always chosen as the RP, regardless of its RP Candidate priority.
When the router with the IP address of 10.5.0.3 has its RP Candidate disabled, the router with the IP address of 10.5.0.1 is then always chosen as the RP.
It just makes no sense as to how the RP is being elected.

This is reproducible 100% of the time.

A very frustrating issue that has been inhibiting RP redundancy for several of my customer sites for a long time . . .