PIM-SM with BSR for IPv6
Load multicast.init.cfg
Configure R9 and XR4 as RPs for all IPv6 groups using BSR.
Both R9 and XR4 should be BSRs as well.
R9 should be the preferred BSR and Candidate RP.
Answer
Explanation
BSR for IPv6 works very much the same as BSR for IPv4. There is a minor difference with the default priority values for IOS-XE, though. IOS-XE conforms to the RFC standard and uses priority 192 for the C-RP advertisement.
Just like for IPv4 BSR, IOS-XE uses a default BSR priority value of 0, and IOS-XE uses a default BSR priority value of 1. For this reason, we specify priority value 2 on R9 so that it will be the elected BSR.
On R9 we can see that it has won the BSR election and that it has an RP-cache consisting of both 2001::9 and 2001::14 for ff00::/8.
On any other router, the “show ipv6 pim bsr rp-cache” command will show nothing. This is only useful on the BSR itself. However, we can see the IPv6 PIM RP mapping using the following command.
Using the command show ipv6 pim group-map <group address> we can see which RP wins the election. When the priories tie, the hash mask length is used just like with IPv4 BSR. We can see the hash mask length value using show ipv6 pim bsr election. This is 126 by default.
Strangely, I can never get 2001::14 to be used.
Similar commands can be used on IOS-XR. Interestingly, I can get XR3 to use XR4 as an RP for some groups. This appears to be a bug in IOS-XE.
Failover Considerations
Failover does not appear to be as robust with IPv6 PIM. When I shutdown Lo0 on R9, I don’t see automatic failover on all other routers. In fact, R9 continues caching itself as C-RP in show ipv6 pim bsr rp-cache output. R9 stops sending BSR messages so its boot strap messages eventually time out on all other routers, and all routers are left with no RPs at all. Next, XR4 elects itself as BSR and floods its RP mapping with only itself as C-RP. Other downstream routers learn this. But there was a period of time when some routers had no RP information at all in my lab.
Last updated
