November 26th, 2007 neteng
Welcome back everyone. I hope you guys were smart enough to avoid following my lead this past weekend and not stuff yourself silly. I’m growing feathers from all the turkey I ate! But I digress…We’re back in action for awhile and I hope to have some good material coming your way.
Let’s begin where we left off and take a look at our common PIM network. We’ve seen static RP assignments and Auto-RP at work, so now we’ll take a look at BSR. It’s really not very complicated if you’re familiar with Auto-RP and you’ll see what I mean as we go through the configuration. The BSR router plays a similar role to the Auto-RP Mapping Agent, but it performs one major function differently. The Auto-RP MA elects an RP based on the announcements it receives from candidate-RPs (C-RP). The BSR router actually sends all mapping possibilities to every PIM router and allows them to elect an RP. They will elect the same RPs for each group though, as every PIM router uses the same hash algorithm.

First, we’ll configure R3 to be our C-RP:
R3#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#ip pim rp-candidate lo0
Now let’s verify:
R3#sh ip pim rp map
PIM Group-to-RP Mappings
This system is a candidate RP (v2)
Next, let’s configure R2 to be our BSR:
R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#ip pim bsr-candidate lo0
Let’s verify that everything is working as it should be now:
R2#sh ip pim rp map
PIM Group-to-RP Mappings
This system is the Bootstrap Router (v2)
Group(s) 224.0.0.0/4
RP 150.1.3.3 (?), v2
Info source: 192.168.23.3 (?), via bootstrap, priority 0, holdtime 150
Uptime: 00:00:54, expires: 00:01:33
You can see that R3 has been selected as the RP for all multicast groups. Now we’ll ping from our R1 multicast source to R6 and see what happens:
R1#ping 239.39.39.39
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.39.39.39, timeout is 2 seconds:
Reply to request 0 from 192.168.56.6, 452 ms
You can see that R5 is using R3 as it’s RP. This was learned as the BSR sent the announcement to each PIM router (224.0.0.13), and each PIM router forwarded this announcement to it’s neighbors at the same address. Let’s take a look:
R5#sh ip pim rp map
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/4
RP 150.1.3.3 (?), v2
Info source: 150.1.2.2 (?),via bootstrap, priority 0, holdtime 150
Uptime: 00:06:41, expires: 00:02:01
Here’s our mroute table on R5:
R5#sh ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.39.39.39), 01:29:37/stopped, RP 150.1.3.3, flags: SJC
Incoming interface: FastEthernet0/0, RPF nbr 192.168.35.3
Outgoing interface list:
FastEthernet1/1, Forward/Sparse, 01:29:37/00:02:31
(192.168.12.1, 239.39.39.39), 00:02:56/00:00:10, flags: JT
Incoming interface: FastEthernet0/0, RPF nbr 192.168.35.3
Outgoing interface list:
FastEthernet1/1, Forward/Sparse, 00:02:56/00:02:31
(*, 224.0.1.40), 01:30:15/00:02:27, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Loopback0, Forward/Sparse, 01:30:15/00:02:27
As far as basic BSR setup, that’s all there is to it! If you have multiple BSRs, the one with the highest priority will be elected. If they all have the default Cisco priority of 0, then the BSR candidate with the highest IP address will be chosen. If you have multiple RP candidates seeking election, then the BSR will also elect the RP based on the same priority/IP address system.
I hope you’ve found this series of PIM labs useful. I haven’t quite decided what to tackle next, but have some ideas in mind. Suggestions are always welcome! In the meantime though, expect to see a review of CCNA/CCNP training materials provided by our friends at TrainSignal.
neteng
Buy Me a Beer! Help me keep my sanity as I write more articles.
Posted in HOWTO, Multicast, Networking, Routing | 1 Comment »