It's time to cover an implementation of PIM that's unlike
any other implementation out there.
Bidirectional PIM changes a lot of the rules we learned so
far and it can be tricky to understand.
We'll go step by step.
In this module, we'll talk about bidirectional PIM and its operation,
we'll see demonstrations of the designated forwarder
selection and what the DF means in birdir PIM,
and then we'll see a demo of birdir PIM in action.
We'll finish off with a packet capture analysis including a PIM Hello,
a join, and a few DF election packets.
The GloboTicket acquisition and subsequent multicast deployment has
proved so popular that employees who are aspiring musicians have
asked to start collaborating remotely.
In their spare time,
a few software developers created an application that can send music,
as well as receive it.
The GloboTicket leadership likes this idea and wants to
dedicate certain multicast groups for it,
though,
the network engineering team is concerned about the impact of
tracking so many sources and receivers.
Bidirectional PIM could be used to solve this problem.
Let's see how.
Up until now, multicast has been a one‑way street,
only flowing downstream from one source to any number of receivers,
but let's imagine a situation where many endpoints
wanted to communicate via multicast.
This is a common use case in deployments where there are endpoints that want
to both stream their own data and learn data from others.
Financials are a good example of this where traders stay
informed of each other's trades via an application.
In our GloboTicket example,
people want to both stream their own music and be able
to listen to the music of others.
What happens when a network is full of sources and receivers,
what about when you have receivers that are also sources?
When the tracking of multicast state becomes too cumbersome,
what strategy can we use to ensure multicast delivery
while protecting against routing loops?
The answer is to stop basing the multicast flows on the source tree altogether.
Because bidirectional PIM assumes any endpoint could be a source,
it does away with tracking the S, G entry.
This also means we do away with optical source trees and our
PIM joins will never be based on a source.
To support bidirectional flows,
we need an arbitrary point everyone can agree on to
forward both PIM joins and the traffic.
Sound familiar?
Welcome back to our good friend, the rendezvous point.
In bidirectional multicast,
all flows use the RP as the root of the shared tree and
all traffic must flow through it, whether sending or receiving.
If that seems suboptimal, it is.
The trade‑off of allowing multiple sources and receivers to scale
necessitates slimming down the multicast state tables.
For any bidir group, there will only be a shared tree.
The rendezvous point no longer handles source registration as
we're not tracking the state of sources.
It instead acts as the arbitrary point from which
the bidir shared tree is built.
But how is the bidir shared tree different?
The answer to this lies with the role that only exists in PIM bidir,
the designated forwarder.
The designated forwarder is a role that only exists in
bidirectional PIM and should not be confused with the designated
router, as the DF might not necessarily be the DR.
The designated forwarder is elected based on the shortest path to
the RP for each segment and link; it is the sole router on a
segment that can forward multicast data downstream to receivers
or upstream towards their RP.
The DF is also the one that forwards PIM joins upstream towards the
RP to help build the outgoing interface list.
It is the oil that ultimately determines where
multicast flows downward from the RP,
and all source traffic flows upstream to the RP,
regardless of PIM joins.
The DF is also the only router which will deliver multicast to
any local segment where there are receivers.
There is no concept of a PIM assert in birdir PIM.
The DF election is absolute and irrespective of the path to the source.
In this example,
we walked through a DF election and what that means
for building the shared tree.
Starting with the RP, which is the root of the shared tree,
each segment outward must have a designated forwarder.
Remember that the router elected the DF will be the one delivering
downstream multicast and forwarding PIM joins upstream.
Importantly,
the field in a PIM join's upstream neighbor field will always be
the DF of the upstream link when forwarding.
Moving to the next routers outward from the RP link,
we start seeing some specific path things starting to take shape.
Each router attached to a link compares its Unicast best
path metric to the RP address and announces it; the best
metric wins the DF election.
If there's a tie based on metric, then the highest PIM neighbor IP wins.
For those who may be watching who are network engineers,
this may start to look familiar.
This process is very similar to the spanning tree loop
prevention process with the RP acting as the root.
Much like spanning tree and VLANs,
we can use different multicast groups and different
RP addresses for this process, resulting in different shared trees.
For simplicity, I've reduced it to a single group and a single RP.
Well, sort of this concept tends to blow people's minds a bit,
but let's take it piece by piece and it'll start to make sense
and it'll fit with what we've been discussing.
I should explain up front that the phantom RP is an option,
but not a requirement in bidir PIM.
Unlike any‑source multicast,
the rendezvous point in bidir PIM doesn't need to register sources.
In fact, it doesn't really need to do anything.
There's no source registration,
so there's no need for an RP to send a join towards an upstream source.
The RP becomes an arbitrary point in the network from
which we plan to build the shared tree.
Everyone must agree on the RP,
but only so we can determine what is upstream and downstream and
so we can elect our designated forwarders.
This means the router servings in RP can be replaced by a link servings in RP,
hence the name phantom RP.
If that causes you to do a double take, trust me, I understand.
Let's see an example first.
In order to use a phantom RP,
we need to advertise some arbitrary link into the network.
There are a lot of ways to accomplish this,
but usually what we see is a loopback address.
We also need some way for everyone to agree on the RP address,
but in this case, we can't use bootstrap router.
Next, we need to ensure that the RP address isn't local to any router.
This is the reason why we can't use bootstrap router to elect
and select an RP because BSR requires that we choose an
interface to be the candidate RP,
and we specifically want to avoid using a local IP as the RP address.
The reason why we don't want any router to process the PIM
join is because the PIM joins are only being used to create
an outgoing interface list.
There will be no need for the RP to send a source tree
join based on receiving a PIM join.
And after I explain this next part,
the reason for not hijacking PIM join should be very clear.
Providing redundancy for a phantom RP means making sure there are
multiple arbitrary places within the network that can serve as the
RP in case of a router or link failure.
In this case, MCAST2 has a loopback configured that's also advertised,
but notice that the subnet mask is a shorter match than MCAST1.
This means if MCAST1 fails,
the rest of the PIM routers will still have an RP address to use,
though such a failure would necessitate DF re‑election
and recalculation of best paths.
MCAST2 is the backup for RP.
Because though the prefix is the same,
the subnet mask is less preferred by the Unicast routing table.
Let's see an example of why we never want the local router to
have an IP configured for the RP in bidir PIM.
Suppose the receiver sends an IGMP report and the PIM join needs to be
forwarded to the RP and the best path to the RP link happens to be
through another router with a phantom RP link.
Even though the correct RP link is being targeted,
if the PIM join reaches a router serving as the backup phantom RP,
that PIM join would be stopped there as it is addressed to a local interface;
it would not end up being forwarded upstream as it should.
Instead, if the RP is within the subnet of the link,
but not the IP itself,
every PIM router will correctly forward it to the
current best phantom RP address.
The most important thing to remember is that for phantom RP to work,
the RP address must fall within the subset of the advertised
links, but not be assigned to a router.
Redundancy is achieved by advertising backup phantom RP links with
shorter matches, though the RP address still needs to fall within
that submit. The DF election and the avoidance of multicast loops
depends on every router having the same RP address and agreeing on
what the RP link is.
This is because every PIM router will send multicast source traffic
towards the RP via the bidir upstream interface without waiting for an oil
towards the RP to be built. PIM joins for the shared tree will also be
forwarded to the RP link, and it's this that builds the outgoing interface
list downward of receivers.
So it's vital that every router agree on the forwarding
shared tree to get traffic from a source to a receiver without tracking the sources themselves.