PIM Sparse‑Mode hasn't fundamentally changed in IPv6,
so what we've learned already will save us some time.
When creating the IPv6 content,
I needed to strike a balance between viewers who started with PIM Sparse‑Mode
for IPv4 and those who may be primarily interested in IPv6.
I hope I've struck a good balance.
My suggestion is to watch the recap here and pay attention to what's new in v6.
If that's enough, move on.
And if not, please watch the IPv4 content where I go much more in depth.
In this module,
we'll cover the following: a quick recap of how any source
multicast works and then what's new in IPv6.
Specifically, we'll talk about multicast scoping and the embedded RP feature.
There will be demonstrations of building multicast flows in IPv6 ASM and
we'll see how the embedded RP works on the command line.
Finishing the module will be packet analysis of the familiar PIM ASM packets,
the Hello, Register and Register Stop, Join/Prune.
None of this is fundamentally different than IPv4,
but we'll cover them for the viewers who may only be interested in IPv6.
Globomantics is testing an IPv6 network in its lab and
wants to roll in multicast testing as well.
The goal is to test each implementation of PIM
supported in IPv6 to ensure functionality,
starting with sparse mode as dense mode is not supported in IPv6.
Our lab network mimics a production deployment down to the
placement of our rendezvous point and bootstrap router.
Rather than rehash every detail of any source multicast,
I'm going to spend a little time recapping the basic functionality
we've already learned and then we'll see what enhancements and
considerations are important for IPv6.
I want to take this moment to suggest that if you
haven't spent time with IPv6 before now,
refer to the beginning of this course where I mention a
great pluralsight IPv6 course to start.
I'm not going to spend a lot of time explaining IPv6
itself except as it pertains to PIM.
With PIM Sparse‑Mode,
the ever‑present problem is how to pair sources and
receivers without flooding multicast everywhere.
We need a central location where source traffic can be registered
and where interested receivers can find them.
The rendezvous point is where all sources will register their streams
and where all any source PIM Joins will be forwarded.
Because of this, all routers need to agree on the RP address.
The challenge of configuring an RP address is whether it can be
done dynamically or via some other method.
IPv6 uniquely supports a way to send an RP via the multicast group,
and this is called embedded RP.
We'll look at that option a little later.
For this setup,
let's assume we're using bootstrap router as it is
the standard using PIM protocol.
In our topology, MCAST2 will serve as the bootstrap router.
Remember that the BSR serves to collect advertisements from candidate
RPs who want to serve as the RP for multicast groups.
It then elects a winner and advertises the winner to every
other PIM router using native PIM messaging.
In this way, every router can learn about an RP dynamically.
On the source side, nothing is changed by transitioning to IPv6.
Though we are using IPv6 addressing,
the source must still register its stream with the rendezvous point.
In PIM Sparse‑Mode,
each PIM router creates a unicast PIM tunnel to the RP when the RP is defined.
For the router serving as the RP, it creates the tunnel endpoint.
This is important because per the rules of multicast,
a multicast stream can only be forwarded according
to an outgoing interface list.
The first hop router will have an empty list.
In the case of a PIM Register,
the FHR sends a PIM Register message to the RP and
then begins sending the stream to it, encapsulated in a PIM unicast tunnel.
The source of the FHR's PIM tunnel is the best
unicast interface to reach the RP,
and the RP's tunnel source is whatever local interface is configured with the
IP of the rendezvous point that every other router is using.
If the RP has not received any PIM Joins for any
interested receivers to that multicast group.
It responds to the PIM Register with a PIM Register Stop message.
This sets a timer on the RP and the first hop router to wait a while
before continuing to send traffic over the PIM tunnel.
When the RP receives a PIM Join asking for a group with a
registered source, the RP sends its own PIM Join towards the source
to build an outgoing interface list downward.
Remember from our previous modules that PIM Joins are initially
converted from some form of host or router signaling, like multicast
listener discovery in IPv6. From that point,
the interface on which they are received are added to the oil of a router and
then the join is forwarded out of the incoming interface. With PIM Sparse‑Mode,
the routers don't initially know where the sources are that are sending, so
instead they use the IP of the rendezvous point to determine the incoming
interface and perform any RPF checks.
This is commonly known as the shared or any source
tree with the RP as its target.
When the oil to the RP is completed,
we have a complete path back to the interested receivers.
The traffic will flow along each router in path according to its own
outgoing interface list built from the PIM Joins.
When the traffic is delivered to the last hop router, something magical happens.
The LHR learns the IP of the source.
The LHR will now send an S,G PIM Join directly towards the
source. Because the source IP is now known,
it becomes the target of the unicast best path decision to pick an
incoming interface for the routers along the way.
Note that this PIM Join process is separate from the *,G any
source PIM Join process involving the RP.
And in fact, while this is happening,
multicast traffic is still flowing along that shared tree while this new
path is being built. Once the FHR receives the PIM Join,
it will add that downstream interface to its oil and the
traffic will flow along the new path.
Each receiver will temporarily receive two multicast streams,
one flowing from the source to the RP along the *,G shared tree and one
from the source downstream via the S,G source tree.
Each router using the *,G shared tree will send a PIM Prune
upstream towards the RP to stop the flow of multicast.
This is traffic optimization. Now that the source is known and the
S,G tree is built, the rest is just cleaning up.
If the RP removes all interfaces from its oil due
to receiving PIM Prune messages,
it will also send its own PIM Prune upstream towards the first hop router.
If the outgoing interface list towards the RP is not using the same
interface as the one on which it received the S,G join, it will prune that
interface and the optimal traffic flow is achieved.
The end state of any source multicast is optimal multicast traffic flow based
on the best path between sources and interested receivers.
Now that we've recapped the basic operation of any source sparse‑mode multicast, we're going to branch into what's changed for IPv6.