All right, so now let's talk about multicast because it really is a high-level overview.
And you might get one or two questions on the exam on multicast, so don't overprepare
for this.
But if I presented it to you and I've shown it to you and I've talked about it, at least
make sure you know the terms, make sure you know the definitions, make sure you know what
they're used for so that way there you can answer questions on a certification exam.
All right, so before we get to terms and definitions, I have to really make sure we understand the
difference between unicast and multicast and give you a few real-world examples because
a lot of us don't realize what multicast truly is, and we think that a lot of things we use
and do are multicast when in actuality they're not, right?
Comes up in my classes all the time.
So let's first of all identify the difference between unicast and multicast communication.
So let's say we have a server here, and let's focus on unicast right now.
If I had a video on this server, if I had a video on that server, and this PC wanted
to watch that video, unicast, what do we do?
We go, we double-click on whatever the video image is or the video is so we can go ahead
and watch it, and we watch it.
That will produce a stream from here to here so we can watch, unicast, right?
It's no different than if you go to a website and want to open an image or download a text
document, right?
Everything you do, that's unicast.
So you want to open an image, you open it up.
That's a unicast stream.
You want to open a Word doc, review it on a file server, that would be a unicast stream.
So for every person that clicks on that, every person that uses it, that's an individual
stream of communication that's happening.
So when PC3 comes along and says, oh, I want to watch that video, they go ahead, they click
on it, they get to watch the video.
Now for every single instance of communication, the server basically makes a different connection
to those users, and the server is going to then show you the video individually.
So PC1 is watching it individually, PC3 is watching it individually.
What does that mean?
It means that we can start it, we can stop it, we can pause it, we can do anything we
want to do with it, because that is specifically for us at that very specific moment in time.
So just to let you know, Netflix is not multicast.
Netflix is unicast, okay?
YouTube is unicast, Disney Plus is unicast, Amazon Prime is unicast, all of that stuff
is unicast, why?
Because when I want to watch something, I open up my account, I open up my app, I click
on it, and I watch what I want to watch, when I want to watch it.
And then you watch what you want to watch when you want to watch it, and if you want
to pause it and go to the bathroom, you absolutely can, and that doesn't affect me, it doesn't
affect anybody else, that is unicast.
But think about it, if there's a million people watching that show, then there's a
million different streams, there's a million different instances of that video playing.
Now you might be saying, well, so why not multicast?
Because it's the internet.
For multicast to be used on the internet, that means every single service provider is
going to have to get together and build a massive, giant multicast network to make that
work.
When we use multicast, we have to realize that you are now bound, essentially, by when
the server is streaming it, versus when you want to watch it.
So for example, if I say this is streaming at 1pm, out it goes, and if you're not watching
it at 1pm, then you miss out.
That's the difference between unicast and multicast, right?
It's like broadcast television, right?
It's like broadcast television back in the day, just a little bit different, because
with broadcast television, we would broadcast to every single TV in that television provider's
network, and then with your little knob, or your little flicker, or whatever you had at
the time, on broadcast television, you would then tell your TV, I want to watch that.
But your TV was getting every single stream all at the exact same time.
But with multicast now, you actually tell the network what you want to join, what you
want to watch.
So modern day television, where you have thousands of channels, 4k, that is multicast within
the service provider's network, right?
It's not over the internet, it's over their multicast network that's using the same cable
as your internet connection, but they're like different virtual networks in there,
ones for the multicast stream for your TV, essentially.
So when it's all said and done, when you want to watch, let's say, NFL football on Sunday,
you know it's playing at, let's say, 1 o'clock, 1 in the afternoon, 1pm is kickoff time, Eastern.
So what do you do?
You go ahead and you click on that at 1 o'clock, and then you get to watch the stream.
Now could you pause it?
Yes, but that's only if you have a PVR or a DVR.
If you didn't have that, you have no choice but to watch that stream at that moment in time.
Right, so a PVR or DVR is only recording the multicast stream for you, so that way there
you can rewind, pause, do whatever you want, and then catch up after the fact, that's all
it's doing for you.
But that multicast stream is going, and if you're not tuned in, you're not getting it.
All right?
So yes, typical television is multicast, on demand is unicast, essentially you can put
it that way.
All right?
Because for it to be on demand, you need to be able to start it and stop it when you want
to, not when they're streaming it.
So even with your television provider, if you are watching it live, right then and there,
that's your multicast stream.
But if you're watching it later as a recording, on demand, playback, whatever they have as
an additional feature, that would be unicast at that point in time as well.
So typically they offer both nowadays, because that's what people want.
If I missed it live, I want to go ahead and watch it.
So the great thing about multicast is the extreme reduction in bandwidth.
So think about an audio.
If we had, for example, music on hold.
If music on hold for voice over IP was unicast, as you can see, the number of people on hold
the audio stream would significantly consume more and more traffic depending on the number
of people on hold.
So a hundred people on hold increases our traffic.
But look at the multicast stream.
A hundred people on hold with a multicast stream doesn't change the bandwidth.
It's the same.
And why is that?
Because there's only one stream going out, and then everybody's tapping into it.
Whereas with unicast, everybody has their own stream all the way back to the server.
Whereas a multicast, everybody's sharing the same stream when it's all said and done.
So what does that mean for multicast?
You need to have a network that can support this.
That's why you don't see it used all over the internet, because the ISPs are not going
to come together and build a nice, cohesive, wonderful multicast network that can be consumed
by all.
Because who's going to make the money off of that, right?
They're going to constantly be in court over stuff like that.
So it all starts with what?
Making sure you have what is called multicast groups.
So a multicast group, for example, 239.0.0.5.
A multicast group is an IP address.
And that specific IP address is associated with something very specific.
So for example, if we just use a typical modern-day television company, they might have, for example,
channel 621 is a certain multicast group address.
Channel 632 is a certain multicast group address.
Channel 6 is a different multicast group.
So when you click on the guide and you say, I want this channel, you are basically telling
the network you want the stream for that particular group.
Now when it comes to multicast addressing, there are many different ranges of multicast
addresses.
Remember, when we had our OSPF discussion, we did 224.0.0.5 and 6.
And then for EIGRP, we have 224.0.0.10.
Remember I said those were non-routable multicast addresses, meaning they're not even routable
inside your network, outside your network.
It says right here, look at this, non-routable.
These are for local subnetworks.
So that's why it makes sense to use those for EIGRP and OSPF.
So you're not going to use those for multicast streaming, as an example.
And if you notice here, there's some that are reserved for internet control, ad hoc
blocks, source-specific multicast, glop addressing, not exam relevant.
But you'll see here that typically the 239 range, administratively scoped, is what would
be utilized for multicast networks for streaming services.
When I say streaming, I don't mean Netflix, remember.
I mean streaming inside your corporate environment, videos, audio, whatever it needs to be.
And when I say stream, I mean like continuous streaming of stuff that if you're not tuned
in at this particular time, you don't get to watch it or listen to it.
Music on hold's a good example, right?
When you're on hold, you just pick up wherever that music is.
You don't get – you don't start at the beginning of that audio file.
You just pick up wherever that music is when you're put on hold.
So typically, we'll be in this range down here.
But if you're using source-specific multicast, then you'll be in this range right here.
We'll talk about source-specific multicast a little later.
So, the range is from 224 for multicast all the way up to 239, 255, 255, 255.
So, you would have to create your groups in order to make this work.
Now, you're not going to have to create groups on the exam.
That's perfectly fine.
But then your apps and services are going to have to be designed for those particular groups.
For example, we'd have to have an app on this, right?
Either a web app or a desktop-related app.
So, it could be an app that's in the web browser.
It could be an app that's on the desktop.
Whatever it is, that gives us the ability to pick and choose our multicast group.
So, on the phone, you put the hold button or you're put on hold.
It automatically then joins you to that particular multicast group.
So, let's say this button right here, this button is linked to 239.0.0.5 in that actual app.
So, whenever I push that button or maybe the whole app is associated with that group maybe, right?
It really all depends on how you've developed it.
But in the end, what it does is it triggers you.
It triggers you to send out a message that then modifies what's happening here.
That's right. I said modifies what's happening here for you to get your stream.
It's the network that changes to deliver your stream when we deal with multicast.
So, think about your television right now.
And you're using a guided television service from your service provider.
And you want to watch, let's say, channel 621.
Let's say, let's just pretend that, ooh, the golf channel.
No one else in your neighborhood likes golf.
They hate golf.
So, nobody's ever watching it.
What would that mean in that particular case?
Let's say this is your entire neighborhood.
This is your neighborhood.
All of these are TVs.
Then that means the stream, if nobody's watching golf channel, the stream is never coming to your neighborhood.
But then as soon as you click on this, channel 621, what does that do?
It triggers a message to be sent, which ultimately then forces the network,
the network to send the stream down to you.
And now let's say your neighbor down the road turns around and they're like,
oh, I don't really like golf, but there's nothing else on TV,
so I'm going to go to channel 621 and watch golf today.
They push the button, and then what happens?
They send out a message, but great news, the stream's already here.
The stream's already here.
So, what does that mean?
Just send it from here.
That's it.
Done.
So, notice that the bandwidth has not changed here.
The bandwidth is steady.
The only thing here is we've had to duplicate it and send it down to the TVs as an example.
That's it.
I'm just trying to give you a real-world example of what multicast does for us.
So, in your environment, if you have videos you want to stream all day long
or you have audio you want to stream all day long,
and it's not something that a user has to start or stop from the beginning
or anything like that, then multicast might be the thing you want to do in the environment
to make sure that that audio and video is not consuming more bandwidth
than you absolutely want it to when it's all said and done.
So, protocols used by multicast that you need to know for the exam are IGMP and PIM.
IGMP is what?
It's used between hosts and what does it say there?
Routers.
Hosts and routers.
IGMP stands for Internet Group Management Protocol.
Internet Group Management Protocol.
And it's used between what?
Hosts and routers.
Remember that for the exam.
Hosts and routers.
What is a host?
Your PCs.
What is the router?
The default gateway.
So, we would be running IGMP here.
So, for example, we would be running IGMP in here.
We would be running IGMP in here.
That's where we would be running it.
It wouldn't be running in here.
It would be running here.
And so, with IGMP now, we are going to be able to communicate between our hosts
and our routers so that way we can join, leave, or remain in a group.
Join, leave, or remain in a group.
Remember that.
Your goal here is to be able to describe multicast protocols.
That's what we're doing right now for the exam.
So, for example, here's my default gateway.
Remember, we have redundant default gateways, so let's get that out of the way first.
If I have more than one default gateway like we have here, one of them has to be elected
as the overseer of this IGMP environment.
So, we definitely want to line this up with who?
We want to line this up with our default gateway.
We want to line this up with our what?
Our spanning tree protocol root bridge as an example.
So, in this case, it's going to be this one here.
And so, this is the one that's going to be responsible for everything, and this will be its backup
when it's all said and done.
Remember, you don't have to configure this or verify this or set this up, any of this.
It's about understanding that we are going to have to have one and only one device responsible
for IGMP in that environment, even if there's multiple gateways.
And by default, it'll be the one with the lower interface IP address, but obviously,
it's something that you can manipulate if you want to manually.
We call this also the IGMP query, courier?
Yes, courier, the IGMP courier.
So, your client, whenever you open the app, click something, whatever it is.
Let's say you want to join this group.
How do you know you're joining that group?
You don't.
What you know is you want to watch this, you want to listen to that, you want to do this,
and the app is telling you what you have access to.
And remember, this is already streaming.
How far?
Well, if nobody's using it, then it's only streaming this far.
That's it.
But let's say somebody down here is already watching it, then it's streaming over here
potentially right now.
So, it really depends.
Is anybody watching it or not?
Nobody's watching it?
Then the stream only goes as far as its own default gateway.
If people are watching it, then it's already throughout the environment.
So, you want to join?
What do you do?
You send an IGMP report.
So, to join, you send what is called an IGMP report.
So, what I'm doing is I'm sending this message out, and it's a non-routable message, meaning
that it only stays within my subnet, my VLAN, my broadcast domain.
And then what's going to happen?
Well, this is the router that's responsible for joining me to groups and doing all of
that stuff right now.
So, it eventually gets to that device.
And again, right, if that's the root bridge, that's our active forwarder, it makes sense
to line this up because traffic's going to flow this way for that subnet, that VLAN,
that broadcast domain.
So, we want to make sure that it's not doing something like this in order to get there.
So, again, your Layer 2 network has to be designed properly to make sure we get the
best performance out of all of this stuff.
Now, once that happens, this router, if the stream is already coming to it, it'll then
just send the stream down to that user.
If the stream's not already coming to it, then it has to use PIM.
So, PIM, that we'll talk about later, is used up here.
So, IGMP is only used here, as we said.
PIM's used up here.
And now, I'm not talking about PIM particles, all right, if you're a Marvel MCU fan or any
type of Marvel fan, and not PIM particles, all right, just protocol independent multicast
PIM.
So, PIM would then be used from here to here in order to get the stream down to DSW1.
So, let's say the stream now comes down here.
So, IGMP's in here.
Important for your exam.
All right, so now, what happens now?
Well, the stream can now go down to the user.
Anytime you want to leave the group, maybe you close the app, you hit X, anything like
that, then you automatically send an IGMP leave.
Obviously, you have to be coded to do that.
If you're not coded to do that, probably in the app, then it's not going to happen, okay?
So, join is an IGMP report, and to leave, it is an IGMP leave.
So, when I want to leave a group, I'll send up my message.
The default gateway gets it.
And then, what's going to happen?
Well, the default gateway is not going to stop the stream, because you have to remember
that the stream is coming down to here, and then I'm branched off of that.
So, if the default gateway stops the stream, then that means anybody else down here would
no longer get the stream as well.
So, DSW1 has to be careful here.
Remember, it's called the IGMP querier, and that's called that for a reason, because now
it has to query.
It has to send out a message, a query message, asking if anyone else still needs the stream
for that group.
So, when I say I'm leaving 239005, when the router gets it, it then has to send a message
saying anybody else still need the stream for 239005.
If no one responds, then I cut the stream off.
If at least one device responds, then I don't cut the stream off, which means the stream
will keep going down to here.
But the thing is, is you no longer have the app open.
You've closed the app.
You're done with it.
What does that mean?
It means you're not going to get it anymore, because the switch down here is going to make
sure you don't get it anymore by adjusting its multicast table.
Periodically, the querier is going to send out IGMP queries, periodically, just to ask,
hey, anybody down here still need a stream?
Anybody down here?
Why?
Because there is never, there is never a, there's no table or anything, for example,
on DSW1 that says, oh, I'm sending a stream to so and so and so and so and so and so and
so in that particular regard, meaning I'm not keeping track of stateful streams, as
an example.
So because of that, I have to query every so often to determine if there's anyone out
there that still needs the stream.
And if nobody responds, then I'll stop the stream.
But if one device at least responds, then I'll keep the stream up and running.
This is also important, because if there's ever a failure of the network down here, if
there's ever a failure, then that means no leave messages would have been sent, which
means the router is going to keep sending messages, because it doesn't know otherwise.
So if it sends out a query periodically, and there's a network disaster down here somewhere,
then it will at least know, oh, nobody's responded, I can stop the stream now.
So these are the little things I want you to remember for the certification exam when
it comes to IGMP joins, so the IGMP report, the query, and the leave message.
Now, we have two versions that you can utilize today for IGMP, version 2 and version 3.
The main thing I want you to remember about the difference between these two is in regards
to your ability to specify a source of the stream or not to be able to specify the source
of the stream.
With IGMP v2, you cannot specify the source of a stream.
With IGMP v2, it's known as star comma G, so that's source comma destination.
So star in this case equals any source, and then G equals the group number, meaning that
when I send out my IGMP message using IGMP version 2, it would be star comma 239.0.0.5.
So any source that is providing that particular stream for 239.0.0.5.
Now, if you notice here, I have two servers, so that means I could end up with a stream
from either of those two servers, and in reality, that's fine.
Nothing wrong with that.
But the question now is, what if there's a rogue device over here?
Somebody managed to set up a rogue server that is streaming inappropriate content.
Let's say its address is 10.0.120.5.
It's streaming inappropriate content.
Well, then that means because it says star for any source, and it's streaming inappropriate
content for 239.0.0.5, is it possible that some of the users are going to end up with
the inappropriate content if we're using IGMP v2?
Of course, because you're saying any source providing that stream.
So whatever one you get is what you get.
So there is a lack of security, as you can see in this particular case.
And anybody who introduces a rogue server streaming for that group could ultimately
interfere with our stream.
With IGMP v3, you'll see here that we can do what is called source-specific multicast.
So we have the opportunity to do the same thing that we saw here, but we have the opportunity
to do this as well now.
So IGMP v3 is the better option.
And it is not compatible with v2.
It's not compatible with v1, which I don't even have listed here because you don't really
want to use v1.
But IGMP v2 is compatible with v1.
So v1 and v2 are compatible, but v3 is not compatible with any of them.
Remember that.
But in this case here, s, g.
So what does that mean?
It means we can be very specific.
So s equals specific source.
And g equals group number.
So what does that mean?
It means that when you click on something, now we could have 10.0.100.18 as the source,
with the group being 239.0.0.5.
So now if this stream is actually there sending out, I'm not going to get it because it's
source-specific multicast.
So if you're ever asked which is more secure, it's IGMP v3 because why?
Source-specific multicast.
Now, there are other things about it too, but it's way beyond the scope of the course
and certification exam, folks.
And you would learn all about the intricate details of all of this stuff in multicast
courses, which are large courses in and of themselves.
Lastly, what I want to point out to you is that your switch, by default, doesn't understand
the difference between multicast and broadcast.
It thinks they are the exact same.
So what does that mean?
It means when a multicast message comes down, it gets flooded out all ports except the port
it came in on in that subnet, in that VLAN, in that broadcast domain, just like broadcast
traffic and unknown unicast traffic.
So you can think of this as unknown traffic.
So it gets flooded out all ports except the port it came in on.
We don't want that because what that means is that if somebody wants the stream, then
everybody automatically gets it, whether you have the app open or not, which means your
PC has to constantly get those multicast frames, process them, and discard them, discard
them, discard them, discard them, which results in your CPU on your PC having to do work that
you don't want it to do.
So that would absolutely increase the bandwidth and resource consumption of your PC's CPU.
So what you need to do is you need to make sure that you have the ability to filter that
multicast traffic on your access layer switches.
And that's where IGMP snooping comes into play.
So with IGMP snooping, when you turn it on, you are snooping, sniffing out multicast packets.
So when you realize that an IGMP report message, a join message comes in, then you'll have
the ability to make a note in your multicast table that the traffic only goes out this
way right now for that.
It doesn't go out anywhere else.
And then if this PC joins, then you know that you're going to want to send it out this way
as well.
And then when the leave message comes, then you can remove that so it no longer goes that
way.
So the IGMP snooping feature permits the switch to forward multicast frames for them instead
of flooding them, and therefore reduce bandwidth consumption for your multicast stream to the
end users.
All right, so that's just IGMP.
Now we want to talk about PIMP, Protocol Independent Multicast, so you can pick it out of the
lineup on the certification exam.
So you already know the difference between the two, right?
We said IGMP works between the PCs and their default gateway.
So for example, IGMP would be running here.
But PIMP, PIMP would be running, for example,
I'll have to draw this.
Did you get the picture?
On every other router interface, that goes to another router.
So I'm running PIMP here, here, here, here, here, here, here.
I'm running PIMP here, here, here, here, here, here, here.
That's a better way to represent it.
I'm running PIMP in all of those places.
Why?
So we can build what is called our multicast tree, used by our routers to build the multicast
tree.
Remember that.
And the multicast tree is going to be used to what?
Forward multicast stream through the network.
Now, let's be clear about something here as well.
You still have to have an underlying dynamic routing protocol for unicast traffic running.
OSPF, EIGRP, ISAS is an example.
You need to have full, full, full unicast connectivity with your dynamic routing protocols
before you can even set up multicast.
Because multicast PIMP just runs on top of everything.
And the decisions PIMP typically makes is going to be based on what?
The underlying decisions that your dynamic routing protocols have already made.
Or your static routing has already made.
So essentially, you need to have a fully developed network using static routing, dynamic routing
underneath, so that way their PIMP can do its job.
So the multicast table is essentially going to be built based on what your unicast protocols
have already decided about the best, quickest, shortest way to forward traffic.
So PIMP runs on top of all that stuff.
So PIMP has different modes, and you'll be able to have to pick them out of the lineup
of the exam potentially.
Dense mode, sparse mode, sparse dense mode, and bidirectional.
So basically, what I have on the slides is going to help you prepare for the exam.
So what is dense mode?
First and foremost, we call it one to many.
One to many, which means what?
One source going to many different devices.
So one source here, server here.
That's my server.
That's my source.
And then you've got many, many, many, many different clients that want that stream, that
multicast stream.
It is a push model.
Remember that.
Push model.
If you don't know that, don't sit for the exam.
A push model that what?
Floods multicast to every corner of the network, regardless of users wanting the stream or
not.
This is how it starts up.
So when I start this multicast stream up, what's going to happen with PIMP is that it's
going to flood that stream everywhere.
It's going to flood it everywhere to all the routers with PIMP.
So it's not going to go right down to the users.
It's going to go right to the edge routers.
Or right to the edge, I should say, of those environments to those routers.
But it's not going to go into the IGMP environment.
All right.
So there you go.
It's going to start there.
Beautiful.
So this is essentially what's going to happen here in the beginning.
We push it out.
And then what has to happen, the routers are going to build the tree backwards, backwards,
backwards, backwards, backwards.
So let's say there is somebody here that wants the stream.
And there is somebody here that wants the stream.
What does that mean?
It means this router is like, well, nobody wants the stream.
So using PIMP, they're going to stop that from happening.
Nobody here wants it.
So that'll be removed.
Nobody over here wants it.
So this can be removed.
Nobody over here wants it.
So this can be removed.
Nobody in here wants it.
So that can be removed.
Nobody there.
So that can be removed.
All right.
Now we have our tree.
So our tree looks like this right now.
And then let's say somebody else wants it here after.
Well, that's easy.
I send my IGMP message.
PIMP tells this router who tells this router.
And then they send the stream from there down to here.
So that's the job of PIMP.
And so dense mode is flood and prune.
Remember that.
Flood it out and then prune back.
It was the very first version of multicast.
So really great for environments where you have large amounts of receivers everywhere that need this stream.
The basic assumption behind dense mode is that everyone wants this,
or more than 50% of the users out there need this stream.
So we might as well just get it as fast as we can to all the different destinations that are out there where the users live.
And then whoever doesn't need it will just pull back from there.
So that way there we can just get it out there as fast as possible.
So sparse mode is the complete opposite.
So sparse mode is still one of many, but it's a pull model.
And it's going to deliver the multicast streams to only those networks with end users that have requested the stream.
So, for example, here's your server.
The stream only goes this far.
Remember, with flood and prune, the stream goes all the way there and then gets pulled back.
With sparse mode, that's it.
Boom.
There's your stream.
Until people start asking for it.
So let's say you have your user here.
I ask for it using IGMP.
PIM is then used to tell this router, who then tells this router, who then sends the stream.
And so then all of a sudden there's a user here that comes online.
I use IGMP to tell this router.
This router uses PIM to tell this router.
There you go.
The stream is now there.
And so on and so forth.
So from the beginning, the very beginning, we just start the stream and it doesn't go anywhere unless people are asking for it.
So in this particular case, it's really good for those environments where your users are sparse.
Only a few users need it here sometimes, over here sometimes, over here sometimes, over here sometimes.
And as a result, when they want it, they're going to have to request for it and ask it.
Now, with that in mind, sometimes sparse mode is not going to perform as well as we want it to.
And the reason why is because of how your network is set up.
Wherever your streamer is, your source is, that's typically far off somewhere, like in the corner of your data center, let's say, as an example.
And the data center resources are not necessarily really close to the users.
So if you think about all the users down here in this part of the environment, it could take a while for them to start getting that stream when they want it because it's so far away.
Whereas with flood and prune, it was flooded everywhere.
With dense mode, everybody got it, right?
It was everywhere, so it was really easy, really quick.
But in this case, it could be slow.
We call it spin-up time.
It could be slow here.
So instead, what we do is we have the rendezvous point.
The rendezvous point is going to be some centralized router.
This is important for the example.
The rendezvous point is going to be some centralized router that we have that is going to be the meeting place for sparse mode.
What does that mean?
It means that our source traffic is always going to be sent to the rendezvous point whether it needs it or not.
So let's say it's being sent.
Let's just say for fun it's being sent this way.
So the rendezvous point is always getting the stream.
And so now what does that mean?
It means anybody in our environment who needs that stream, let's say you have a user here.
They send their IGMP query.
This router is going to contact the rendezvous point indicating that it needs the stream.
The stream is then going to be sent down to the user from the rendezvous point.
So build trees based on requests is the key for sparse mode.
However, this is suboptimal, isn't it, folks?
You see that path?
Very suboptimal.
The great thing about PIM with rendezvous points is that the rendezvous point is for what purpose?
To basically just set up the initial connection, the communication.
It is only needed to start that session for the client between the source and the receiver.
In this case, is there a shorter path that could be used for the stream?
Yes, there is.
What happens automatically now is that the network will adjust and will start sending the stream this way as well now.
And this can be removed.
So you see how the tree was built on the fly now.
So the rendezvous point, remember, this is only needed to start a new session between the sources and receivers.
And if there's a shorter path, a better way to go, the network will adjust and change for multicast so the stream can go.
Keep that in mind for the certification exam.
All right, so now you know dense mode, you know sparse mode.
You know the keywords.
You know the buzzwords.
You know what the rendezvous point is.
Sparse dense mode is a combination of two.
Just think about a scenario where part of your network you want to flood and prune because there's a lot of users down there that need the multicast stream.
Flood and prune instead.
And there's another part of your network that is sparse.
Well, then you can do both.
Sparse dense mode, pull or push model based on the group requirements.
So any scenario on the exam that says you have a few users that need the multicast stream, your answer is sparse mode.
Where they said you have lots and lots of users that need, that's dense mode you're going to use.
If they say you have a combination and different parts of your network, that's sparse dense mode, okay?
Keep it as simple as that for the certification exam.
Now, the last one here, bidirectional, is different.
It really is.
Why?
Just think about, first of all, what's happening with all the other three.
The other three have a very specific source, and then you have a multitude of receivers.
So, for example, for every multicast stream I would have a different source, a different group address, so 239.001, 239.002, 239.003, right?
Every single source would have a different stream, a different address, and then I have all my users, right?
And what happens?
We stream from there to whoever needs it.
Bidirectional is when you have many, many, many sources and many, many receivers all communicating with each other.
Think of, for example, like an in-house video conferencing solution, right?
If I'm an in-house video conferencing solution, then what happens?
We're all senders and we're all receivers all at the exact same time.
So you don't just have one sender and a bunch of receivers.
Everyone's a sender and everyone's a receiver all at the exact same time, right?
Don't think that's Zoom.
No, Zoom is not that.
Microsoft Teams is not that.
Skype is not that, right?
Why?
Because in that case, we're using unicast for that.
We're not using multicast for those types of scenarios, and there's typically a centralized server in play for those communications.
But any scenario where they're talking about needing a solution for multicast whereby many senders and many receivers all exist for one group, many senders in a group, many receivers in a group, think bidirectional.
And it's a pull model designed for many to many applications.
Now, some of your environments are going to have what?
You are going to have multiple PIM domains, PIM sparse mode domains, I should say.
So when you have multiple PIM sparse mode domains, what does that mean?
You have a multicast tree here.
You have a different multicast tree here.
That is a possibility.
And as a result of that, how could you have these different trees actually connect together?
Well, that is where you use PIM MSDP, Multicast Source Discovery Protocol.
And what happens here is that the rendezvous points are going to be linked together, essentially.
So I have different PIM environments, PIM sparse mode environments, each with their own rendezvous points.
And so now what happens is I could be here as a receiver, but the source could be in a totally different tree by me understanding how to get there through this rendezvous point over to the other rendezvous point into that environment to get that.
So on the exam, if there is any scenario that talks about you having multiple PIM sparse mode domains, therefore you have multiple rendezvous points, therefore you have two totally separate trees, you use Multicast Source Discovery Protocol, so that way there you can interconnect those two environments together.
And that uses what?
BGP in order to accomplish it.
All right, so the rendezvous points will exchange source information with other rendezvous points in other domains.
That's what you need to know.
All right, now PIM reverse path forwarding, what does that mean?
So this is just a safety check.
That's all it is, a safety check.
So anytime you see PIM RPF, reverse path forwarding, it is a check.
A check for what?
A check to make sure that the path is loop free.
It's loop free.
It's to prevent multicast loops.
Because the last thing we want, for example, is our traffic to, let's say, I'll just do this.
Loop, right?
We don't want this to happen ever.
Because that would be bad.
That should never happen.
Our tree should start at the source and end at the users, and it should never loop back on itself, ever.
So the PIM reverse path forwarding feature is going to be used to check what?
To check that the multicast packet that was received on an interface is valid in relation to our unicast routing table.
Yes.
What does that mean?
Okay.
So let's say a multicast packet arrives in this interface, and it's destined for here.
With this check, the router says, I just received that multicast packet from source 10.0.100.1.
Based on my unicast routing table, is that the way I go to get there?
If the answer is yes, then I'm allowed to forward that down to where it needs to go.
If the answer is no, then I have to drop that packet.
Because if the answer is no, then we could have a routing loop on our hands.
And we don't want the tree to cause a routing loop.
So here's an example of that.
Let's say we receive the packet this way.
And so I check, is this the way I go to get to this address right here, based on my unicast routing table?
Based on my unicast routing table.
Let's say the unicast routing table is pointing this way.
If the unicast routing table is pointing that way, then I drop it because that tree is not right.
That's all this does.
Source address of incoming multicast packet is checked against the unicast routing table.
Make sure you know that.
Why?
To prevent loops.
Alright, so that is IGMP.
That is PIM for the certification exam.
Now you know how the magic happens in multicasting.
You've got a lot of different terms and definitions that you'll want to know for the certification exam.