Since IPv6 multicast doesn’t support the Auto-RP process like IPv4, there must be other methods for dynamically configuring a RP. The two options are using Bootstrap Router (BSR) and embedded RP. In this post, we will walk through BSR, step by step together.
For BSR to work, we need to have at least 1 candidate BSR router, and 1 candidate RP. For fault tolerance, we would want to have at least 2 of each. If a RP was on the network, but is powered down, I suppose that would make it a “Lost Candidate”.
To understand the process, let’s watch it in action. We will use the same diagram that we did in the previous blog post. (To see the details of the topology and an example of static RP, please visit the original post).
First, we will configure a couple routers as BSR candidates. The router that ends up as the BSR will listen for RP volunteers (candidate RPs), and let the rest of the network know which devices are the RPs. All of this is done directly through PIM messages, so no out of band control plane is required. Let’s set up R2 and R3 as BSR candidates. The one with the highest priority will be the winner of the BSR election. With BSR, a larger number for priority means a higher priority.
R2(config)#ipv6 pim bsr candidate bsr 2002:2222::2 priority 2 R2#show ipv6 pim bsr election PIMv2 BSR information BSR Election Information Scope Range List: ff00::/8 This system is the Bootstrap Router (BSR) BSR Address: 2002:2222::2 Uptime: 00:01:13, BSR Priority: 2, Hash mask length: 126 RPF: FE80::C002:13FF:FE08:0,Loopback0 BS Timer: 00:00:46 This system is candidate BSR Candidate BSR address: 2002:2222::2, priority: 2, hash mask length: 126 R3(config)#ipv6 pim bsr candidate bsr 2002:3333::3 priority 1 R3#show ipv6 pim bsr election PIMv2 BSR information BSR Election Information Scope Range List: ff00::/8 BSR Address: 2002:2222::2 Uptime: 00:00:08, BSR Priority: 2, Hash mask length: 126 RPF: FE80::244:44FF:FE44:4444,FastEthernet0/0 BS Timer: 00:02:01 This system is candidate BSR Candidate BSR address: 2002:3333::3, priority: 1, hash mask length: 126
Now we need some volunteers willing to be RPs. Let’s use R1 and R4. For candidate RP, the priority is backwards from that of the BSR. With RP candidates, lower is better. Notice below, that the PIM Tunnels are built, indicating that R1 has been mapped as the RP by the BSR, and R1 learned about the mapping via PIM.
R1(config)#ipv6 pim bsr candidate rp 2002:1111::1 priority 2 %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel2, changed state to up R1# R1#show ipv6 pim tunnel Tunnel0* Type : PIM Encap RP : Embedded RP Tunnel Source: 2002:12::1 Tunnel1* Type : PIM Encap RP : 2002:1111::1* Source: 2002:12::1 Tunnel2* Type : PIM Decap RP : 2002:1111::1* Source: - R1#show ipv6 pim bsr candidate-rp PIMv2 C-RP information Candidate RP: 2002:1111::1 SM All Learnt Scoped Zones, Priority 2, Holdtime 150 Advertisement interval 60 seconds Next advertisement in 00:00:38
Now lets assign R4 as a candidate RP. Notice no PIM tunnels are built, as the priority is not as good for R4, and it is not currently being used as an RP. If R1 fails, then R4 would be used.
R4(config)#ipv6 pim bsr candidate rp 2002:4444::4 priority 3 R4#show ipv6 pim bsr candidate-rp PIMv2 C-RP information Candidate RP: 2002:4444::4 SM All Learnt Scoped Zones, Priority 3, Holdtime 150 Advertisement interval 60 seconds Next advertisement in 00:00:21
Lets take a look at this from a couple different locations in the network. On the current BSR (R2), we can see all the candidate RPs.
R2#show ipv6 pim bsr rp-cache PIMv2 BSR C-RP Cache BSR Candidate RP Cache Group(s) FF00::/8, RP count 2 RP 2002:1111::1 SM Priority 2, Holdtime 150 Uptime: 00:05:46, expires: 00:01:44 RP 2002:4444::4 SM Priority 3, Holdtime 150 Uptime: 00:05:32, expires: 00:01:58
From R6, who is not a BSR nor a RP candidate, we can see who the RP currently is. (Just to verify that the BSR is correctly advertising the mapping).
R6#show ipv6 pim group-map ff00::/8 IP PIM Group Mapping Table (* indicates group mappings being used) FF00::/8* SM, RP: 2002:1111::1 RPF: Fa0/1,FE80::211:11FF:FE11:1111 Info source: BSR From: 2002:2222::2(00:02:00), Priority: 2 Uptime: 00:07:45, Groups: 0 FF00::/8 SM, RP: 2002:4444::4 RPF: ,:: Info source: BSR From: 2002:2222::2(00:02:00), Priority: 3 Uptime: 00:07:31, Groups: 0 FF00::/8 SM Info source: Default Uptime: 00:24:03, Groups: 0
To test this, we can have R3 join a group in the FF08::/8 range, and then simulate a mcast server, by pinging that group, (let’s do the ping from R2). If all goes well, the RP of R1 will be used to start the shared tree, and then a shortest path tree will be built between the listener (R3) and the content server (R2). The replies will be unicast from R3 to R2.
R3(config-if)#ipv6 mld join-group FF08:AAAA::1 R3#show ipv6 mld groups MLD Connected Group Membership Group Address Interface Uptime Expires FF08:AAAA::1 Loopback0 00:00:26 never R2#ping ff08:aaaa::1 Output Interface: fastethernet0/0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to FF08:AAAA::1, timeout is 2 seconds: Packet sent with a source address of 2002:12::2 Reply to request 0 received from 2002:3333::3, 208 ms Reply to request 1 received from 2002:3333::3, 188 ms Reply to request 2 received from 2002:3333::3, 216 ms Reply to request 3 received from 2002:3333::3, 224 ms Reply to request 4 received from 2002:3333::3, 224 ms Success rate is 100 percent (5/5), round-trip min/avg/max = 188/212/224 ms 5 multicast replies and 0 errors.
If we look at a device in the transit path, such as R5, we can verify the multicast routing information.
R5#show ipv6 mroute Multicast Routing Table Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected, L - Local, I - Received Source Specific Host Report, P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT Timers: Uptime/Expires Interface state: Interface, State (*, FF08:AAAA::1), 00:04:00/00:03:28, RP 2002:1111::1, flags: S Incoming interface: FastEthernet0/0 RPF nbr: FE80::266:66FF:FE66:6666 Immediate Outgoing interface list: FastEthernet0/1, Forward, 00:04:00/00:03:28 (2002:12::2, FF08:AAAA::1), 00:01:58/00:03:28, flags: ST Incoming interface: FastEthernet0/0 RPF nbr: FE80::266:66FF:FE66:6666 Immediate Outgoing interface list: FastEthernet0/1, Forward, 00:01:58/00:03:28 R5#show ipv6 mfib ff08:aaaa::1 IP Multicast Forwarding Information Base Entry Flags: C - Directly Connected, S - Signal, IA - Inherit A flag, AR - Activity Required, K - Keepalive Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kbits per second Other counts: Total/RPF failed/Other drops Interface Flags: A - Accept, F - Forward, NS - Negate Signalling IC - Internal Copy, NP - Not platform switched SP - Signal Present Interface Counts: FS Pkt Count/PS Pkt Count (*,FF08:AAAA::1) Flags: C Forwarding: 1/0/100/0, Other: 0/0/0 FastEthernet0/0 Flags: A FastEthernet0/1 Flags: F NS Pkts: 0/1 (2002:12::2,FF08:AAAA::1) Flags: Forwarding: 14/0/100/0, Other: 0/0/0 FastEthernet0/0 Flags: A FastEthernet0/1 Flags: F NS Pkts: 0/14 R5#show ipv6 pim topology IP PIM Multicast Topology Table Entry state: (*/S,G)[RPT/SPT] Protocol Uptime Info Entry flags: KAT - Keep Alive Timer, AA - Assume Alive, PA - Probe Alive, RA - Really Alive, LH - Last Hop, DSS - Don't Signal Sources, RR - Register Received, SR - Sending Registers, E - MSDP External, DCC - Don't Check Connected Interface state: Name, Uptime, Fwd, Info Interface flags: LI - Local Interest, LD - Local Disinterest, II - Internal Interest, ID - Internal Disinterest, LH - Last Hop, AS - Assert, AB - Admin Boundary (*,FF08:AAAA::1) SM UP: 00:06:21 JP: Join(00:00:28) Flags: RP: 2002:1111::1 RPF: FastEthernet0/0,FE80::266:66FF:FE66:6666 FastEthernet0/1 00:06:21 fwd Join(00:03:06) (2002:12::2,FF08:AAAA::1) SM SPT UP: 00:04:19 JP: Join(00:00:28) Flags: RPF: FastEthernet0/0,FE80::266:66FF:FE66:6666 FastEthernet0/1 00:04:19 fwd Join(00:03:06) R5#
Thanks for reading!
I will include embedded RP in a separate blog post for you.
Best wishes, and keep up the dedicated studies. It is worth it.
4 Responses to “BSR IPv6 Multicast, are you a candidate?”
Leave a Reply