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.
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: 126Now 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:38Now 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:21Lets 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:58From 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: 0To 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!
0 comments:
Post a Comment