Alright, so up to this point, if you've been watching the videos from
the beginning up till now, I've sort of broken it up into sections in
order to highlight each section, really give the details of what's happening
in each process or as each trigger happens in the PIM process.
We had a section on, you know, the shared tree being built and the triggers
and the messages that happen with that, then we had another video about
the registration process as the source starts up what that looks like.
Then we had another section on joining the shortest path tree.
So, I'm going to bring it all into focus.
Now, I'm just going to do a quick review on the whiteboard of all that
stuff as it happens.
Not going to do any more sniffer traces or labs.
We've already done that in the previous trait in the previous sections.
I'll just show you on the whiteboard end to end the whole process as it
happens. So, hopefully that will bring it into focus if you were sort
of stuck right now seeing the forest through the trees as the saying goes.
So, let's go back to our whiteboard here.
Okay, so now with multicast, one of two things could happen first.
Either the receivers could start joining the multicast before the multicast
has even started, and that could certainly happen.
You know, for example, if you find out that your CEO is going to be having
a video at three o'clock today of some big new bonus structure in your
company. Well, before that even video starts going out at three o'clock,
people in their cubes will probably start joining it, you know, five or
ten minutes before the video even starts.
So, that could happen where, you know, maybe you've got a video stream
that starts up that's running 24 by seven, like, you know, the CNN newsfeed
or the BBN, you know, newsfeed, something that's going all the time, and
it might not even be anybody watching it.
So, the registration process could happen first, and then the receivers
could join later.
So, just to simplify things, I'm going to start with the first scenario
where the receiver joins first, and then the video starts up after that.
So, just as a review, step number one in this process is if the receiver
is joining, we know that receiver, we're just going to assume IPv4 for
now just to keep it simple.
We know that receiver, which is my laptop here on the left, is going to
send what? Review question.
What kind of IgMP message will that receiver send his default gateway
saying, I wish to be part of this stream?
Who can answer that?
Well, hopefully the answer you came up with was an IgMP membership report.
Sometimes they call that an IgMP join.
That's the sort of slang term for that, but the technical term is an IgMP
membership report.
And we know that the destination address of that report will be whatever
the stream is that the guy wishes to watch, and also in the body of the
report, the GDA field, the group destination address field, will also
be this exact same thing.
Okay, now if this router here is not enabled for PIM, on that interface,
he's going to ignore that because routers don't listen to IgMP by default.
They ignore it. So, that's one of the reasons why we have to enable PIM
in some form, either dense mode or sparse mode, on this interface, because
that also enables IgMP processing as a byproduct of that.
So, let's just assume for the sake of argument that every single interface
that we see here in this drawing already has PIM sparse mode enabled.
Okay, so let's just assume that.
Also, let's assume for the sake of argument that we've already predetermined
that the PIM rendezvous point is going to be router three right here.
And all of the routers, including router three, are pointing at the IP
address on router three's fast, Ethernet zero zero, which is three dot
four dot three dot three as the PIM RP address.
And in case you forgot, the command for that at the global level was IP
PIM RP dash address, and then you put the address.
And we did that on every single router, including the RP itself.
Okay, so that was the command to statically configure an RP.
Okay, so PIM is enabled.
Everybody knows who the RP is.
And of course, everybody has to be able to reach the RP.
So, we're going to assume there's some sort of routing protocol like EIGRP
or RIP or something, running in the background.
So everybody knows how to get to everything.
Okay, so all of that background prerequisite stuff is already done.
All right, so now the IGMP membership report comes in on router two.
Now, if I did at that moment, right after router two received that IGMP
membership report, if I issued the command show IP em route in router
two, here's a review question, what kind of em route entry would I see?
Exactly. Thank you, Peter.
And for those of you watching, hopefully you said you would see a star
comma G entry. Exactly.
That's why I would see a star comma G.
So in this particular case, if I write that, I'll just keep this here
in red to denote PIM stuff.
So in router two, I would see a star comma 239.999 entry, which is what
we call star comma G.
Now next to that would be the RP's address of 3433.
That indicates that we actually know who the RP is.
Okay, another review question.
Using this particular drawing is our guideline and assuming that the fast
Ethernet links are a much better routing metric than the serial link,
that the serial is really the last preferred route to get anywhere.
And I'm mentioning that for a reason.
In the star comma G entry, we'd have something called an incoming interface.
I'm just going to shorten that to IIF.
On router two, what interface would we see as the incoming interface?
That's right. It would be fast Ethernet zero slash one.
And if you forgot, if you said, well, how did you come up with that?
Remember with the star comma G entry, that's all based around the rendezvous
point. Who is the rendezvous point?
How do we get to the rendezvous point?
And in this particular case, in this diagram, it's a pretty safe bet that
for router two to get to the rendezvous point, his best path is via fast
Ethernet zero slash one.
So let's say that, fast Ethernet zero slash one.
Okay, next question.
There would also be right there something called an RPF neighbor.
What IP address will be listed there in the RPF neighbor field?
Yeah, it would be the IP address of his upstream neighbor, which in this
case is router eight.
Now remember the upstream neighbor in relation to how I get to the rendezvous
point. So that would be eight dot four dot eight dot eight, which is not
eight dot four, eight dot two dot eight dot eight.
So that is router two is upstream neighbor router eight to get to the
rendezvous point.
Last thing, there would also be something in here called an outgoing interface
list. What interface, if any, would be in the outgoing interface list
right now? Yeah, so hopefully said, well, that would be the interface
that received the membership report.
The interface where if we actually received the the multicast where we're
going to send it.
In this particular case, this whole star, G entry was created because
we received a request.
We received an IGMP membership report on fast Ethernet zero zero.
So that's what's going to be in our outgoing interface list, because that's
where receiver has joined.
Okay, so that all happens in a split second as soon as that membership
report comes in.
Then that triggers R2 to generate and transmit a special kind of PIM message.
What do we call that kind of PIM message?
Well, hopefully you answered that is called a PIM join.
So that's the sort of generic term.
But we also talked about there were actually two different kinds of PIM
joins. They take the same packet format, but due to the the presence or
lack of certain flags, there was two different kinds of joins.
What kind of join is R2 going to generate?
So hopefully you said Keith, that's going to be a star, G join, a PIM
star, G join exactly, because R2 doesn't know the source.
So in that join, there's going to be a little flag called the wild card
flag, which means I don't know what the source is.
And of all the interfaces that R2 has, which interface will be used to
actually transmit that star, G join?
Where will it go?
That's right. So that the intention of that star, G join is to send it
eventually to make it to the rendezvous point.
We want to let the rendezvous point know, hey, we've got somebody who
is interested here.
And yes, you guys in the live stream, you're answering correctly.
It's all based on basically two things, the incoming interface, which
is the interface I used to get to the rendezvous point and to the RPF
neighbor. So in this particular case, it's going to actually be transmitted
out on fast Ethan at zero slash one.
And then because we know our RPF neighbors 8.2.8.8, we'll look in our
ARP table, we'll figure out what the the MAC addresses of that guy.
And that's how next question, actually, this is a review question.
What will be the destination MAC address of this ethernet frame that's
carrying this PIM star, G join?
Well, this one was a little tricky.
This is a little tricky because the star, G join at layer three of the
networking layer goes to the exact same destination IP address as PIM
hellows. 224 00 13.
So now that we know that the layer three destination is a multicast address,
that should cue you in that, ah, okay, if the layer three destination
address is a multicast address, then we can derive the layer two destination
MAC address from that multicast address.
So in the very beginning of the videos yesterday, I said that all IPB4
multicasts go to the address of 0100 5E.
And then I said, basically, you map the last 23 bits down into the MAC
address here. Well, 13 in hex is what 10, 11, 12, 13, ABCD.
So that's D. So I'll be 0100 5E, 0000 D.
If I got that right there, 0100 5E, and then D is, yep, D is 13, ABCD,
10, 11, 12, 13. So that will actually be the destination MAC address of
that star, G join, because it's going to a multicast.
In the actual IP header, what's going to be the time to live in that IP
header for that join?
That's right. It's going to be one.
Remember, we talked about how multicast addresses have different scopes.
And we said, according to the Internet Assigned Numbers Authority, any
multicast address that begins with 22400 is called the link local scope,
which means it should have just a time to live of one.
It's only meant for your next hop neighbor.
So let me ask you this.
If this star comma G join is only meant to be processed by router 8 and
then discarded, how is it ever going to get to the rendezvous point?
Well, router 8 is going to have to replicate it.
Exactly. He's going to have to create a new one himself.
So basically, the join coming from router 2, the source address will be,
in this case, 8.2.8.2, router 2 source address.
The destination will be 2240013.
Router 8 will process that in his CPU.
His CPU will say, oh, this is a star comma G join.
It's got the RP bit set, which means it needs to be forwarded up to the
rendezvous point.
So router 8 will say, OK, I'm going to use my incoming interface, which
is, he says, oh, oh, so when router 8 gets that, guess what?
That's going to create star comma G state in him, which he didn't have
before. So now he's going to have star comma G state.
It's going to look very similar to what we saw before.
Now, his incoming interface will be fast Ethan at 00.83, because that's
his interface to reach the rendezvous point.
His RPF neighbor is going to actually be 8.3.8.3, and his outgoing interface
list will be the interface that received that PIM star comma G join, which
is fast Ethan at 0 slash 1.
So now that he's created that star comma G state, he says, OK, I need
to now create my own star comma G join.
And there it goes.
PIM star comma G join.
That will also be going to the destination address of 2240013, but this
will have a different source address because it's being sourced from router
8. So if we capture that in a sniffer trace, the source IP address of
that would be 8.3.8.8.
And then once the rendezvous point gets that, now that creates star comma
G state in him. He knows that he's the RP, so you'll see that there.
What will we see in the star comma G state of the incoming interface on
the rendezvous point?
That's right. In this particular case, it will say no, because remember
the incoming interface is the interface that leads to the RP.
Well, if the RP had a split personality and he was psychotic, he might
put something else in there.
But he says, look, I'm normal, I'm okay, I know I'm the RP, I don't use
any interface to get to myself.
So incoming interface is no.
What would we have as the RPF neighbor here?
That's right, it would be 000, 000.
Once again, I don't use any neighbor to get to myself.
And here, the outgoing interface list would be the interface that received
the star comma G join.