We're going to be spending some time with PIM sparse mode,
and I'll be demonstrating all the pieces needed to get it working.
There are several ways to configure a rendezvous point.
We could do it statically per router,
use an old Cisco proprietary method called Auto RP,
or we could use the PIM standard method,
which is called bootstrap router.
Since this is a deep dive on PIM,
let's focus on the method built into the PIM standard.
In this demo,
we'll configure a bootstrap router and use native PIM Hellos to
share the BSR address with other PIM routers.
We'll dynamically elect an RP and then use PIM bootstrap
messages to advertise the RP dynamically.
Remember that every multicast router must agree on what is the IP of the RP
as both sources and receivers will be forwarded there.
In a large network, the process of selecting,
configuring, and changing RPs could be an unwieldy task.
PIM gives us the tools to do this dynamically with the minimum of configuration.
In our topology, MCAST 2 will serve at the bootstrap router.
The BSR is not an RP, though the same router could perform both duties.
The BSR instead serves as an endpoint for any RP
candidates to advertise their candidacy.
The BSR advertises itself through PIM Hellos,
which are exchanged throughout the PIM domain.
In this way,
any router we want to serve the function of RP will learn of the
BSR's existence and can Unicast message the BSR about itself, what
groups it will serve, and its priority.
The BSR's job is to collect all the candidate advertisements,
elect the functioning RP,
and then advertise that winner throughout the PIM
domain using the PIM bootstrap messages.
The best part of using this method is there's no multicast flooding
required to elect and dynamically learn the RP,
unlike the Cisco proprietary auto RP method.
The BSR is learned by PIM Hellos,
the candidate RP advertisements are Unicast to the IP of the BSR,
and the bootstrap router advertises the winner through PIM bootstrap messages.
Hypothetically,
we could have multiple BSRs with different priority for redundancy purposes and
then configure multiple candidate RPs for the same reason.
In our lab, we'll stick with one of each for simplicity.
MCAST 1 will serve as our candidate RP, and MCAST 2 will be the BSR.
No other router will have any RP configuration,
but will learn the RP address dynamically.
First up is MCAST 2.
Let's add the BSR configuration and then check on MCAST 1 to see if
it learned the BSR router through PIM Hellos.
Before we make MCAST 2 a BSR candidate,
we should turn on some debugs to capture the BSR processed.
We use the loopback interface for high availability,
just making sure it's injected into the routing protocol for reachability.
The debug shows that MCAST 2 has originated a BSR message to other routers.
We can check to make sure the router knows it's a BSR with this command.
This system is the bootstrap router; that means it will be the router
collecting candidate RP advertisements and selecting the RP and then
advertising to all the other PIM routers.
Now over to MCAST 1 to make it an RP candidate.
Before we set up MCAST 1 as the RP, let's turn on some debugs here too.
We can see that the bootstrap advertisements are
coming in on multiple interfaces,
but that the ones on the non‑reverse‑path‑forwarding interfaces are discarded.
Let's configure MCAST 1 as the RP now.
Again, in this case, we use loopback for redundancy,
and we just have to make sure that it's reachable by the other routers.
Notice, we didn't have to set the router itself as the RP.
Using BSR,
all routers wait to learn the winner of the RP election
and then set themselves dynamically.
MCAST 1 advertised to the BSR that it could serve as the RP for 224.0.0.0/4,
which is the entire multicast address range.
We now see to PIM tunnels come up, one for the router and one for the RP itself.
Recall that PIM tunnels are used to register multicast
sources with the RP before an outgoing interface list has
been created from the first‑hop router.
We can turn off debugs now and check to see that MCAST 1 is the RP. MCAST 1
is the RP for all groups; it's being learned via 2.2.2.2,
which is the IP of the bootstrap router; the Priority is 0 because we
didn't set on; the Uptime shows how long it's been selected as the RP;
and if no new RP advertisements come from the BSR, the dynamically
selected RP will expire. One last thing, let's check another router in
the topology and make sure it agrees. Just like the RP itself, the LHR
shows it's using MCAST 1 as the RP, learned via bootstrap from MCAST 2.
We can quickly check the configuration of the PIM tunnel.
All right, this looks good.
The PIM tunnel shows that the source is the closest RPF interface to the RP and that the destination is the IP address of the RP itself.