In this first demo,
we're going to configure basic PIM neighbors between two routers and then
debug the exchange so that we can understand the process.
We'll start with the last‑hop router, or LHR, for short.
This is the multicast router that's attached to the receiver segment.
There might be LHRs in the network or just one depending
on where the receivers are connected.
In our basic topology, there will only be one LHR.
The next hop in the topology will be a multicast router.
This router has no special role or designation.
It simply routes multicast traffic and tracks
multicast state through its interfaces.
We could say that this router is an upstream multicast
router from the point of view of the LHR as it is closer to
the source of multicast traffic.
Remember that every multicast router uses its Unicast routing
table to determine the best path upstream towards the source and
IGMP or MLD reports or PIM joins to determine its downstream
interfaces towards the receivers.
Here we are on the command‑line interface of the LHR router.
This is a Cisco router,
but the commands and output will be similar between other vendors.
At this point, the LHR is not configured for multicast routing.
We'll enable that first and then PIM on the interface
facing the upstream multicast router.
I'm using Cisco routers in this course,
but not all platforms and vendors have the same commands.
I don't want to focus as much on specific commands
as I do on the process itself.
So please refer to the relevant documentation for
your specific use cases and vendors.
If I were doing this for an IPv6 implementation,
the command is very similar, but it is a separate command entirely.
When we get to IPv6‑specific multicast solutions, I'll cover it more in detail.
The next step in configuring PIM neighbors is to enable PIM on the specific
interfaces on which we expect to use for multicast forwarding.
But before we do that, let's set up a debug so we can see the output.
Okay,
now we will be able to see some output when PIM neighbors
come up; time to build that PIM adjacency.
Because we're tackling PIM dense mode first,
will use PIM dense mode in this example.
We received a lot of output here.
I'll turn off the debug so we can focus on it without continuous updates.
As you can see, when we turn on PIM,
we send an immediate triggered Hello out of the interface and
receive a Hello in return from our neighbor.
In the interest of brevity, the upstream router is already configured for PIM.
The next step after Hello exchange is to bring up the PIM adjacency,
followed by the designated router election.
For each multi‑access segment, a DR must be elected.
We'll cover DR in the next video, so I won't go into details here.
After DR is elected,
we transition to an upkeep phase where periodic Hellos
are exchanged between neighbors.
We can also see that the Hellos contains something called a
GenID. We'll explore the GenID more when we analyze the packet
captures, but think of it as an indicator of whether or not a
router has been recently rebooted.
If routers reboot,
they lose the multicast state information, and that's impactful to
forwarding. PIM neighbors use the GenID to detect whether a neighbor has
rebooted and might need triggered state refresh instead of waiting for timers to refresh the state information.