Okay, so the multicast Mac, remember we're talking about a destination
Mac address, is partially derived from the actual multicast IP address
that sits above it at the networking layer.
So these are the two reserved OUIs you should look for for multicast.
If you ever see an Ethernet frame that's going to a destination starting
out with 01005E, that should make you say aha, that frame is carrying
an IP version 4 multicast packet.
So that's the OUI that's reserved for IPv4 multicast data.
And then if you ever see anything going to 33333, that is reserved for
IPv6 multicasts.
Okay, so let's talk a little bit about how do we actually derive stuff.
First of all, let's start with IPv6.
IPv6 is real easy, and then I'll go back to IPv4.
Let's say that my multicast IPv6 address, I'll just make something up
here. Let's say it was going to FF0E, so this is a global multicast, and
let's just say 11111, and then AAAA, BBBB, CCC, let's see, 1, 2, 3, 4,
5, I need three more.
And then 2222, 777, 1, 2, 3, 4, 5, 6, 7, then we'll just do the last octet,
sort of run DDD.
Okay, all we're going to do is when the multicast source generates this
address as the destination address at layer three, after that when he's
creating his Ethernet frame, all he's going to do is take the last 32
bits, which in this case is 777 and DDDD, and he's going to put that right
here, where these X's are.
So at layer two, the Ethernet frame will be destined to 333 colon 777
colon DDDD. So that's pretty easy.
Just remember the last 32 bits of the IPv6 multicast address are directly
mapped to the last 32 bits of the Ethernet frame's destination MAC address.
Now, in the world of IPv4, this is kind of a nightmare to map this.
So just bear with me here, if you haven't had your coffee, you might want
to take a big chug of it at this point, because this typically makes people's
eyes glaze over.
But we're going to go ahead and go through it because I think you ought
to know it. So, first of all, my multicast MAC address we know at layer
two is 01005E. And now you might think, okay, well that's half of the
address, right? A MAC address is 48 bits long.
This is half. So you might think, okay, I've got 24 bits left to map.
Well, not quite.
If I convert this into binary for the rest of it, just some of it, the
very next bit has to be a zero.
And then you've got 12345678 colon 12345678.
I'll just do that.
Colon 12345678. I'm running out of space, but you get the idea.
So of my remaining 24 bits, I really only have 23 bits.
This one here has to be zeroed out.
And if you're ever looking at that and you're wondering what?
Well, that makes no sense.
I'll tell you what, there's an interesting story.
I'm not going to get into the story, but this is what you should Google
to find out why did they end up doing it like this?
Google this. Google the name Steve.
Last name, Deering.
Multicast Mac. Google that.
Steve Deering Multicast Mac.
And you'll be able to find an interesting story about Steve Deering was
one of the original pioneers of multicast.
He did a lot of the initial work on this.
And you'll find an interesting story about back when he was a grad student,
a little interaction he had with his professor that had to do with money,
and it ended up with this weird thing right here, with only 23 bits being
available. Okay, so how do we map the multicast IP address?
Well, if you can keep this in mind, now it should be pretty easy.
Just take the last 23 bits of the multicast IP address and map it here.
So let's say my multicast IP address is 239.
Well no matter what the first octet is, whether 224 up to 239, it's always
going to map down to 5e, right?
Because that octet is sort of canceled out, it's always going to become
5e. And now let's say I had a multicast stream that was 239.
let's just make it easy.
1.1.1. That's my multicast IP address.
Well the resulting multicast MAC address would be 01005e, and these bits
would be mapped right here.
So it'd be 01005e, 1111.
Well what if I had 225.1.1?
It would be the exact same thing.
0111, they would all map to the same multicast MAC.
So let's add this up for a second.
If you just do some quick math, if we start at 224 and we go up to 239,
how many unique numbers is that?
I'll tell you right now, that's a total of 16 unique numbers.
From 224 up to 239 is 16 combinations of bytes.
So right off the bat, we've got 16 multicast IPV4 addresses which will
all map down to the exact same multicast MAC.
But it gets even better than that.
Because not only will 239.111 map down to this, but 239.129.11.
Because remember, this 8 bit, this bit that's normally mapped to the 128
bit, always has to be a zero.
So even if in the IPV4 address that bit is turned on, we have to turn
it off right here.
So 239.111 and 239.111 will also map to the same thing.
Anytime the 128 bit is turned on in this third octet, it's going to drop
out because it's got to be a zero right here.
So that means for each one of these 16 combinations, there's two combinations
that also map. For example, 224.111 and 224.129.11, both mapped to the
exact same thing.
227.1.5.5, 227.129.5 mapped to the exact same thing.
So in reality, we've got 16 numbers in the first octet and two numbers
in the second octet.
So we really have 32.
So for every single multicast MAC address, so if I show you, for example,
this one, let's get rid of Steve Deering's name right here.
I'm sure he would love to see it up on this presentation, but sorry, Steve,
we're going to get rid of it temporarily.
So if I gave you this multicast MAC address, 01005E, oops, not 5.2, 5E.
And then I said, let's just say, 7.1 .1, let me do one, let's do colons.
So much for keeping things consistent, let's see here.
Let's do colons over here too.
Okay so if I was to ask you, what is the multicast IPv4 address that ended
up resulting in this multicast MAC address?
Your answer would have to be 32 unique numbers.
Because you'd say, well Keith, the first octet could have been anything
from 224 all the way down to 239.
And then the second octet could have been the number 7, or it could be
128 plus 7, which would be 135.1.1.
So 224.7.135, 225.7.135, 226.7.135, 111.1.
Would all map to this?
So that gives us 32 multicast IP addresses that map to the same multicast
MAC address. Now at this point you might be wondering, wow, okay, interesting
mathematical exercise, but where is the real world relevance to this?
Where is the relevance?
Well let me paint a picture for you.
Let's say, let's take this.
Let's say that I have 4 laptops.
Let's just say 3, 3 laptops since I'm running out of room here.
Okay, and we'll make it real simple here.
They're connected to a hub, which in turn is connected to a multicast
server. Of course you would never see this in real life, but you'll get
the idea behind this once I start here.
So we'll just say PCA, B, and C.
And let's say this multicast server is going to be sending out 3 unique
streams of traffic.
We've got 225.2.1.1.
We've got 239.130.1.1.
And we've got 232.
Well we shouldn't be using, well you'll get the idea, 232.2.1.1.
And let's say that all of these are high definition streams.
Each one is 5 megabits per second.
If you actually receive it, you'll be receiving 5 megabits per second.
Okay, so these streams are going now.
All three streams are leaving this server simultaneously.
If PC, let's just start with PCC.
If PCC says look, the only one I'm interested in is 225.2.1.1.
So what does he do?
He goes to his ethernet Nik card.
He says okay, ethernet Nik card, this is what I want you to look for.
If you've ever seen ethernet frame that starts out with 0.01, 0.05e, 0
.2, 0.1, 0.1, I want you to pick that up and send it to my processor for
processing. The moment he does that, and he programs his Nik card to look
at that, all of a sudden his laptop just starts going haywire.
His video screen is just pixelated, you can't see anything, it doesn't
make any sense. Not only that, he's trying to download his emails and
it's taken forever to download his emails, he might even be connecting
and disconnecting, connecting and disconnecting from his email server.
It's like his laptop is just being slammed.
What's going on?
At this point, because all three of these streams map to the exact same
layer two MAC address, we now have three streams coming down and his Nik
card is picking up all of them because at layer two, they all look the
same. His ethernet card can't distinguish the layer three addresses because
it doesn't do that.
It's just a layer two ethernet card.
So all three of these streams, a total of 15 megs of traffic is being
directed to this guy's central processing unit and his CPU has to now
toss or discard 10 megs of that so it can only see the five megs that
it want. Well his CPU is probably going to have a real hard time receiving
a consistent 15 megs of inbound traffic and trying to discard two thirds
of that, 10 megs of it.
And that's the problem with the 32 to one overlap.
Now this is not the receiver's fault.
This is the fault of the person who set up this multicast server in the
first place. When you're, if you ever are in a situation where you are
the multicast administrator and it's going to be your job to come up with
the multicast IP addresses for each one of the multicast streams, it's
your job to be aware of this and make sure that these video streams don't
overlap. And it might say, well Keith, is there an easy way to figure
that out? Sure there is.
Just make sure that of every single multicast stream that the last two
octets are never the same.
Now technically we could go into the third octet as well but if you know
that these last 16 bits are always unique, your multicast MAC addresses
will always be unique because these last 16 bits map down one for one
down to the multicast MAC address at layer two.
So just make those unique and you'll never have this 32 to one overlap
problem ever again.
So that is how you recognize multicast IP and multicast MAC addresses.
Now I've talked a little bit about what do routers do with multicast frames.
I said when a router receives in a multicast frame, first thing it says
is, is this something I need to process?
Because it might be an EIGRP hello or an OSPF hello or something like
that in which case I'll say, ah, I'm programmed to look for this.
Let me send it to my CPU for processing.
Which stop and pause for a moment.
Think about this.
Imagine that you are a router, okay, and you are programmed to do EIGRP,
alright? So you are listening specifically for Ethernet frames coming
in going to 01005E, 0000A, right?
Because that would map to 10, 2240010 maps down to 00A at layer two.
So here every once in a while you're expecting as a router you say, okay,
well, you know, EIGRP shouldn't be that chatty, right?
In a nice stable environment, every five or ten seconds or so you should
be receiving an EIGRP hello packet, going to that multicast Mac, and then
you process it. Now what if somebody who doesn't know anything about EIGRP
but they do know multicast sets up their multicast high definition video
stream, which is going at seven megabits per second, and they select,
I don't know, 239.0010 as the destination dress.
Guess what? At layer two that high definition video stream will map to
the exact same Mac address that EIGRP is using.
And now all of a sudden your router instead of only getting one packet
every five or ten seconds is getting thousands of packets every single
second going to this layer to address.
You can bet that router is not going to be too happy about that.
It might even crash because it has to take all that traffic directed to
the CPU to be not EIGRP.
I need to discard that to be able to isolate the little EIGRP hello that's
still coming in every five seconds or so.
So be aware of that.
Now what do switches do when receiving multicast?
Well, if you're just talking about pure layer two, switches flood multicast
because how does a switch know where to forward something?
Well, when Ethernet frame comes in, what does a switch do?
It learns that into the MAC address table, sometimes called the CAM table,
right? So that's how the switch populates the CAM table, the MAC address
table based on source MAC addresses.
Well, are multicast MAC addresses ever seen in the source of an Ethernet
frame? No they're not.
At least they shouldn't be.
That would be illegal.
So because a multicast MAC address only shows up in the destination, by
default, a switch has no way of learning it because it's not in the source.
So what do switches do when they receive an Ethernet frame and they look
at the destination and there's no match in the table?
They flood it. That's what they do.
So the default behavior of many switches is to flood multicast.
Now we'll see when we get into the topic of IGMP snooping that changes