Thank you Bell, I just fixed this.
Rene
Hey ReneMolenaar,
Just a correction on this post. But with BSR, the RP priority, lowest is preferred. I labbed it up, got confused with what I was seeing and then confirmed it that lowest priority is preferred and wins the RP election.
Regards - Tony Ellis
Hi Tony Ellis,
I just made some changes, you are right this is confusing. In RFC5059 they state it like this:
BSR Priority
Contains the BSR priority value of the included BSR. This field
is considered as a high-order byte when comparing BSR addresses.
BSRs should by default set this field to 64. Note that for
historical reasons, the highest BSR priority is 255 (the higher
the better), whereas the highest RP Priority (see below) is 0
(the lower the better).
They talk about highest priority for BSR and RP selection, but for BSR highest priority means the highest value (255) and for RP, it means lowest value (0).
Rene
1 Like
Hi Rene
I have a confusion. You mentioned in your post âWe have two RPs with the same priority, both want to become the RP for the entire 239.0.0.0/8 multicast range.â
Q1. If the group is 239.1.1.1 then why would they want to become RP for entire 239.0.0.0/8, wouldnât it be that they want to become RP for 239.1.1.1?
Q2. How will the RP know that they have to be RP for a particular group, when we mention ip pim rp-candidate we never specify any group there ?
Hello Vikrant
Concerning question 1, the statement âboth want to become the RP for the entire multicast rangeâ, essentially means that when you have two routers that have the same priority, initially, each one wants to be the RP for all of the multicast ranges that have been configured. In other words, for any and every group, each router wants to be the RP.
Concerning question 2, the command ip pim rp-candidate simply enables the router to become a candidate, that is, to become eligible to become an RP. It does not map particular multicast ranges to a particular RP. All routers with this command participate in the hash function. It is the hash function that is used to map the specific multicast group addresses to particular RPs.
I hope this has been helpful!
Laz
Hello every one
Q1: How can apply the PIM sparse mode with BSR in this Scenario
Q2: I Know that safe IP address for multicast group that I can use it from 239.0.0.0 -239.255.255.255
but I want to ask if multicast address its depend on streaming app or server that I use or not ?
Hello Ammar
I suggest you take a look at this lesson and see an example how BSR with PIM sparse mode is configured on a topology.
Once you review, let us know if you have more specific questions.
As for your section question, the multicast IP addresses that are used in each case do depend on the implementation of the service that is being provided. Some vendors use specific addresses within the range, others may use random addresses. But there are some multicast addresses that are reserved and should never be used.
I hope this has been helpful!
Laz
I read it and I understand it also, but how I joined tv receiver to the multicast group because in the lesson was used router as host
Hello Ammar
Any host (either multicast source or receiver) that is connected to a network that is required to function using multicast should simply be connected to any network of any of the multicast routers found within the topology. It is true that in the lessons, Rene often uses routers as hosts, but for your purposes, you can simply replace the router with your host in your topology.
I hope this has been helpful!
Laz
Hi Rene,
can we configure more than one mapping agent Router in Auto-RP in same network for redundancy and high availability reasons ? and if yes how the election and selection for the mapping agent will be? is it same as BSR idea?
Hello Ziad
You can configure redundancy using Auto-RP. You simply have to have multiple candidate RPs and multiple mapping agents. At any given time, only one RP address is active, either per multicast group to share the load, or for all groups. If the active RP fails, it may take up to three minutes for the other candidate RP to take over. But donât forget to include multiple mapping agents, because even if you have more than one candidate, if the mapping agent fails, it is a single point of failure and you donât achieve the redundancy you desire.
The same logic can be applied to BSR, with its candidate BSRs and candidate RPs.
I hope this has been helpful!
Laz
Hello Gowthamraj
Yes, it should be pim and not bim, thanks for pointing that out! Iâll let Rene know to fix that.
Laz
1 Like
Hi,
i have two RP and BSR candidate i configure hash mask as 31 bit. for what bases multicast group address are map to RP. i am getting confused check below output.
R1#show ip pim rp-hash 239.1.1.0
RP 1.1.1.1 (?), v2
Info source: 2.2.2.2 (?), via bootstrap, priority 0, holdtime 150
Uptime: 00:09:03, expires: 00:01:57
PIMv2 Hash Value (mask 255.255.255.254)
RP 4.4.4.4, via bootstrap, priority 0, hash value 192087346
RP 1.1.1.1, via bootstrap, priority 0, hash value 1415431185
R1#show ip pim rp-hash 239.1.1.1
RP 1.1.1.1 (?), v2
Info source: 2.2.2.2 (?), via bootstrap, priority 0, holdtime 150
Uptime: 00:09:06, expires: 00:01:54
PIMv2 Hash Value (mask 255.255.255.254)
RP 4.4.4.4, via bootstrap, priority 0, hash value 192087346
RP 1.1.1.1, via bootstrap, priority 0, hash value 1415431185
R1#show ip pim rp-hash 239.1.1.2
RP 4.4.4.4 (?), v2
Info source: 2.2.2.2 (?), via bootstrap, priority 0, holdtime 150
Uptime: 00:05:40, expires: 00:01:48
PIMv2 Hash Value (mask 255.255.255.254)
RP 4.4.4.4, via bootstrap, priority 0, hash value 724279812
RP 1.1.1.1, via bootstrap, priority 0, hash value 52024035
R1#show ip pim rp-hash 239.1.1.3
RP 4.4.4.4 (?), v2
Info source: 2.2.2.2 (?), via bootstrap, priority 0, holdtime 150
Uptime: 00:05:42, expires: 00:01:46
PIMv2 Hash Value (mask 255.255.255.254)
RP 4.4.4.4, via bootstrap, priority 0, hash value 724279812
RP 1.1.1.1, via bootstrap, priority 0, hash value 52024035
R1#show ip pim rp-hash 239.1.1.4
RP 1.1.1.1 (?), v2
Info source: 2.2.2.2 (?), via bootstrap, priority 0, holdtime 150
Uptime: 00:09:13, expires: 00:01:47
PIMv2 Hash Value (mask 255.255.255.254)
RP 4.4.4.4, via bootstrap, priority 0, hash value 342031214
RP 1.1.1.1, via bootstrap, priority 0, hash value 1650395061
R1#show ip pim rp-hash 239.1.1.5
RP 1.1.1.1 (?), v2
Info source: 2.2.2.2 (?), via bootstrap, priority 0, holdtime 150
Uptime: 00:09:17, expires: 00:01:43
PIMv2 Hash Value (mask 255.255.255.254)
RP 4.4.4.4, via bootstrap, priority 0, hash value 342031214
RP 1.1.1.1, via bootstrap, priority 0, hash value 1650395061
R1#show ip pim rp-hash 239.1.1.6
RP 1.1.1.1 (?), v2
Info source: 2.2.2.2 (?), via bootstrap, priority 0, holdtime 150
Uptime: 00:09:22, expires: 00:01:38
PIMv2 Hash Value (mask 255.255.255.254)
RP 4.4.4.4, via bootstrap, priority 0, hash value 662935616
RP 1.1.1.1, via bootstrap, priority 0, hash value 1043161735
R1#show ip pim rp-hash 239.1.1.7
RP 1.1.1.1 (?), v2
Info source: 2.2.2.2 (?), via bootstrap, priority 0, holdtime 150
Uptime: 00:09:25, expires: 00:01:35
PIMv2 Hash Value (mask 255.255.255.254)
RP 4.4.4.4, via bootstrap, priority 0, hash value 662935616
RP 1.1.1.1, via bootstrap, priority 0, hash value 1043161735
R1#show ip pim rp-hash 239.1.1.8
RP 4.4.4.4 (?), v2
Info source: 2.2.2.2 (?), via bootstrap, priority 0, holdtime 150
Uptime: 00:06:28, expires: 00:02:00
PIMv2 Hash Value (mask 255.255.255.254)
RP 4.4.4.4, via bootstrap, priority 0, hash value 1603485818
RP 1.1.1.1, via bootstrap, priority 0, hash value 317288793
R1#show ip pim rp-hash 239.1.1.9
RP 4.4.4.4 (?), v2
Info source: 2.2.2.2 (?), via bootstrap, priority 0, holdtime 150
Uptime: 00:06:43, expires: 00:01:45
PIMv2 Hash Value (mask 255.255.255.254)
RP 4.4.4.4, via bootstrap, priority 0, hash value 1603485818
RP 1.1.1.1, via bootstrap, priority 0, hash value 317288793
R1#show ip pim rp-hash 239.1.1.10
RP 4.4.4.4 (?), v2
Info source: 2.2.2.2 (?), via bootstrap, priority 0, holdtime 150
Uptime: 00:06:47, expires: 00:01:41
PIMv2 Hash Value (mask 255.255.255.254)
RP 4.4.4.4, via bootstrap, priority 0, hash value 231542092
RP 1.1.1.1, via bootstrap, priority 0, hash value 194104363
R1#show ip pim rp-hash 239.1.1.11
RP 4.4.4.4 (?), v2
Info source: 2.2.2.2 (?), via bootstrap, priority 0, holdtime 150
Uptime: 00:06:51, expires: 00:01:37
PIMv2 Hash Value (mask 255.255.255.254)
RP 4.4.4.4, via bootstrap, priority 0, hash value 231542092
RP 1.1.1.1, via bootstrap, priority 0, hash value 194104363
R1#show ip pim rp-hash 239.1.1.12
RP 4.4.4.4 (?), v2
Info source: 2.2.2.2 (?), via bootstrap, priority 0, holdtime 150
Uptime: 00:07:01, expires: 00:01:27
PIMv2 Hash Value (mask 255.255.255.254)
RP 4.4.4.4, via bootstrap, priority 0, hash value 1542141622
RP 1.1.1.1, via bootstrap, priority 0, hash value 10083069
R1#show ip pim rp-hash 239.1.1.13
RP 4.4.4.4 (?), v2
Info source: 2.2.2.2 (?), via bootstrap, priority 0, holdtime 150
Uptime: 00:07:05, expires: 00:02:27
PIMv2 Hash Value (mask 255.255.255.254)
RP 4.4.4.4, via bootstrap, priority 0, hash value 1542141622
RP 1.1.1.1, via bootstrap, priority 0, hash value 10083069
R1#show ip pim rp-hash 239.1.1.14
RP 1.1.1.1 (?), v2
Info source: 2.2.2.2 (?), via bootstrap, priority 0, holdtime 150
Uptime: 00:10:36, expires: 00:02:22
PIMv2 Hash Value (mask 255.255.255.254)
RP 4.4.4.4, via bootstrap, priority 0, hash value 170197896
RP 1.1.1.1, via bootstrap, priority 0, hash value 1396848079Hello Gowthamraj
Rene explains the Hash function clearly in section 3.1 Hash Function of the lesson.
The hash function takes as input the multicast group address, the IP address of the RP, and a hash mask value. For example, in the case of the group address 239.1.1.1, we have:
- G = 239.1.1.1
- M = 31, as per your post
- IP address of the RP, which in one case is 4.4.4.4, and in the other it is 1.1.1.1.
This hash function is run for both candidate RPs, and it comes with a result of:
- 192087346 for candidate RP 4.4.4.4
- 1415431185 for candidate RP 1.1.1.1
Since the value for 1.1.1.1 is larger, then 1.1.1.1 becomes the RP for group 239.1.1.1.
If you look at the same calculations for the group address of 239.1.1.2, the hash value for RP 4.4.4.4 is larger, so 4.4.4.4 is used as the RP.
So for each group address, one candidate RP is chosen as the RP. If this calculation is reproduced by other routers in the topology, you get the same result, as long as the configured hash mask is the same on all routers.
I hope this has been helpful!
Laz
Excellent lesson. Thanks Rene.
1 Like
Hi,
I get how the hash mask works when it is applied to different G addresses and hashed against RPs IP, producing different results. But is there not a possibility that the hashes could be higher for the same router for different Gâs , thereby resulting in no RP load balancing?
For example, in your reply above, the hash of 239.1.1.2 could have resulted in 1.1.1.1 returning a higher hash than 4.4.4.4, meaning 1.1.1.1 could have been used again. I know it didnât, but in a similar situation, could it have happened? If so, does that mean load balancing is not guaranteed to be evenly distributed?
Hello Samir
Yes, you are correct. The hash function does not guarantee perfect load balancing between RPs. However, it does provide a level of load balancing that, in most cases, is sufficient. The hash is random enough so that, statistically, there will be some satisfactory load distribution across multiple RPs.
I hope this has been helpful!
Laz
1 Like
Hi Rene,
In your video (at around 8:00) you mentioned getting back the output of âsh ip pim bsr-routerâ is slow.
Here the IOS is waiting for IP to name resolution. The question mark in the output denotes no resolution cold be made.
Fix:
- no ip domain-lookup
- add IP hosts to config
R3(config)#ip host R1_Lo0 1.1.1.1
R3(config)#ip host R2_Lo0 2.2.2.2
R3(config)#end
R3#sh ip pim rp mapping
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/4
RP 1.1.1.1 (R1_Lo0), v2v1
Info source: 2.2.2.2 (R2_Lo0), elected via Auto-RP <<<<<<<<<<
Uptime: 00:41:24, expires: 00:02:02