So to really appreciate multi-cast, let's first of all talk about some other
traffic patterns.
And the first I'd like to chat about is unicast.
And unicast is a traffic that I think most people think of when they think of
IP traffic.
It's traffic from one source IP address going to a specific destination address
.
An example would be this client here at 101050 making request, going up to the
server at 23.1.2.100.
And even though there may be napping used here at this edge router, we still
have a single source address going to a single destination address. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
have a single source address going to a single destination address.
After the reply traffic, it'd be a single source address here going back to a
single destination address.
Or at this point, what are the net address was, then the end translation
happens,
and then that traffic is then routed back down to the client after the end
translation happens here.
But either way, the concept of unicast is one source address, one destination
address.
Now, what other kind of options do we have?
Well, we also have broadcasts.
So I clean up my markings over here.
And a broadcast is from one source to all destinations. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And a broadcast is from one source to all destinations.
So that's most typical in a protocol like ARP, which is looking for, for
example, the layer two address of another device on the same local network.
Let's imagine it's this PC right here doing an ARP request that ARP request
goes into this network, the 10100 network, and that corresponding layer two
broadcast domain.
And that broadcast is sent to all other devices on the network segment.
So if there's 100 devices here, all of them are going to see that broadcast
message sent by the ARP.
And then the device that has the corresponding layer three address would
respond back. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
respond back.
But the initial request, the ARP request, is going to be a broadcast sent from
one source device to all of the other devices on the local subnet.
So let me clean this up a little bit.
And let me clean this up a little bit as well, make it a little bit more tidy
for us.
So unicast is one source IP going to one destination IP broadcast is from one
source IP.
And that would also include broadcast or sent when we don't have a layer three
address.
For example, if a client is doing a discover message with DHCP, that's going to
be a broadcast, but the client does not yet have an IP address.
But the concept is the same as coming from one source and it's being sent to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But the concept is the same as coming from one source and it's being sent to
all other devices on that network segment.
So I switch when it receives a broadcast frame that comes in, for example, on a
port associated with VLAN one, it's going to for that frame out all other ports
associated with that same VLAN.
So we've taken a look at unicast and broadcast.
So what is this wonderful magical thing called multicast?
And here's the secret.
We're going to have one source and for our discussion, let's imagine that we
have content that is being sent from this server into the network.
So that's our source at 23.1.2.100. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So that's our source at 23.1.2.100.
But instead of sending it to one specific IP address that represents a single
device on the network.
And instead of sending it to all devices in the case of a broadcast, instead
this time we're going to go ahead and send it to some.
And sometimes that's referred to as many, but not all.
Now, how in the world do you have a server send traffic to some devices or many
devices, but not all devices?
And the answer is we are going to send the destination to a specific type of
layer three address and that's a multicast address. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
layer three address and that's a multicast address.
That's a class D address and that range is the first octet being 224 through
239.
So IP address starts with a 224 all the way through 239 is a class D address
and that is a multicast address.
And here's something that I didn't really grasp immediately many decades ago
when I started learning multicast is that when we have a multicast address, let
's say for example, 224.67.8.3.
That not only is a multicast address, but it's also referred to as a multicast WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
That not only is a multicast address, but it's also referred to as a multicast
group.
Let's imagine that the server is pumping out content to 224.67.8.3.
That multicast group address.
How in the world is the network going to be able to forward this multicast
group content down to, for example, a client down here that would like to
receive it?
And that's the topic I'd like to address next in this overview and explain how
that traffic sent to this group address is being able to be delivered down here
to this client.
So let me clean up a little bit of space and let's talk about the details about WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So let me clean up a little bit of space and let's talk about the details about
delivering multicast across a network.
And I'm going to refer to that as multicast routing, the ability for routers
who see a multicast group destination address to be able to forward it through
the network.
So the first step here is we need to do enable multicast routing on our routers
.
So once we've enabled multicast routing on our one and our two and our three
and our four, they'll be able to go ahead and then for that traffic down to the
clients that need it.
Now, there are several different options regarding multicast routing and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now, there are several different options regarding multicast routing and
setting it up.
But one of the most popular and traditional methods is to use a protocol for
multicast routing called PIM.
Now PIM itself, that acronym stands for protocol independent multicast.
And here's what that means in a Cisco world.
If we set up PIM multicast routing on these devices, they are going to use our
one, our two and our four and our three.
They're going to use their IP routing tables and the thing about protocol
independent multicast is it doesn't matter how those IP routing tables got WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
independent multicast is it doesn't matter how those IP routing tables got
populated.
We could be using any type of routing protocol to train these routers on how to
make forwarding decisions for normal IP traffic.
So we could use things like OSPF or RIP, Heaven Help was there or EIGRP or BGP.
It doesn't matter to protocol independent multicast how the unicast routing
tables got populated, but it's leveraging that.
And that's why it's called protocol independent multicast.
As long as our IP routing to start with works OK, we can overlay protocol WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
As long as our IP routing to start with works OK, we can overlay protocol
independent multicast routing on top of it.
And that's why it's called independent.
It's independent of the method we use to populate the IP unicast routing tables
.
So I'm going to clean that up just a little bit and let's talk about how PIM is
going to work.
PIM has a couple of options.
One's called sparse mode and the other is called dense mode.
And there's a few different options regarding each of those and how to set it
up.
But the basic concept of sparse mode is this.
If we have all these routers set up for multicast routing and the routers see WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
If we have all these routers set up for multicast routing and the routers see
this stream of traffic going to this multicast group 224 67.8.3
by default with sparse mode, they're not going to bother forwarding it through
the network.
There's something going to say, you know what, we don't have any clients that
we know of that need it.
So we're not going to forward it.
That's what sparse mode is all about.
It's about saving bandwidth, not forwarding traffic where it doesn't need to go
.
Now dense mode on the other hand takes the attitude of, well, you know what, if
we see a multicast destination address,
we're just going to automatically forward it down through the network.
And the reason it's called dense mode is that perhaps we had a large number of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And the reason it's called dense mode is that perhaps we had a large number of
devices that needed to join a multicast group and receive that content.
That'd be another way of saying we have a dense population or a great
population of devices that need that stream.
And then dense mode might be justifiable in that case because we're going to go
ahead and start forwarding it no matter what.
So if there's lots of clients, it's possible they could get that a teeny bit
faster than if the network had to figure out where all the receivers are.
So for our discussion regarding protocol independent multicast, I'm going to
focus on sparse mode for the remainder of our discussions. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
focus on sparse mode for the remainder of our discussions.
So for our next magic trick here is how do we let these routers know if we have
sparse mode?
How do we let them know that this client down here at 1010 050 would like to
receive the traffic for that multicast group to 24 dot 67 dot 83?
And the answer is this client is going to start the process by saying, you know
what?
I would love to receive that multicast group stream if it's available.
So it starts by this client here joining the multicast group. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So it starts by this client here joining the multicast group.
And again, when I talk about joining group, think of it like this client saying
, you know what?
I would really love to see the stream of traffic if it shows up.
That's what joining a group means.
It means it wants to go ahead and see that multicast stream if it's present on
the network.
Now, if there's no server or nothing else pumping up that content, of course,
this guy is not going to get the traffic it needs.
But assuming that that multicast content is being sent on the network and this
client has joined and would like to receive it, that's an indication of this
network.
They need to deliver that traffic down to this client so you can go ahead and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
They need to deliver that traffic down to this client so you can go ahead and
consume it and see it.
An example of that would be this little client's running a multimedia player
that receives or is able to receive multicast content.
And so when the client launches their application and then says they want to
join that group or receive that stream of traffic, that's what triggers the
join request to go into the network from this client.
Now, that join request in the background is using a protocol called IGMP, not
to be confused with ICMP,
but IGMP is the internet group, hence multicast groups, management protocol. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
but IGMP is the internet group, hence multicast groups, management protocol.
So in the background, when this client is joining a group or says in the
interface of the software, I want to see the multicast stream for 2.2467.8.3 in
the background,
it's actually using this protocol, IGMP, internet group, management protocol to
do that join, which indicates to the network that, hey, if that content's
available, please deliver it down to this client.
Now, there's three different versions of IGMP, there's version 1, which was the
original flavor, there's version 2 that was more effective, and there's also a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
original flavor, there's version 2 that was more effective, and there's also a
version 3,
which allows for something called source specific multicast, which takes into
consideration not just the destination multicast group, but also it takes into
consideration the source of the server who's actually sending that content.
And we'll save the whole discussion for source specific multicast for another
set of videos in another course.
But for now, I just want you to be aware that if a client is making a join
request for a multicast group, it's going to be using IGMP.
So let's imagine this client has launched some software like VLC or some other WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So let's imagine this client has launched some software like VLC or some other
software that can process and receive multicast group streams,
and they want to join the group 2.2467.83.
Let's also imagine for this discussion that this client is going to be using I
GMP version 2.
So it sends a join request.
So when the client joins that group, that 2.2467.83, that's what begins the
process of training the network that they need to forward that content should
they see it to 2.2467.83 down to this client.
So the next question I'd like to chat with you about is how in the world does WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So the next question I'd like to chat with you about is how in the world does
that happen?
I mean, what's the magic in sparse mode of allowing the traffic from the server
up here to be correctly routed all the way down to this client?
And the answer is in multicast routing, when setting up PIM and sparse mode, it
's going to use a tree structure.
And one thing about a tree, as the starting point for this, is a tree has
affected like one trunk.
So I'm going to go ahead and instead of calling it a trunk, which might be
confused with either 2.1Q, let's call this the base of the tree.
Now that base of the tree could be any one of these four routers. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now that base of the tree could be any one of these four routers.
So for our discussion, let's imagine we want the base of the tree to be this
one right here, R2, and we'll make that the base of the tree.
So let's go ahead and use R2's loopback address of 2.2.2.2.
So we can configure the entire network and back these four routers that the
base of the tree is 2.22, reachable right here at R2.
That's its loopback zero address.
And once we do that, any routers that see multicast destination content, what
they're going to do is they are going to simply send it.
So if there's multicast content here, the class D address range, and R1 sees it WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So if there's multicast content here, the class D address range, and R1 sees it
, it's going to forward it to R2.
If, for example, R3 sees multicast content, it's going to forward it to R2.
If R4 sees multicast content, it's going to forward it to R2 because that's the
base of the tree.
So using our example here, let me go ahead and clean this up a bit.
Let's imagine that we do have the server here that's pumping out content to 224
.67.83.
R4 sees that and immediately forwards it over based on a routing table, which I
think we'd go this way. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
think we'd go this way.
It's going to forward it over to R2 and based on Gigabit and OSPF, which I
currently have running,
and the reference bandwidth in place, the best path is going to be right here.
So now that traffic is being forwarded from the server through R4, through R3
based on the routing tables to R2,
who is the root or the base of the tree.
Now that base of the tree has a specific name in PIM and that's called an RP
and that stands for rendezvous point.
So whenever you see the concept of rendezvous point, think of it as like the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So whenever you see the concept of rendezvous point, think of it as like the
base of the tree,
where's the starting point for the dissemination and the propagation of our
multicast content.
Now in sparse mode, when R2 sees that multicast content, what's it going to do?
The answer is it's not going to forward it by default in sparse mode anywhere
until it knows that somebody needs that content.
So if this client computer here did a join request and let me put the join
request here in green.
So if it did join a request here, R1, who sees that join request, is going to
say,
"Whoa, I've got a client that needs it and it's going to communicate up to the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
"Whoa, I've got a client that needs it and it's going to communicate up to the
rendezvous point that it needs that traffic,
that it needs that flow of data, that it needs that multicast group stream."
So here it'd be IgMP, the client setting out, and then R1, it's messaging up to
the rendezvous point, would be using PIM.
Effectively saying, "Hey, you know what? I need this traffic."
Now once that all happens, R2 is going to change its mind about where it's
going to forward the traffic
and it'll start forwarding it out, gig 1/0.
At which point, the switch in its default state is going to forward that multic
ast traffic to all other ports WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
ast traffic to all other ports
or if something called IgMP snooping is on, it'll only forward it to ports that
need that.
So then the multicast traffic stream would be forwarded out, gig 1/0, gig 0/0
here on router 1 would see it,
and then R1 could then forward it down to the client who needs to get that data
.
And if there are local switches, which are likely to be there, if those
switches are doing IgMP snooping,
they would only bother forwarding that traffic down to the ports that need it.
Or in the case of a switch that's either a non-managed switch or a switch that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Or in the case of a switch that's either a non-managed switch or a switch that
does not have IgMP snooping enabled,
it would just forward that multicast traffic to all other ports in that
corresponding VLAN,
if it didn't know exactly which ports needed that.
However, most Cisco switches are going to have IgMP snooping on by default.
Also, before we finish this overview, let's chat about a feature called RPF.
And RPF stands for a reverse path forwarding check, that's why I call it an RPF
check.
And understand an RPF check, let me go ahead and clean up our PIM just a little WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And understand an RPF check, let me go ahead and clean up our PIM just a little
bit here.
And let's imagine we have that same multicast stream of 224.67.8.3.
And let's imagine that flow of traffic and it's still coming from this server
at 23.1.2.100.
Let's imagine that here on R1, it's receiving that multicast group stream here.
And it's also just for grains, let's imagine it's receiving it here.
Now, obviously, R1 does not need to send two copies of that multicast group of
224.67.83
that's coming from the server down to the client.
I mean, the client only needs one copy of each of the packets, it doesn't need WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I mean, the client only needs one copy of each of the packets, it doesn't need
two.
And that's where the RPF comes into play.
An RPF check is simply considering the source of the packet coming in.
And let's do that here on R1 regarding traffic coming in from 23.1.2.100.
So if that source traffic for this multicast group is coming in on gig zero
zero and coming on zero three slash one,
the RPF check on R1 is going to say, okay, pause for a moment and let's think
about this.
If I'm not saying I need to, but if I needed to forward a packet to 23.1.2.100, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
If I'm not saying I need to, but if I needed to forward a packet to 23.1.2.100,
the source, which interface would I use?
Would I use gig zero zero based on my IP routing table or would I use serial
three slash one?
And if the answer is gig zero zero and that's the interface where we receive
that multicast group information,
we're going to go ahead and forward.
I call that passing the RPF check.
So yes, I pass the check.
It came in on the interface I would use to forward back to the source.
I'm going to go ahead and forward, meaning forward out the other interfaces
where I have clients or other devices that need that multicast group stream. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
where I have clients or other devices that need that multicast group stream.
So next, let's consider the RPF check for that multicast group stream.
If it's received here on zero three slash one, if the router receives it here
and it looks at the source IP address of where the server is sending it from,
it would consider, okay, how do I reach 23.1.2.100?
If it's not this interface, that's considered failing the RPF check.
And as a result, we are not going to forward that multicast stream out any
other interfaces.
We're just going to begin to receive it because it's already there. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We're just going to begin to receive it because it's already there.
Nothing we can do about that, but we're not going to bother propagating it any
further down.
And that's what the RPF check is about.
It's about pausing for a moment in the mind of the router considering the
source, considering the interface that that traffic came in on.
And if it's a yes, I would use that same interface to reach the source.
That's an RPF check that says yes, I pass.
And as a result with multicast, it's going to forward it down the other
interfaces.
And if the traffic comes in on another interface like serial three slash one,
and it pauses to consider how do I reach the source address and it's not the
same interface there.
That's a failure of the RPF check. And as a result, the multicast group is not WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
That's a failure of the RPF check. And as a result, the multicast group is not
forwarded out of any other interfaces.
So now that we've taken a big picture, look at many of the features of multic
ast routing, in the next several videos, I'd like to walk you through step by
step the configuration and verification of multicast routing.
Not with an I-Torz making an expert at multicast routing, but rather, to help
reinforce the concepts of PIM and IgMP and how a sparse mode implementation of
PIM multicast routing.
And again, we'll do it step by step. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And again, we'll do it step by step.
Continue to the next video.
So I'll see you there in just a moment.