So by this point in the process, if you've been watching these videos
from beginning up until now, we've pretty much covered the vast majority
of the details of the PIM process and how it works in 90% of cases.
But there's still a couple of other details that may have escaped you
that are important to know, and that's what we're going to talk about
now is this concept of designated routers and designated forwarders.
Not really necessary to know if PIMs working perfectly, but in the case
where things aren't working as you expect, you might have to troubleshoot
things, you definitely have to know what these routers are, what purpose
they serve, and why they were elected into these particular roles.
So that being the case.
I have a couple of questions for you.
So if you're watching this as a recording, just think about it, blur it
out your answer verbally, don't be afraid that people in the cubes next
to you might think you're kind of insane, but see if you can answer these
questions. They're basically yes or no questions.
So looking at this diagram right here, we've got our source in the upper
left corner, and we have two receivers, receiver X and receiver Y.
So my first question, let's assume that receiver Y first joins the stream
by sending an IGMP membership report.
Well because routers three and four are both connected to that same LAN
segment, here's my question.
Would it make logical sense?
Would there be a purpose behind both of those routers, routers three and
four, when they both receive that membership report, both of them sending
a star, IG join up to the rendezvous point?
Well, hopefully answered, no, there wouldn't be a purpose behind that.
As a matter of fact, that would be a bad thing because if both of those
routers did do that, they sent joins up this way and up this way, well
guess what? Now when the multicast traffic actually starts happening,
use a different color right here, and starts coming down, well, router
five has two interfaces and is not going interface list.
So he'll copy that multicast traffic and we'll end up having two copies
of the same packet onto LAN C.
We don't want that.
We don't want duplicate copies because who knows how router, how receiver
Y is going to respond to that.
The video might be really choppy, might have like a mirror effect.
We don't want that.
So no, even though two hours in the same LAN we'll see the membership
report, we don't want both of them sending the join upstream to the rendezvous
point. Next question.
The source starts up, sends his very first packet onto LAN A.
Both routers one and routers two see that packet.
Similar question is before, does it make sense for both routers one and
two to register that same packet and send those two registers to the rendezvous
point? Once again, hopefully you said no, doesn't make a lot of sense
because we don't need both of them to do it.
Number one is going to add additional work to the rendezvous point.
Now you're having the rendezvous point work twice as hard to receive and
deencapsulate there's only a need to send one packet down to LAN A.
There's no need to send two.
So once again just like there was no need for both routers to send star,
join, there's no reason both routers one and routers two need to send
register packets to router six.
Only one of them needs to do that.
And last question.
Let's say the multicast is flowing.
So it's going this way down the shared tree.
Now receiver X has also joined that stream.
So it's also going through router two on to LAN B.
And remember routers three and four, they both saw the membership report
from receiver Y.
So router three put this interface in his outgoing interface list.
Router four put this interface in his outgoing interface list.
So router four when he receives the packets, he'll forward it on to LAN
C. When router three sees these packets coming on to LAN B, he will forward
the same packet also on to LAN C.
Do we want that?
No, we don't. Once again we got duplicate multicast packets going on to
LAN C. That's probably not going to make the receiver very happy to see
that. So how do we get away from these problems about multiple routers
sending a join for the same stream and the same LAN?
Multiple routers sending a register for the same stream on the same LAN.
Multiple routers forwarding duplicate packets onto the same LAN.
That's exactly what this segment is about.
How do we avoid that?
Well PIM, fortunately the people who designed PIM were a lot smarter than
me. They thought of these problems in advance and they came up with some
solutions. So how does it work?
Well PIM designated router.
When two routers share the same LAN, one of them will be elected as the
PIM designated router.
This is simply done by an exchange of PIM hellos.
It's sort of like think about spanning tree, if you're familiar with spanning
tree. Are there special election messages to elect the root bridge?
No, right? Spanning tree just uses one format of a BPDU.
That one packet format is used for everything.
So when two switches forward BPDUs to each other, they see each other's
names and one guy says, okay, I know you're the root bridge.
He doesn't actually say that, he thinks it in his mind.
Okay, I lost, he's better than me.
So I'll just think of him as the root bridge.
The other guy over there will say, oh, I saw his packet.
He's not as good as me.
So I'll just be the root bridge and I'll assume that he knows on the root
bridge. Same kind of thing here with PIM.
These routers are exchanging hellos.
When they see each other's hellos on the same LAN, they'll look at their,
well, that's actually two things.
Number one, there's a PIM priority.
So there's an interface priority just like OSPF has an interface priority.
There's a PIM priority that is included inside the hello packet.
So whoever has the highest interface priority, that person will automatically
be elected as the designated router.
If their priorities are the same, which by default they will, then whoever
has the highest IP address will be elected as the designated router.
Okay? So once the designated router is elected, if we go back to our drawing
here, now that solves a couple of the problems that we are looking at.
Numbers of the routers represent their IP addresses.
So router four on LANC has a higher IP address than router three.
So in that particular case, actually I've got a slide that animates all
of this. So in this particular case, let's look at LAN A for a second.
When the multi-cast packet, when the very first multi-cast packet hits
LAN A, only the designated router will be responsible for registering
that packet with the RP.
So in this particular case, which router do you think is going to do that?
Who's going to be the designated router on LAN A?
Well, hopefully you said router one, because router one has the highest
IP address. So he will be the designated router, he will be responsible
for registering those packets.
And on LANC, well, when receiver Y sends his IGMP membership report, both
routers three and routers four will see it, but router four is a designated
router by virtue of his highest IP address.
So he will be the one to send the PIM star, comma G join upstream to the
rendezvous point.
Now that answers two out of the three questions that we had.
So we had three questions.
Remember number one was if two routers see a membership report, which
one sends the join to the RP?
Well, that's the designated router.
So something going to the RP.
Second question was if two routers get the multi-cast packet, who sends
the register to the RP?
That's the designated router.
So remember, designated router, maybe you can think of R in DR as being
this is something responsible for going to the rendezvous point, someone
who's sending something to the rendezvous point.
Now I said that we had one other problem in this scenario, which is that
we had multiple duplicate packets being put onto the same LAN from multiple
routers. And I said it's not the DR's job to figure that out.
That's the job of the designated forwarder.
So if multiple packets, if I've got two or three routers all servicing
the same LAN, and two or more of them are putting the exact same multi
-cast packets onto that LAN, then one of them will be elected as the designated
forwarder. Now that's actually a little bit more complex of a process
than just simply looking at hello packets.
In order to figure that out, there's actually a special PIM message called
the PIM assert. So this is a new message we haven't talked about.
So so far we've talked about the join prune, which is one packet, it just
depends on the body of the packet, whether it's a join or prune, but it's
the same type code in PIM.
We had another type code, which was the hello, and we had a third type
code, which was the register.
And we had a register stop, and now this is another kind.
This is a PIM assert message.
And here's an animation to show basically how this would work.
So in this particular case, the source starts going, and the packets are
going both down the shared tree, so router 4 is putting them onto LAN
C, and router 3 is getting them via LAN B, and so he's also putting them
onto LAN C. So routers 3 and 4 will see these duplicate packets coming
from each other.
They'll realize, hey, this is a bad thing, we need a designated forwarder.
So they'll both send PIM assert messages to each other.
And this particular case, the guy with the lowest IP address will actually
be elected as the designated forwarder.
So once both routers know that router 3 is a designated forwarder, it's
now router 3's job to continue forwarding this multicast onto the LAN.
Router 4 says, okay, I'm not really needed on this LAN anymore, because
it's not my job to forward the packets.
So in his, in response, he'll send a prune message upstream, which will
end up causing that shared tree to be cut off.
And now the multicast will only be forwarded onto LAN C by way of the
designated forwarder, which is router 3.
So that completes this particular topic of the PIM designated router and
designated forwarder.
You can actually see this also when you go into a router.
I don't know if we have any segments here which would warrant a designated
forwarder, but let's just see here.
Show IP PIM neighbor.
Well, here the DR shows you if someone's a designated router or not, so
as you for a particular segment who the designated router is.
And I think we can also do a show IP PIM interface.
This just shows you here who the designated router is once again.
It has a default priority of one, so that's a default priority level on
the interface, but you can change that.
Let's see here. This shows you the particular groups that we've joined
on an interface, the show IP interface command.
I don't know what command we would use.
Or maybe detail.
There we go. It should be in here.
Let's see here. PIM enable the version who the DR is.
State refresh. Yeah, I think the reason why we're not seeing this is because
this would a designated forwarder would only be elected when both routers
see the same multicast packet coming from duplicate packets coming.
But if there's never a situation where duplicate packets are going on
a LAN, there's no need to elect a designated forwarder.
And in my particular topology, I don't think we've had that situation
where a designated forwarder needs to be elected.
I would expect that if there was one, it should be here in the show IP
PIM interface detail output.
Okay, so Josh asks a good question.
Let me go back to the designated router concept.
We had this right here.
Oops. Right there.
So he asks, in this particular case, where router four is a designated
router and router three is not.
He says if the designated router goes down, so if router four crashes
and dies or gets removed, how does router three build or rebuild its multicast
routing table and how long does it take?
Okay, so keep in mind that even though router four is a designated router,
when receiver Y sent his IGMP membership report, both router three and
router four saw it.
So even though router three realizes that it's not his job to join the
shared tree, he's not just going to ignore that report.
He will still create star, state in his M route table just like router
four does. It's just that when he creates that state, he won't do anything
about it. Now if the multicast is currently flowing down this way, down
the shared tree, we would expect that when the very first multicast packet
happens, router four would say I'm the leaf router, so it's my job to
switch over to the shortest path tree with just the receipt of one packet.
So look in this diagram here, router four would say well, from my perspective,
the shortest path is actually via router three.
This is my shortest path tree, going that way, that way, and that way.
So router four will actually create the S, G join and router three will
receive it, so now, actually it's kind of weird here.
When this very first multicast packet hits this wire here, I'm not sure
the timing of things.
We know that router three is going to create S, G state.
I just don't know what will happen first.
Will he see this very first multicast packet and that will create S, G
state? Or will he see the PIM S, G join first and that will create S,
G state? So then he will forward his own S, G join upstream, so after
just one packet coming down within like less than a second, we would expect
the multicast stream to now be coming this way via router three.
And then once router four sees that multicast packet, he'll prune this
off. So even if router four dies, we only really needed him for like one
packet, just to put one packet on to the wire, and then router three did
all the remaining work of opening up the shortest path tree, and now the
packets were being forwarded on to land C, and router four wasn't necessary
anymore. Now, you know, we can get into all sorts of corner cases here
like, okay, well, what if the membership report comes up, both router
three and router four get it, but before router four has a chance to create
the join, he dies.
Right now, that's like real nitty gritty, because we're talking about
less than a second here from the time he receives the membership report
before he has a chance to send up the join.