So now we've got the shared tree built.
At this point, if the multicast ever starts, once it reaches the RP, it'll
go from router 3 to router 8, router 8 to router 2, and then out to router
1. So we're ready to go.
Okay, so let me, okay, I'll just keep this the way it is for now.
It's starting to get a little cluttered, but I'll do my best here.
Okay, so now, you know, a minute later, an hour later, the source finally
starts up. He starts sending his multicast stream.
So there it is. Router 4 on the back of the head.
What action will router 4 take as a result of receiving this very first
multicast packet?
He's actually going to do a lot of stuff, so there's more than one correct
answer here. Well, before he does anything, you know, the rule of PIM
is that when you receive something, you can't create any PIM packets.
You can't forward any multicast packets until you create state in the
M route table. Without M route state, you can't do anything.
So the first thing that this guy has to do is create M route state.
So he says, okay, well, because I've received actually traffic from the
source, I'm going to create s-coma-g state, which is 4.5.4.5 to 39.999.
So that's our s-coma-g.
Okay, so in this particular case, incoming interface, what's he going
to have as his incoming interface?
Well, it's going to be the interface where this multicast is actually
coming in. Exactly.
Fast ethernet, 0 slash 1.
That's right. So that's what we'll have right here.
What's going to be the RPF neighbor for this entry?
What IP address will we stick in there?
Exactly, Peter. That's right.
He says, look, I'm the last hop router.
I am connected directly to the source.
This didn't come to me by way of any other router.
So the next hop neighbor will be all zeros.
I'm where it starts right here.
Now, right now, what's going to be in the outgoing interface list as he
creates this? Outgoing interface list is going to be null.
Because he's going to say, look, even though I'm receiving this multicast,
nobody's ever asked me for it.
I've never received any kind of IGMP or PIM requests for this.
So it's null. Now, if I did a show IPM route, right now is this all I
would see, this s-energy entry for this state?
You got a 50% chance of getting this right.
Yes or no? No. The answer is, no, this is not all you would see.
Because while routers over here can have star comedies all by themselves,
an s-coma-g cannot be by itself.
An s-coma-g is, you remember that little brother big brother analogy?
I said that the star comedie is the big brother.
He can go out. He can saunter around the neighborhood all by himself.
But the s-coma-g is the little seven-year-old brother.
We don't want him out by himself because something might happen to him.
So he's got to go along with the big brother.
So we got to create the star comedie entry if one does not already exist.
In this case, one did not exist.
So we'll populate that.
Getting a little cluttered here, but I'll try to fit everything in.
Incoming interface will be fast.
Ethernet 0 slash 0 dot 34 because that's the interface that leads to the
rendezvous point.
Our PF neighbor will be 3 dot 4 dot 3 dot 3.
An outgoing interface list, once again, will be null.
Because we only populate the outgoing interface list with something if
we receive a request of some sort.
And we've never received a request.
Okay, so now we've created MROUT STATE.
But we still haven't answered the question, what are we doing with this
very first multicast packet?
Now that the MROUT STATE is created, what are we going to do with that?
We are going to register it.
We're going to send it.
We're going to encapsulate it inside of a PIM register packet.
So here it goes, and that's going to be unicasted.
So let's see if I can do this justice here.
So this is going to be unicasted from R4 down to R3.
And a sniffer trace will say PIM REGISTER.
Now once R3 gets that PIM REGISTER, just like R4 did a whole bunch of
stuff simultaneously when he got the first packet, he created all the
state and he registered it, well R3, he's going to do a whole bunch of
stuff simultaneously once he gets this register.
Because he finally sees the actual source, he can create an S-comaG entry.
I'm not going to sort of run out of room here, so I'm just going to put
just the basics.
4.5.4.5, 2.39.999.
So that is my S-comaG entry.
And if you have any questions about what the incoming interface is or
anything like that, so in this particular S-comaG entry, I'll go ahead
and put this. When he creates it, he'll say, okay, well, if I've already
got an existing star-comaG, it was just hanging around and waiting.
And now I create an S-comaG because I actually see the multicast.
I'll go back to my star-comaG and whatever is in my outgoing interface
list there, I'll copy it into my S-comaG.
The only situation where that would not happen is if by doing so, you
would have a duplicate of where the S-comaG incoming interface is the
same as the outgoing interface list.
You can't have that.
You can't have an interface in the outgoing interface list that's the
same as the incoming interface.
That's against the rules of PIM.
But in this case, we don't have to worry about that.
So somebody in the live audience asked a good question.
They're saying, so that's a unicast message, right?
That PIM register is unicast.
So if I had two or three or four routers between router three and router
four, would they have any multicast state?
No, they wouldn't.
Because if there was any routers in between here, they would just see
a unicast packet with a source address of four, destination of three,
and they would just route it.
Just like they're routing a telnet or a web browser request or an FTP.
So if there were any routers here in between right now, their M route
state would show nothing.
They're not aware that the multicast is actually traveling through them
as a unicast. Okay, so router three creates the S-comaG state, and then
he uses that to actually forward it down the tree.
So he says, okay, I'm going to unencapsulate this register, revealing
the multicast inside, and I'm going to forward it down the tree, and then
router eight, when he gets it, well, that will create S-comaG state in
him. I'll just put that, because we're running out of room.
He will then forward it down the shared tree to router two.
Now let's back up here for a second.
Before I talk about what happens on router two, let's go back to the rendezvous
point. Exactly, Brandon, the pin register is basically a unicast tunnel
for the multicast packet.
Actually, it's kind of interesting that you bring that up.
Once you go onto router and you very first configure the RP on him, you
tell him who the RP is, check this out.
I'll just go, it doesn't really matter which router I pick, but all for
the sake of purposes, I'll go to router four.
Look at this. It actually creates a tunnel interface.
Yeah, and if you do show interface tunnel zero, it actually says, pem
register tunnel.
Every router will have that, because at any given time a router never
knows, am I going to need to register?
Is there ever going to be a multicast that hits me that I'm going to need
to register to the RP?
So as soon as a router knows who the RP is, it dynamically creates this
register tunnel.
So it's ready and waiting to be used in case it ever needs to register
anything. Yeah, so that's pretty cool.
Okay, so router three, he has just forwarded the multicast packet down.
Now I mentioned that the problem with these register packets is, it consumes
a little bit more CPU resources in the router who is doing the registering,
the router who is unencapsulating or deencapsulating the register.
So router three says, okay, I don't want to keep receiving these register
packets if this is making me work extra hard.
I would prefer just to receive the native multicast as it is, pure multicast.
He says, so in order to do that, I got to let my upstream neighbors know
in the direction of the shortest path tree that that's what I want.
So router three says, okay, now that I got this s-comage state, and according
to me, my shortest path tree is interface fast-eath and at zero zero.
Right, he says, when I do an RPF lookup on the source, four, five, four,
five, my RPF lookup says my shortest path is going out fast-eath and at
zero zero. So router three will then send another kind of PIM packet.
What kind of PIM packet will router three send at this point in order
to open up his shortest path?
He will send a PIM s-comagee join, an s-comagee join.
And if there were any routers in the middle here between these two guys
who did not previously have any multicast state because the register was
just transparently going through them, if there were any routers, let's
just put a fake one right here for the time being, let's just say router
x was right here.
Now upon receipt of this s-comagee join, router x would create s-comagee
state in his m-route table.
And he would create star-comagee state because the s-comagee can't live
by itself. It's too scared to go walking out there in the world by itself.
It's got to have big brother along with him.
So it creates star -comagee state also.
And then he would forward the s-comagee upstream and eventually it would
reach router four.
Once router four receives this s-comagee he says, oh, somebody is actually
asking me for this multicast.
So now in my s-comagee entry, I can remove my null outgoing interface
and I will replace it with the interface where I just received the request,
the s-comagee request, which is fast-eathonet00.34.
That now gives router four permission to start forwarding the multicast
natively down fast-eathonet00.34.
But remember, when that s-comagee join came in, router four doesn't necessarily
know that it was because the rendezvous point initiated it.
He doesn't necessarily know that.
All he knows is that there's a downstream neighbor who wants to open up
the multicast. So router four says, okay, I'll send the multicast in his
pure native form down this link, but I don't know if the rendezvous point
has even received my register.
Because remember, it's not like TCP.
There's no acknowledgments or anything here.
When router four sent the register he just sent it out into the void and
he had no idea if the RP actually got it or not.
So he says, well, in addition to sending the multicast in his native form
down this way to router X, I also need to keep on registering.
I can't stop that.
Because until the rendezvous point confirms that he's received my register,
I got to keep going.
So now the multicast is coming down this tree and router three gets two
copies of it. He gets the native multicast because now this path has been
opened up. And he receives that exact same multicast packet encapsulated
inside of a register.
Now, router three says, okay, great.
I know that my shortest path to the source is working.
I know it's opened up.
Because if it wasn't working, I would not have received the normal multicast,
the real native multicast.
He says, so since I got the real multicast, which he continues to forward
downstream, he says, now I can send a register stop message.
Which I'm totally running out of room here, but he can send a PIM register
stop. And that, just like it says, that will cause router four to stop
registering. And now he will just send the native multicast in his pure
form down to router three and away it will go.
Now, I mentioned when the very first multicast packet, when that first
registration was unencapsulated, deencapsulated, and eventually made its
way to router two, I said, let's pause for a second.
Let's go back to the rendezvous point because router two is going to do
a bunch of stuff.
So let's sort of go back in time.
Let's flip the clock back just like a second or two to when that very
first multicast packet hit router two.
Well, guess what?
Router two, when he gets it, he creates S, comma G state, because now
he's seen the packet.
And he says, okay, he goes back to his star, comma G entry, and he sees
a little flag in there.
The C flag, which says, oh, I remember I created the star, comma G state
because a directly connected, that's what the C stands for, a directly
connected receiver asked me for this multicast.
I got a membership report.
So he says, that means I am what PIM calls a leaf router.
I'm at the end of the branch.
And because I am a leaf router, I have the authority to open up the shortest
path tree. For myself, I can move away from the shared tree and try to
get these packets in a more efficient manner.
So if we assume here that this serial link is actually the shortest path
tree from router two's perspective, he's basically going to do the exact
same thing that rendezvous point did.
He's going to send an S, comma G join upstream.
And when router four gets that, he will in his outgoing interface list
now add serial 010 to that outgoing interface.
And now the native multicast will start flowing down this way.
Once router two gets that native multicast, he now says, okay, awesome.
I'm now getting the native multicast on my shortest path tree.
But hmm, I'm also getting copies of that packet down the shared tree.
I don't need those packets down the shared tree anymore.
I don't want those.
So review question, what does router two do in order to try to stop the
packets from coming down the shared tree?
That's right. He sends a PIM prune message.
Exactly a PIM prune message, which is the exact same format as a PIM join
message. Just instead of saying number of groups joined, it says number
of groups pruned.
So he sends a PIM prune.
In this particular case, he'll actually have the source, 4.5.4.5.
He'll have the group.
But inside there, he'll have the RP bit set, which tells his upstream
neighbor, hey, don't forward this to the source.
Even though I'm listing the source's address here, that's not where this
message is ultimately going.
I need you to forward this to the rendezvous point.
So then router eight will prune off zero slash one from his outgoing interface
list. He'll create a prune message, which he'll then send up to router
three. Router three will then prune off his outgoing interface list.
And now router three will say, okay, well, nobody needs the multicast
for me anymore. I have no more interfaces in my outgoing interface list.
So guess what he'll do?
He'll send a prune up towards the source.
And so eventually, after just like a second or two, the traffic will no
longer, he'll stop going through the rendezvous point, and it will only
be going down the source path tree directly to router two.
So what questions do you have?
That completes my review of this process in the live audience.
Do you have any questions?
Peter asks a good question.
He says, hey, I remember something called a null register.
Who sends that and under what conditions is it sent?
Okay, so here we are in the present.
Right now, the multicast is hitting router four, and the only outgoing
interface that router four has is serial zero slash one size zero.
So he's sending it down directly that way.
But router four, he says, well, every few seconds he has his thought.
Router four, every few seconds, says, well, there's a possibility that
somebody else in the last few seconds may have joined the stream and sent
their request to the rendezvous point.
And maybe the rendezvous point sitting there right now, twiddling his
thumb saying, man, I wish that stream would start because I've got somebody
new who wants it.
But remember, the rendezvous point may have forgotten about the stream.
He may have no state anymore.
So when somebody else joined it, that created new star, comma G state
and the rendezvous point.
But he forgot about his previous S, comma G state.
That's gone. So router four says, just in case that may have happened,
I'm going to send a null register.
It's about every five seconds.
Every five seconds or so, I'm going to send a null register down to router
three, which doesn't actually have the multicast packet inside of it.
It just basically says, hey, rendezvous point.
Just want to remind you that I've got this multicast stream going.
I'm forwarding it to other people.
And if you want it, you might want to ask me for it.
So that's what a null register is.
It goes out every five seconds.
It's generated by router four because he's the one that's directly connected
to the source. And it's his way of reminding the rendezvous point, hey,
do you want this?
Now, if the rendezvous point does want it, he'll send an S, comma G join
to reopen that path.
If the rendezvous point doesn't want it, he'll send another register stop.
He'll say, I don't need this.
And so that'll happen.
Every five seconds.
So yeah, that null register is always generated by the first hop router.
The router that's directly connected to the multicast source.
Are there any other questions?
And yes, Josh asked a good question.
He said, going back to router two, when router two switched over to the
shortest path, just Josh just wants confirmation.
He's absolutely correct.
The way that the router determines the shortest path is once he looks
at the source address of that multicast, which in this case is four, five,
four, five, five, four.
He does an RPF check.
He goes into his unicast routing table and says, what's the best route
I have back to that source?
And he might have a static route or an EI-JRP route or an OSPF route.
But in this case, he had some kind of a route that said the best way to
get back to the four, five, four network is via serial 010.
So that's how he determined what his shortest path would be.