- [Narrator] Now let's talk about multicast
and some of the protocols
that make multicast work.
By the way,
if you look at the ENCOR exam blueprint,
which is needed to be able
to describe these protocols,
there's no configuration according
to the blueprint that we have
to do in regards to multicast.
Now, you'll certainly need
to know how to configure multicast
when you get into your CCIE studies.
But for now, we just need to understand the theory.
So let's begin by talking about why do we need it?
What is the benefit of multicast
and it's not that multicast is better than unicast,
or broadcasts all of the time.
But there's a time and a place for multicast.
For example, in this scenario,
we've got a video server
that wants to send out a video stream
to participants that want to receive the stream.
Now let's pretend
that this is a big corporate announcement.
And the CEO is going to make a big announcement at 10:00 a.m.
And everybody that wants
to receive the stream.
They say "Hey, yeah, sign me up."
I want to get that stream coming in
from the CEO and we might have hundreds
of devices on the network here.
I'm just showing you three
to keep it easy to visualize,
but let's say the PC is one and two.
Want to receive the video
and PC three does not want to receive the video.
Well, we've got some options.
One option is to use unicast.
Unicast is one to one communication.
In other words, each packet has a source
and a destination address like this.
The video server is the source
and one packet is destined
for PC one another packet is destined for pc two
and PC three is not going to have a packet sent to it
because it does not want to receive the video.
And this is good in that PC,
one and PC to receive the traffic
and PC three didn't.
Can you see that it doesn't scale very well.
I mean, if that video server had
to send out to 200 participants
that wanted to receive the stream,
that video server would have
to send out 200 copies of every single frame
to get to those 200 recipients
that could be taxing on the video service processor.
It could certainly be taxing on the bandwidth
on that link between the video server
and the switch.
So it's not going to scale very well.
What about broadcasts though?
With broadcast, remember,
that's a one two all communication flow,
or all means all devices on a subnet.
And here the video server could send out each frame
of this video stream just one time.
And it goes everywhere within the subnet,
it goes to PCs, one, two, and three.
Now here we've got the benefit of low processor
and bandwidth utilization.
I'm only having this in one copy of each frame.
But the downside is PC three is getting that traffic.
Every time that it gets one
of those packets from this unwanted video stream.
It's going to have to look at that packet and say,
this is not for me discard,
discard, discard and so on.
It's not efficient for PC three
or any other devices on the subnet
that don't want to receive the traffic.
So what's the compromise in this situation?
Well, the best of both worlds comes
from using multicast.
Multicast is a one to many communication flow,
whereby many we're talking about devices
that have joined a multicast group.
And a multicast group
is going to have a specific type of address
and a certain range.
We'll talk about
that coming up in just a few moments.
But for an IP version for multicast group,
we're going to begin in the first octet
with a number in the range of 224 or through 239.
And these two devices
that want to receive the traffic,
they're going to join this group.
Well, let's say it's a group IP address of 239.1.1.1.
Notice that's a Class D address.
Remember that from your CCNA studies,
PC three does not join the group
and it's not going to receive traffic sent to that group.
Now, our video server can send one copy
of each frame in that video stream
and any switches or routers
that are on the way to our destination devices.
If they need to, they can replicate
that packet like our switch did
that switch received one frame in
from the radio server.
It knew that PCs one
and two wanted to receive
that traffic because
they had joined this multicast group.
So the switch is going to send out copies of
that packet to those two recipients,
but it's not going to send it
to PC three because PC three did not want to receive it,
and it did not join the group.
That's one of the benefits
we have from multicast communication.
And I want to talk about the addressing
of multicast from both an IP version four
and IP version six perspective.
Let's begin by taking a look
at IP version four multicast addressing.
As we already alluded to a moment ago,
we're going to be using a Class D address.
And the Class D address begins
with a number in the first octet in the range
of 224 through 239.
But there are some address ranges
that are reserved for special purposes.
For example, we can have a reserved link local address.
Anything that begins with a 224.0.0.x.
That's a reserved link local address.
We see this oftentimes
with our routing protocols is one example.
EIGRP uses these 224.0.0.10
RIP version two uses to 24.0.0.9,
OSPF it's going to use both to 224.0.0.5,
and .6, all in that reserved
that link local address range.
Pretty much anything above this range is usable globaly,
until we get to 239.
We'll talk about that in a moment.
But we've got a bunch of globaly scoped addresses
that we can use on the internet.
Now sometimes we might say,
not only do I want to join this specific multicast group,
I want to receive traffic
from a specific server sending traffic to this group,
we could request the source in other words
and we could use a source specific multicast address
to do that.
This is going to be supported
with something called IGMP version three
that we'll talk about in a few moments.
Another type of address it's reserved is a Glop address.
And I have not been able to find
and I've looked quite a bit I've not been able to find
that Glop stands for anything,
it appears to just be a name.
And the Glop address is going to help us
get a globaly unique multicast address
when we're communicating
with other companies on the internet
other autonomous systems.
You see, normally the way communication happens
on the internet is we're using BGP,
the Border Gateway Protocol.
And BGP is going to keep track of autonomous system numbers.
If we have an organization that's under our control
and we're talking to multiple internet service providers,
we've got an autonomous system,
each of our service providers
have an autonomous system.
And what we can do is use those autonomous system numbers
to give us a unique multicast address
that we can use with members
in another autonomous system.
And again, it's called a Glop address.
And it's going to begin with 233 in the first octet,
to give an example of what a Glop address might look like,
and by the way, it's a full network address
with a 24 subnet mask,
so you get 254 usable IP addresses
that you can have each of those IP addresses
representing a multicast group.
But let me go to a whiteboard
and show you how we can take
a company's autonomous system number
and convert that into a Glop address
that they can use on the internet.
Let's say for example,
we had an autonomous system of 65,000.
And we want to come up with a Glop address.
Well, what we're going to do is realize
that a Glop address begins with 233.
That entire network address space
that's reserved for Glop addresses.
So we know when we begin with 233.
But what about the next two octets?
Well, what we're going to do
is take our autonomous system number,
and we're going to break it down
into a couple of decimal numbers.
Now the 65,000 that is in decimal,
so step one is we convert
that decimal into a hexadecimal
So I'm using a programming calculator,
and I've clicked on 10 for base 10 numbering,
that's decimal numbering,
and I'm going to type in that 65,000.
And then I'll click on 16,
which will give me the hexadecimal representation.
And by the way, the zero and x,
those aren't telling us anything other
than the following is a hexadecimal address.
Don't try to read anything into this extra zero
and x right here.
It just says the following is a hex address.
And that address is FDE8.
So let's write down FDE8.
Now, each one of those hexadecimal digits
is made up of four bits.
So if we had two of those hexadecimal digits together,
that would give us our eight bits
that we could then stick in an octet.
In other words, we're going to take
the first two hexadecimal digits
and the second two hexadecimal digits
and we're going to convert those into decimal
and that's going to give us our second
and third octets.
First of all,
Let's convert FD into decimal.
So again, using our programming calculator,
I'll say FD.
And we'll click on base 10 numbering,
and it's 253.
So that means my slash 24 network
is going to begin with a 233.
As we said, they all do,
followed by 253,
followed by now let's convert E8 into decimal,
let's say E8, convert to decimal to 232.
So we'll say 232.
And then it's going to be .0 slash 24.
And that's our network address space
that we can use globaly.
If we have an autonomous system,
we can use the IP addresses
in this range for global unique multicast IP addresses.
Now, let's get back to our table.
We've got one other range I want you to know about.
And it's limited scope addresses.
Think about the RFC 1918 addresses,
we know that we've got the the 10.address space
and 172.16 through 172.31.
We've got the 192.168 address space,
those are used for private IP addresses
within an organization, not routable
on the public Internet.
Well, we can have those limited scope addresses
with multicast as well.
And that's what we have here.
These addresses begin with a 239.
And if we're using multicast communication
within our own organization,
it's probably going to be one of these addresses
that begins with the 239.
Now that's a look at IP version four multicast addressing.
Let's contrast that
with IP version six multicast addressing.
The great thing about IP version six multicast addresses
is it's easy to recognize them
because the first eight bits are all ones,
four ones as an F and hex
and so we have FF at the beginning
of all of our IP version six multicast addresses.
Making them very easy to recognize if it begins with an FF.
It's a multicast address.
After that though,
we've got four bits that are used for flags.
Now let's say that we've
got a multicast address of FF04::10.
That would be an example
of an IP version six multicast address
and we could send just two members
of that multicast group.
Let's take a look at those flags we were talking about.
We've got four bits
and those bits are the zero RP and T bits.
Now a little bit later in this video,
we're going to talk about the concept of a rendezvous point
and that's going to play a role here.
But on these four bits right now,
that first bit, the zero bit,
it's reserved, and it's always set to zero.
Now the next bit the our bit that is set to a one,
if we have a rendezvous point
that we're using, by the way
before I explain what a rendezvous point is,
if the orbit is set to one, then the P and
T bits must also be set to a one.
Again, that's going to indicate
that we've got a rendezvous point.
A rendezvous point is we're going to
be talking about later in this video
is a router to which we can point to say,
"Hey, I want to receive traffic
for this multicast group."
Because we might not know the source,
we don't know who's sending traffic destined
for this multicast group.
But if we have it set up such
that everybody that sending multicast streams send
to the rendezvous point.
And we can just go up
and ask the rendezvous point
if we want some of that traffic,
and it's going to send it to us.
And then once it sends it to us,
we're going to see who's really sending it
and then we'll be able to go ask the sender directly.
"Hey, can you send that my way,"
so we don't have to go through the rendezvous point.
But the rendezvous point
can make things work a bit more efficiently
in terms of bandwidth,
and we'll talk about that again later in this video.
But those are the flags we might run into.
The next four bits represent the scope.
In other words, how far can this multicast packet travel?
And some of these are not yet assigned.
But we've already talked
about things like a link local scope,
or an address is only valid on a link
between a couple of devices.
And here's a table as your reference.
But here are a couple of the more common ones,
you might run into a couple of examples.
In FF02::1 is going to indicate all nodes
in the link local scope, FF02::2,
that's all routers specifically
in the link local scope.
So that's a look at IP version six multicast addressing.
But if we think about it,
when we're sending traffic to an IP address,
we need a corresponding MAC address,
don't we to properly form our layer two frame.
So let's think about
how we get MAC address information.
Specifically from an IP version four address.
Let's go through this exercise together
where we're constructing a multicast MAC address.
And I'm going to encourage you
to take some notes here
because I've got a second exercise coming up
in just a moment.
And I'm going to invite you to pause the video
and do that exercise on your own,
then resume the video and check your answer.
So take good notes as we go through this first exercise.
Let's say that we've been given
an IP version four multicast address of 224.1.10.10.
Our mission is to calculate the corresponding MAC address,
here are the steps,
we're going to take the last three octets
and convert those to binary.
And if we convert a one,
that's our second octet to binary,
that's going to be seven zeros and one.
If we convert the next octet to binary,
that's a 10, that's going to be four zeros
and then a one zero one zero,
which is eight plus two gives us 10.
We've got a 10 on the fourth octet as well.
So that's also going to be four zeros
and then one zero one zero.
This is what it looks like in binary,
those last three octets.
Now step number two is we take the left most bit
and we want to convert it to a zero
if it's not already a zero.
Well in our case
the left most bit is already a zero,
so nothing changes.
And finally, we want to take each one
of those groupings of four bits,
which by the way is called a nibble.
And we want to convert each
of those nibbles into a hex digit.
If we convert zero zero zero zero into hex,
we get zero zero zero zero one gives us a one,
all zeros is a zero one zero one zero.
That's an A.
And if we go through all of them,
we get zero one zero a zero a,
and we're going to use these 24 bits
as the last half of the MAC address.
But where do we get the first 24 bits,
the first half of the MAC address?
Well, we're going to prepend zero one zero zero five e.
That's going to give us
our multicast MAC address corresponding
to our unknown IP version four address.
So have you got the steps down
you know what you're prepending
you know what bit you're possibly changing.
All right I want to invite you
to do this next one on your own exercise number two.
I'm going to give you a different IP version
for multicast address.
This time, you've got 224.129.10.10.
And my challenge for you is to pause the video,
calculate the corresponding MAC address
and then resume the video for the solution.
All right, did you do it on your own?
Let's go through it together.
We converted the last three octets to binary.
So this looks different
than it did in exercise number one,
specifically, that first digit is different.
There's a one that begins everything.
But then in step two, we changed the leftmost bit,
which is a one,
we change that to a zero if it's not already zero,
and it's not it's a one.
So once we make that change,
hold on that looks identical
to what we had in exercise number one,
is we convert each nibble in the hex
we get the same thing we got in our prior example.
And once we pre pin the zero one zero zero five e,
we get exactly the same MAC address.
Is this a problem?
Yes, it is.
You need to be careful
when you're assigning your multicast IP addresses
such that no two IP addresses correspond
to the same MAC address,
which definitely is possible as you see
in a situation like this.
Now let's take a look at some of the protocols
that make multicast work.
And one protocol that we need to know about
and this is on the exam blueprint.
It's IGMP, which stands
for internet group Management Protocol.
Many people get that confused
and think the M stands for multicast.
It doesn't its management.
And IGMP is going to allow a device
to join the multicast group.
And we've got a router here.
And let's say that it's configured for multicast
and it's configured for specifically IGMP version two.
That's backwards compatible with IGMP version one.
Let me show you what's different here with IGMP version one.
Let's say I want to join a multicast group.
Well I'm going to send a message up
And IGMP message up to that router saying,
"Hey, I'd like to join the group of 239.1.1.1."
Well, if we haven't heard
from that receiver for some time,
specifically, after 60 seconds,
we're wondering,
does it still want to receive traffic for that group,
I don't want to keep sending it traffic
if it no longer wants it.
So after 60 seconds of silence,
we're going to reach out and ask,
"Hey, do you still want to belong to that group."
And if there's no response,
then will be pruned off,
we won't belong to that group any longer.
That's going to be different as compared to IGMP version two.
IGMP version two is a little bit more proactive.
Consider the PC in the lower left hand corner of the screen.
It can also say,
"Hey, I want to join this group
and make me a member
of that group just like we did with the other receiver."
But if it wants to stop receiving traffic,
if it's done, it can proactively send a message that says,
"Hey, I want to leave group 239.1.1.1"
We don't have to wait for some timer to expire
and then be asked, no, we can politely announce
that we're leaving the group.
Now Here I'm showing you a bus topology
for easy visualization.
But in the real world,
we probably have a switch that we're plugging into.
Well, many of our Cisco catalyst switches
can run something called IGMP snooping.
IGMP snooping literally Snoop In
and eavesdrops in on the IGMP communication.
And it sees when one of the receivers wants
to join to 239.1.1.1
and it sees Okay,
I've got a receiver off of this port
that just said it wanted to join this group.
So then when the switch receives traffic destined
for that multicast group,
it knows because it snooped,
it knows that receivers off in this case,
two specific ports want to receive that traffic
and the switch can send traffic adjust out
to those intended recipients,
not to everybody else.
Well, that's all good IGMP
and specifically IGMP version one
and IGMP version two, what their main difference is,
but there's also an IGMP version three.
And I hinted at this earlier
when we talked about source specific multicast.
Here, Let's say we've got a receiver
that wants to be a member of this 239.1.1.1 group.
But in this case,
I've got more than one video server
that's sending it to that group.
Well, maybe just based on proximity,
the bandwidth between the servers
and our router.
For whatever reason,
I want to receive traffic from a specific source,
source specific multicast.
I can say I want to join this group of 239.1.1.1,
but I specifically want to receive traffic
from video server number two.
We're specifying the source in that
IGMP version three message saying I want to get traffic
from a source of 10.3.1.1,
another multicast concept.
I'd love for you to know is the concept
of reverse path forwarding.
You see when a multicast sender
initially sends traffic out through a network,
depending on how we have things configured,
it's possible that it might flood it
through all of the routers in the network.
And in a case like this, notice
that our poor receiver is receiving two copies
of the same frame.
We don't want that.
So what can we do instead?
We can have that last hop router or four,
run an RPF,
or a reverse path forwarding check,
it's going to look at its IP routing table.
And it says I just got this multicast packet in
and it came from 10.1.1.1,
which is a member of the 10.1.1.0 network
that I've got in my IP routing table.
And according to my IP routing table,
if I wanted to send traffic to 10.1.1.1,
I would send it out of interface gigabit zero slash zero .
So I'm only going to accept traffic.
Thanks to RPF I'm only going
to accept traffic from 10.1.1.1
that's coming in on interface gigabit zero slash zero.
So now when we're flooding as we did before,
we're going to drop that packet as it tries
to enter gigabit zero slash one.
Now the other big protocol
that you need to know according
to the exam blueprint is PIM P-I-M
that stands for Protocol Independent Multicast.
Now when I say protocol independent,
I mean we're being independent
of the underlying routing protocol.
In other words, we could be using OSPF or RIP or EIGRP.
Or ISIS it doesn't matter.
We're independent of that to make PIM work.
Protocol Independent Multicast again.
And there are a couple of ways
that we could have a source send traffic out
through a network.
If we're using what's called PIM dense mode,
we're building a source distribution tree.
In this case,
we've got a server
that sending it to a multicast address of 225.1.2.3,
and I've got a receiver down at the bottom
that's a member it wants to receive traffic destined
for that multicast group.
Well, we're going to send traffic into router R one.
And with a source distribution tree,
the assumption is everybody must want
to receive this traffic.
So I'm going to flooded out all of my interfaces,
R one floods it to R two and R three,
R two and R three flooded to one another,
R three, every time it gets a frame,
it floods it down to the receiver.
So the receiver actually got two copies.
And we had traffic flowing over
that link between R one and R two
and R two and R three that it just didn't need
to follow that link.
Because there was no receiver of of R two.
This is called PIM dense mode.
Well, our R two is going to to see this
and it's going to realize,
"Hey, there's nobody connected
to me that wants to receive this traffic.
So this tree that we've built
that contains everybody at the moment,
I'm going to prune myself off of that."
So it's going to prune itself off
of this tree from R one
and it's going to prune itself off
from the tree from R three and R three
it received traffic coming in from R two
and it wants to tell R two you don't need
to do that any longer,
and it will prune itself off.
And we're left with an optimal tree
where we're just going
from R one to R three down to the receiver.
And this is called flood and prune behavior.
However, in some implementations of multicast,
this happens every three minutes.
And on a really large network with hundreds of routers,
this could cause a serious performance issue.
I know of one case where a bank use this approach.
They used the source distribution tree
which is using PIM dense mode,
and they got rid of it.
It was causing so many issues on their network
that they just got rid of the multicast altogether.
Now let's say that somebody added a device
to R two that wanted to receive traffic.
Is that possible
because R two is already proved itself off.
Well, now we've got this receiver
that wants to receive traffic
it sends an IGMP message up to R two saying,
"Hey, can you send me traffic
For 225.1.2.3"
or R two, it needs to once again be a member of that tree.
So let's go on just like
we would graft on a living brains to a living tree,
we're going to send a graft message up to R one.
And there'll be an acknowledgment in return to say,
"Hey, I want to be part of that distribution tree."
And now traffic is going to go
to the receivers off of R two and R three.
But notice, we're still not sending traffic
between R two and R three directly.
There's no need for that.
That is PIM dense mode.
This is not the preferred way of doing things
because with PIM dense mode,
we're doing that flood and prune behavior repeatedly.
The good news is we have our very first packet
taking an optimal path
from our source to our receiver,
but there's a lot of unnecessary traffic flying around.
So that's not the best solution in a lot of cases.
Our other option or other implementation
of PIM is PIM sparse mode.
With PIM sparse mode,
we're using not a source distribution tree,
we're using a shared distribution tree.
Here's the idea.
We want to avoid this flooding
and pruning behavior.
So what we're going to do instead
is configure one router to be our rendezvous point
and everybody else is going to point to
and when somebody like R one,
starts receiving traffic destined
for the multicast group of 225.1.2.3,
it's not going to flooded everywhere
throughout the network like we did in our prior example.
No, it's just going to send it to the rendezvous point.
In R three also knows that R two is the rendezvous point.
So if it were to get a request
from the receiver saying,
"Hey, can you hook me up
with that multicast group of 225.1.2.3,
I'd like to get traffic for that."
What R three is going to do is send a join message
up to R two up to the rendezvous point saying,
"Hey, I got a guy here that wants
to be a part of this group.
Can you help me out?"
And specifically the top of join message
we're sending is a star comma G,
we're sending a star comma G join,
the star is a wild card, meaning anything
because we don't know the sources right now,
we don't know the IP address of
that sending server over
on the left hand side of the screen.
So we say whoever the source is,
I want to join this group.
That's how we can get that receiver receiving traffic
for the group.
And what's going to happen next is we will send traffic
from the source through R one
through R two down to R three,
we're actually going through the rendezvous point
to receive that very first packet.
But once we receive that very first packet,
suddenly, we've learned the IP address
of the sending server.
And we look at our IP routing table and we say,
Well, if I wanted to go back to that server,
which interface would I use?
Well, maybe it's that interface pointing to R one.
So I'm going to send an S comma G join message up to
that router to say,
"Hey, I'd like to receive traffic
from this specific source."
And you see the S instead of an asterisk is saying,
here's the IP address of the source and the G.
That's the multicast IP address of the group.
So now we start to receive traffic via an optimal path.
But we're also receiving it via RT,
the rendezvous point,
we no longer want to receive it via RT.
So what we're going to do is we're going to send out
a prune message to R two to say,
"Hey, can you stop sending me traffic"
and that's what's going to give us our optimal tree.
So at the end of the day, here,
we do have an optimal tree,
where we're going from R one,
down R two or R three down to the receiver,
and the rendezvous point is not involved.
We just use the rendezvous point temporarily,
so that we could get that first packet.
And from that first packet,
we learn the IP address of the source.
And based on that, we send up a join message saying,
"Hey, can you join me to this group
and I want to receive traffic from the source."
We knew where to send it because of our IP routing table,
we saw that source IP address and we said,
based on the IP routing table,
how would I get back to it?
And the way we would get back to it in this case is
that interface pointing up to R one.
So we send a message to R one saying,
"Hey, I'd like to join this group.
And I'd like to get traffic from this source."
And that's a look at multicast.
We took a look at the benefit of using multicast
in some situations as compared to unicast or broadcast.
We talked about multicast address formatting both
for IP version four and for IP version six.
We saw how to extract a multicast MAC address
from an IP version four multicast IP address.
We talked about the different types
of addressing we worked through a Glop configuration.
We talked about three versions of IGMP versions One,
two and three.
And we talked about two versions of PIM,
Protocol Independent Multicast,
PIM dense mode or the much preferred PIM sparse mode.