1
00:00:02,195 --> 00:00:08,403
[music]

2
00:00:08,403 --> 00:00:11,312
In this section we're going
to start with an introduction

3
00:00:11,312 --> 00:00:14,253
to IPv6. I'm not
going to be getting

4
00:00:14,253 --> 00:00:17,827
on any equipment or CLI at this

5
00:00:17,827 --> 00:00:21,153
point for this
first lesson here.

6
00:00:21,153 --> 00:00:22,831
We're just going to start with

7
00:00:22,831 --> 00:00:24,665
some basic things
you need to know

8
00:00:24,665 --> 00:00:31,277
about IPv6 before we even really
start jumping in and configuring

9
00:00:31,277 --> 00:00:32,841
it and setting it up.

10
00:00:32,841 --> 00:00:34,433
So, the first
question of course,

11
00:00:34,433 --> 00:00:35,853
which I think at this point most

12
00:00:35,853 --> 00:00:40,338
people are aware of, but why
are we even going to IPv6?

13
00:00:40,338 --> 00:00:41,830
What's the point?

14
00:00:41,830 --> 00:00:44,956
The first and foremost
reason, of course,

15
00:00:44,956 --> 00:00:50,200
is that IPv4 only
has a maximum of

16
00:00:50,200 --> 00:00:55,107
2^32 IP addresses being
a 32 bit address,

17
00:00:55,107 --> 00:00:57,306
and mathematically that comes

18
00:00:57,306 --> 00:01:00,996
out to right around 3.4
billion addresses.

19
00:01:00,996 --> 00:01:02,401
But hopefully you're

20
00:01:02,401 --> 00:01:05,606
already aware of
the fact that we

21
00:01:05,606 --> 00:01:08,353
lose considerable amounts of

22
00:01:08,353 --> 00:01:12,606
addresses once you
start backing out

23
00:01:12,606 --> 00:01:14,824
all your multicast addresses.

24
00:01:14,824 --> 00:01:20,523
You start backing out the entire
class A loopback address space.

25
00:01:20,523 --> 00:01:24,653
Not to mention all the addresses
you lose simply by the fact that

26
00:01:24,653 --> 00:01:26,745
we broke it all up
into class A, class B,

27
00:01:26,745 --> 00:01:29,375
class C addresses and so on.

28
00:01:29,375 --> 00:01:34,971
Realistically, there's actually
far fewer addresses than that.

29
00:01:34,971 --> 00:01:37,971
But even if we had
them all usable,

30
00:01:37,971 --> 00:01:41,467
we'd still be running
out of them of course.

31
00:01:41,467 --> 00:01:43,477
Here's what we're saying
here right after classes,

32
00:01:43,477 --> 00:01:46,039
multicast, reserved
ranges, and so on,

33
00:01:46,039 --> 00:01:49,790
there's actually far few
that are actually usable.

34
00:01:49,790 --> 00:01:53,705
Now, if any of you have been in

35
00:01:53,705 --> 00:01:55,506
this industry for
quite some time,

36
00:01:55,506 --> 00:01:57,816
you may remember back in,

37
00:01:57,816 --> 00:02:00,946
I'm going to say
somewhere in the 95,

38
00:02:00,946 --> 00:02:05,758
1996 time frame, even back then,

39
00:02:05,758 --> 00:02:08,472
IANA was yelling, Oh we're going

40
00:02:08,472 --> 00:02:11,250
to run out of address
space in IPv4.

41
00:02:11,250 --> 00:02:13,875
Of course that's when all
this all started with--

42
00:02:13,875 --> 00:02:17,181
it didn't start then, I mean
it already under development.

43
00:02:17,181 --> 00:02:22,074
There's where the whole push
for IPv6 really started.

44
00:02:22,074 --> 00:02:24,855
Of course, it's been a long time

45
00:02:24,855 --> 00:02:26,927
since then, regardless
of when you're

46
00:02:26,927 --> 00:02:27,807
listening to this,

47
00:02:27,807 --> 00:02:29,050
it's been a long time when I'm

48
00:02:29,050 --> 00:02:32,368
recording it and
even longer since

49
00:02:32,368 --> 00:02:33,570
you're listening to it here.

50
00:02:33,570 --> 00:02:36,384
The point is we've
known for quite

51
00:02:36,384 --> 00:02:38,939
some time that this was coming.

52
00:02:38,939 --> 00:02:41,698
Now, in the meantime of course,

53
00:02:41,698 --> 00:02:43,818
they came up with a
technology called NAT,

54
00:02:43,818 --> 00:02:46,094
or network address translation.

55
00:02:46,094 --> 00:02:48,526
The idea here I'm sure
you're all familiar with,

56
00:02:48,526 --> 00:02:55,628
is that we take a range, usually
from the RFC-1918 address space,

57
00:02:55,628 --> 00:03:00,043
so our private addresses,
and we enumerate

58
00:03:00,043 --> 00:03:01,669
our entire internal

59
00:03:01,669 --> 00:03:05,041
network with these
RFC-1918 addresses,

60
00:03:05,041 --> 00:03:07,130
and then we hide all of those

61
00:03:07,130 --> 00:03:10,691
behind NAT, or if you want to
be a little more specific,

62
00:03:10,691 --> 00:03:14,575
we generally use PAT or
Port Address Translation.

63
00:03:14,575 --> 00:03:17,192
NAT is the more
generic term for it.

64
00:03:17,192 --> 00:03:19,425
Everybody calls it that.

65
00:03:19,425 --> 00:03:22,532
Just generically say,
yeah, we're using NAT.

66
00:03:22,532 --> 00:03:25,768
Fact of the matter is, I
think that probably very,

67
00:03:25,768 --> 00:03:32,234
very, very few companies in
situations actually use NAT.

68
00:03:32,234 --> 00:03:35,011
NAT is a one-to-one
translation where

69
00:03:35,011 --> 00:03:38,644
you would have one
public outside address

70
00:03:38,644 --> 00:03:42,266
for every one internal
private address.

71
00:03:42,266 --> 00:03:44,699
That doesn't mean they have
to be statically mapped,

72
00:03:44,699 --> 00:03:46,603
they can still be dynamic.

73
00:03:46,603 --> 00:03:50,869
The way it was done is you
would have an outside pool.

74
00:03:50,869 --> 00:03:52,893
Let's say just as an example,

75
00:03:52,893 --> 00:03:55,218
your company owned
- we'll just make

76
00:03:55,218 --> 00:03:58,651
it simple - we'll say a
class C address range.

77
00:03:58,651 --> 00:04:04,185
So let's say you own essentially
254 usable addresses,

78
00:04:04,185 --> 00:04:06,350
and what that would
mean with NAT

79
00:04:06,350 --> 00:04:09,148
is that you would
have 254 possible

80
00:04:09,148 --> 00:04:12,009
hosts inside of
your network that

81
00:04:12,009 --> 00:04:13,814
could access the internet at any

82
00:04:13,814 --> 00:04:16,849
given time. Now the reason
for that, of course,

83
00:04:16,849 --> 00:04:18,709
is like I said, it's one-to-one.

84
00:04:18,709 --> 00:04:21,465
For every one
internal address that

85
00:04:21,465 --> 00:04:23,338
tried to go to the
outside world,

86
00:04:23,338 --> 00:04:25,212
it would go through
NAT and it would

87
00:04:25,212 --> 00:04:27,157
be given one of the
public addresses

88
00:04:27,157 --> 00:04:28,626
out of the pool.

89
00:04:28,626 --> 00:04:33,231
And then all traffic, all ports,
everything going back and forth

90
00:04:33,231 --> 00:04:37,477
between that private and public
address would be translated.

91
00:04:37,477 --> 00:04:39,854
Now, the obvious
problem with this

92
00:04:39,854 --> 00:04:43,586
is every machine inside talking

93
00:04:43,586 --> 00:04:47,296
to the internet needs a
public outside address.

94
00:04:47,296 --> 00:04:49,065
When this was first created,

95
00:04:49,065 --> 00:04:51,975
you have to keep in
mind that back then

96
00:04:51,975 --> 00:04:53,952
not everybody had
the internet on

97
00:04:53,952 --> 00:04:57,469
every machine, and
not every device

98
00:04:57,469 --> 00:05:00,235
inside a company
network actually

99
00:05:00,235 --> 00:05:01,459
needed internet access,

100
00:05:01,459 --> 00:05:06,580
or was even allowed internet
access, or anything else.

101
00:05:06,580 --> 00:05:08,359
Quite honestly, half the people

102
00:05:08,359 --> 00:05:09,158
didn't even know
what the internet

103
00:05:09,158 --> 00:05:14,426
was yet. You have to look at
from a time frame perspective,

104
00:05:14,426 --> 00:05:16,434
at a certain point
in time, it would

105
00:05:16,434 --> 00:05:20,867
have been no problem to have,

106
00:05:20,867 --> 00:05:23,465
it of course varies
based on company size,

107
00:05:23,465 --> 00:05:27,165
but maybe a block of
16 outside addresses,

108
00:05:27,165 --> 00:05:30,852
or 32, or maybe a whole
class C, whatever.

109
00:05:30,852 --> 00:05:33,343
You'd have X number of outside

110
00:05:33,343 --> 00:05:35,935
addresses and then
you'd have 200

111
00:05:35,935 --> 00:05:40,729
machines inside the company
with 16 outside addresses.

112
00:05:40,729 --> 00:05:44,606
Only 16 of those machines
could communicate at once,

113
00:05:44,606 --> 00:05:47,449
because you only have
16 public addresses.

114
00:05:47,449 --> 00:05:51,077
Now the obvious problem here
becomes is as the network grows,

115
00:05:51,077 --> 00:05:54,233
and the internet
becomes more popular,

116
00:05:54,233 --> 00:05:56,767
everybody wants internet access.

117
00:05:56,767 --> 00:05:58,152
Yeah, you could
argue whether they

118
00:05:58,152 --> 00:05:59,710
actually need it or not inside

119
00:05:59,710 --> 00:06:01,905
of a company, but regardless,

120
00:06:01,905 --> 00:06:04,255
everybody had to have internet.

121
00:06:04,255 --> 00:06:05,939
We're now all of a sudden having

122
00:06:05,939 --> 00:06:09,434
16 out of 200
machines capable of

123
00:06:09,434 --> 00:06:13,713
communicating simultaneously,
just frankly wasn't enough.

124
00:06:13,713 --> 00:06:16,016
So that's where we
step up to, of course,

125
00:06:16,016 --> 00:06:18,997
Port Address
Translation where we

126
00:06:18,997 --> 00:06:22,821
can take hundreds of machines

127
00:06:22,821 --> 00:06:27,814
and hide them behind a
single IPv4 address.

128
00:06:27,814 --> 00:06:30,017
Now, for your really
large companies,

129
00:06:30,017 --> 00:06:31,515
you could still take that block

130
00:06:31,515 --> 00:06:39,724
of 16 or 254 addresses, whatever
it is you have and overload -

131
00:06:39,724 --> 00:06:41,672
that's what Cisco calls it.

132
00:06:41,672 --> 00:06:45,417
Other devices honestly
just refer to it as NAT.

133
00:06:45,417 --> 00:06:47,935
Cisco refers to it
as NAT Overload

134
00:06:47,935 --> 00:06:50,095
on the CLI, but at
the end of the day,

135
00:06:50,095 --> 00:06:55,930
we're really talking about PAT
or Port Address Translation.

136
00:06:55,930 --> 00:06:57,762
All in all what
does this give us?

137
00:06:57,762 --> 00:07:05,019
It buys us from 1996,
when we already

138
00:07:05,019 --> 00:07:06,442
started throwing up
the panic flags -

139
00:07:06,442 --> 00:07:09,524
holy cow, the internet's
growing like crazy -

140
00:07:09,524 --> 00:07:11,387
and they're looking at
it, looking at the math,

141
00:07:11,387 --> 00:07:13,777
going, uh, we're in big trouble.

142
00:07:13,777 --> 00:07:17,368
This cannot grow the
way we're trying to.

143
00:07:17,368 --> 00:07:22,421
To really getting us all the way
through until modern times,

144
00:07:22,421 --> 00:07:26,326
where we're still on
IPv4 for the most part.

145
00:07:26,326 --> 00:07:29,184
Obviously, since you're
watching this course,

146
00:07:29,184 --> 00:07:31,687
we're hoping that
you're at least

147
00:07:31,687 --> 00:07:33,157
interested in IPv6 and learning

148
00:07:33,157 --> 00:07:36,690
more about it, and we are
ultimately heading here.

149
00:07:36,690 --> 00:07:40,173
It's not a question, it's
not a maybe we're going to.

150
00:07:40,173 --> 00:07:43,217
Someday we will look
back on this and say,

151
00:07:43,217 --> 00:07:45,383
ha ha, remember when
we used to run IPv4?

152
00:07:45,383 --> 00:07:48,192
I can't believe anybody would
still run that anymore.

153
00:07:48,192 --> 00:07:52,219
How quickly? I'm
not even going to

154
00:07:52,219 --> 00:07:55,522
bother trying to
make a prediction.

155
00:07:55,522 --> 00:07:57,813
There have been numerous times
where people have said,

156
00:07:57,813 --> 00:07:59,462
oh, it's going to
happen in two years.

157
00:07:59,462 --> 00:08:00,934
Yeah, okay, no.

158
00:08:00,934 --> 00:08:02,717
This is going to
take a long time.

159
00:08:02,717 --> 00:08:04,202
There's no two ways about it.

160
00:08:04,202 --> 00:08:06,631
We're going to have
transition phases.

161
00:08:06,631 --> 00:08:10,981
My personal prediction is that
this is going to be very,

162
00:08:10,981 --> 00:08:14,921
very much like, if anybody's
been around for a while,

163
00:08:14,921 --> 00:08:20,621
the transition from IPX/SPX
to IP for a lot of your LANs.

164
00:08:20,621 --> 00:08:22,288
Now, some of your big networks

165
00:08:22,288 --> 00:08:24,597
started off that way
and stayed on IP.

166
00:08:24,597 --> 00:08:26,382
But for people who are running

167
00:08:26,382 --> 00:08:27,890
Novell, NetWare, and stuff back

168
00:08:27,890 --> 00:08:30,420
and in the day, it
was not an overnight

169
00:08:30,420 --> 00:08:32,818
translation from one protocol

170
00:08:32,818 --> 00:08:38,108
to the other. It was
a long transition,

171
00:08:38,108 --> 00:08:43,338
relatively speaking, where we
were, for quite a long time,

172
00:08:43,338 --> 00:08:44,850
running both protocols.

173
00:08:44,850 --> 00:08:47,026
We would have IPX/SPX running to

174
00:08:47,026 --> 00:08:49,997
support the LAN, file and
print sharing services,

175
00:08:49,997 --> 00:08:51,295
that sort of thing.

176
00:08:51,295 --> 00:08:52,989
And right next to it,

177
00:08:52,989 --> 00:08:58,380
running TCP/IP to support
internet access.

178
00:08:58,380 --> 00:09:01,857
Now obviously, things like
NetWare, things like that,

179
00:09:01,857 --> 00:09:03,724
of course, all start
moving over to IP.

180
00:09:03,724 --> 00:09:06,371
The need for IPX/SPX goes away.

181
00:09:06,371 --> 00:09:10,086
Someday we do that whole
fake full flip the switch,

182
00:09:10,086 --> 00:09:14,044
click, okay, IPX/SPX is off.

183
00:09:14,044 --> 00:09:16,547
Let's see what breaks.

184
00:09:16,547 --> 00:09:17,760
Hopefully, it's not guess work.

185
00:09:17,760 --> 00:09:19,527
Hopefully, you've
done your research

186
00:09:19,527 --> 00:09:21,231
and you know that nothing else

187
00:09:21,231 --> 00:09:22,897
is using it. A little bit of

188
00:09:22,897 --> 00:09:25,193
protocol analysis
goes a long way.

189
00:09:25,193 --> 00:09:27,181
The point is this.

190
00:09:27,181 --> 00:09:30,761
I think we're going to be doing
the same thing for a really long

191
00:09:30,761 --> 00:09:33,619
time with IPv6.

192
00:09:33,619 --> 00:09:36,574
A lot of companies are
just at the point,

193
00:09:36,574 --> 00:09:41,652
as I'm recording this, of just
starting to mess with IPv6.

194
00:09:41,652 --> 00:09:42,795
Well let's get it running.

195
00:09:42,795 --> 00:09:47,115
Let's get it set up and going,
but we're still really IPv4.

196
00:09:47,115 --> 00:09:50,202
It's going to be a long
drawn out process.

197
00:09:50,202 --> 00:09:55,060
The good news is everything
is supported with IPv6.

198
00:09:55,060 --> 00:09:56,595
It's ready to go.

199
00:09:56,595 --> 00:09:59,539
There's a couple
few little things

200
00:09:59,539 --> 00:10:02,582
here and there that
are not supported

201
00:10:02,582 --> 00:10:04,665
in code, like
specifically on Cisco

202
00:10:04,665 --> 00:10:08,366
devices and such and
other manufacturers,

203
00:10:08,366 --> 00:10:10,991
but it's down to little things.

204
00:10:10,991 --> 00:10:14,025
When this all started,
you had basic

205
00:10:14,025 --> 00:10:16,831
IPv6 support, but none of the

206
00:10:16,831 --> 00:10:17,458
fancy features.

207
00:10:17,458 --> 00:10:20,532
None of the really cool stuff.

208
00:10:20,532 --> 00:10:23,568
Now we pretty much
have everything

209
00:10:23,568 --> 00:10:25,537
and now it's more the other way.

210
00:10:25,537 --> 00:10:27,177
Yeah, okay, this little feature

211
00:10:27,177 --> 00:10:28,801
here is not supported
yet or that

212
00:10:28,801 --> 00:10:31,101
little thing there is
not supported yet.

213
00:10:31,101 --> 00:10:36,170
It's really come a long way
since this whole thing started.

214
00:10:36,170 --> 00:10:38,029
The other thing.

215
00:10:38,029 --> 00:10:40,511
I have one more
thing on this slide

216
00:10:40,511 --> 00:10:41,516
I want to talk about which is

217
00:10:41,516 --> 00:10:44,903
the whole broadcasts.

218
00:10:44,903 --> 00:10:48,216
Layer 2, Layer 3
broadcasts cause

219
00:10:48,216 --> 00:10:50,968
a lot of unnecessary CPU load on

220
00:10:50,968 --> 00:10:55,401
our end devices because the fact
of the matter is if something's

221
00:10:55,401 --> 00:11:00,319
going to a broadcast that means
that it's destined to you.

222
00:11:00,319 --> 00:11:01,412
That's actually one of those

223
00:11:01,412 --> 00:11:03,114
things I always
like to point out

224
00:11:03,114 --> 00:11:05,080
to people because you
love the question,

225
00:11:05,080 --> 00:11:09,572
so what does a router
do with a broadcast?

226
00:11:09,572 --> 00:11:12,127
And so many times
I get the answer

227
00:11:12,127 --> 00:11:13,199
- because I love asking that in

228
00:11:13,199 --> 00:11:16,729
classes and stuff -
and I'll often hear

229
00:11:16,729 --> 00:11:19,110
the answer, it drops them.

230
00:11:19,110 --> 00:11:23,122
And I have to say, no,
not specifically.

231
00:11:23,122 --> 00:11:25,559
If a router dropped broadcasts

232
00:11:25,559 --> 00:11:29,961
then RIP version 1 would have
had a really hard time working.

233
00:11:29,961 --> 00:11:32,133
The fact of the matter is

234
00:11:32,133 --> 00:11:35,724
routers don't drop
them. They don't

235
00:11:35,724 --> 00:11:39,618
forward broadcasts, or they
don't route broadcasts -

236
00:11:39,618 --> 00:11:41,179
however you want to say that.

237
00:11:41,179 --> 00:11:46,901
But the point is this, they do
in fact process broadcasts.

238
00:11:46,901 --> 00:11:49,202
Just like your own machine does,

239
00:11:49,202 --> 00:11:53,273
the problem is that every
device on the segment is,

240
00:11:53,273 --> 00:11:55,457
in fact, the target.

241
00:11:55,457 --> 00:11:58,012
So if you want to look at
it from this perspective,

242
00:11:58,012 --> 00:12:00,754
why would a router
forward a broadcast

243
00:12:00,754 --> 00:12:02,599
when it is the destination?

244
00:12:02,599 --> 00:12:03,518
That's sort of the point,

245
00:12:03,518 --> 00:12:07,489
that everybody is the
destination for the broadcast.

246
00:12:07,489 --> 00:12:10,733
The problem is, that packet

247
00:12:10,733 --> 00:12:13,176
may only be intended for one,

248
00:12:13,176 --> 00:12:16,182
two, a couple devices
on that segment.

249
00:12:16,182 --> 00:12:19,120
I just used the example
of RIP version 1.

250
00:12:19,120 --> 00:12:20,404
Let's say that you were running

251
00:12:20,404 --> 00:12:24,565
RIP version 1 - I'm
hoping you're not,

252
00:12:24,565 --> 00:12:26,923
I'm just using an example -

253
00:12:26,923 --> 00:12:28,350
but let's say you were running

254
00:12:28,350 --> 00:12:31,369
RIP version 1
between two devices

255
00:12:31,369 --> 00:12:34,959
on a multi-access LAN
segment - so VLAN.

256
00:12:34,959 --> 00:12:37,788
On that VLAN, just for
the sake of argument,

257
00:12:37,788 --> 00:12:39,953
let's say there's 100
machines on there.

258
00:12:39,953 --> 00:12:42,551
Every time RIP sends out its

259
00:12:42,551 --> 00:12:46,698
broadcast update
every 30 seconds,

260
00:12:46,698 --> 00:12:49,028
sending out the
entire routing table,

261
00:12:49,028 --> 00:12:50,207
that means that every single

262
00:12:50,207 --> 00:12:53,397
device on that segment
- every PC, MAC,

263
00:12:53,397 --> 00:12:58,709
Linux box - everybody needs
to process that frame.

264
00:12:58,709 --> 00:13:00,437
What they're going to process is

265
00:13:00,437 --> 00:13:01,095
they're going to
get it and they're

266
00:13:01,095 --> 00:13:04,001
going to bring it up to UDP,

267
00:13:04,001 --> 00:13:06,240
and they're going to
look at the port number,

268
00:13:06,240 --> 00:13:07,139
and they're going to say,

269
00:13:07,139 --> 00:13:10,027
oh, I'm not listening
on that UDP port.

270
00:13:10,027 --> 00:13:12,195
Now, depending on the
operating system,

271
00:13:12,195 --> 00:13:15,465
they may or may not
realize, wait, this is RIP.

272
00:13:15,465 --> 00:13:16,786
I'm not running RIP.

273
00:13:16,786 --> 00:13:18,413
Why am I getting this?

274
00:13:18,413 --> 00:13:21,337
They may just look at it and go,
I'm not listening on that port.

275
00:13:21,337 --> 00:13:23,717
However it works
programmatically

276
00:13:23,717 --> 00:13:25,526
inside's not really important.

277
00:13:25,526 --> 00:13:30,334
But the fact of the matter is,
they had to interrupt the CPU,

278
00:13:30,334 --> 00:13:33,577
take cycles to look at
this frame to realize,

279
00:13:33,577 --> 00:13:36,681
hey, this isn't for me.

280
00:13:36,681 --> 00:13:39,463
Ultimately a better thing to do

281
00:13:39,463 --> 00:13:41,625
would be to throw
this frame away

282
00:13:41,625 --> 00:13:45,287
in hardware. At the
end of the day--

283
00:13:45,287 --> 00:13:47,416
hopefully we're all
running switches.

284
00:13:47,416 --> 00:13:49,718
I don't even know if
they make hubs anymore.

285
00:13:49,718 --> 00:13:53,893
I'm sure somebody
does somewhere.

286
00:13:53,893 --> 00:13:55,552
We'll just pretend for a minute

287
00:13:55,552 --> 00:13:57,101
that we have hubs
and everything's

288
00:13:57,101 --> 00:14:01,445
just one big broadcast segment,
one big collision domain.

289
00:14:01,445 --> 00:14:09,383
The issue becomes, even with
unicast, and multicast,

290
00:14:09,383 --> 00:14:14,908
with a hub environment or just a
flat out multi-access segment,

291
00:14:14,908 --> 00:14:16,875
everybody gets those
frames anyway.

292
00:14:16,875 --> 00:14:19,467
I think it sometimes
confused people;

293
00:14:19,467 --> 00:14:23,322
what's the difference
if there's a hub?

294
00:14:23,322 --> 00:14:26,562
The difference, honestly, all
comes down to your network card.

295
00:14:26,562 --> 00:14:28,721
Your network card
has a burned in

296
00:14:28,721 --> 00:14:31,443
address from the manufacturer.

297
00:14:31,443 --> 00:14:32,665
If it's Ethernet,
which I'm going

298
00:14:32,665 --> 00:14:34,815
to assume for this
course that it is,

299
00:14:34,815 --> 00:14:38,668
we call it a MAC address.

300
00:14:38,668 --> 00:14:42,493
The thing is this, if
you receive that frame,

301
00:14:42,493 --> 00:14:45,314
and it's not destined
to your broadcast--

302
00:14:45,314 --> 00:14:47,948
sorry, to your MAC address,

303
00:14:47,948 --> 00:14:50,412
if it's a broadcast
or a multicast

304
00:14:50,412 --> 00:14:53,364
that you're-- and for the
sake of the multicast,

305
00:14:53,364 --> 00:14:55,758
you have not joined
that group, so

306
00:14:55,770 --> 00:14:58,589
you're not listening
for that multicast.

307
00:14:58,589 --> 00:15:00,795
Your network card
will look at that.

308
00:15:00,795 --> 00:15:04,199
It'll look at the destination
MAC address and it will say,

309
00:15:04,199 --> 00:15:08,228
well, this clearly
came in on my segment.

310
00:15:08,228 --> 00:15:09,887
Here it is. Here are
the bits coming

311
00:15:09,887 --> 00:15:11,800
in on the wire,
but when he looks

312
00:15:11,800 --> 00:15:14,702
at the destination
address and it's

313
00:15:14,702 --> 00:15:16,793
not his unicast MAC address

314
00:15:16,793 --> 00:15:21,290
or any multicast he's listening
for, he'll just throw that away.

315
00:15:21,290 --> 00:15:25,144
He just discards it right there
in hardware at the neck.

316
00:15:25,144 --> 00:15:27,012
He's not going to
bother the CPU.

317
00:15:27,012 --> 00:15:29,408
He's not going to bother
the operating system.

318
00:15:29,408 --> 00:15:35,545
He just says, not for me and
I'm going to throw this away.

319
00:15:35,545 --> 00:15:36,454
I just want to make sure we're

320
00:15:36,454 --> 00:15:37,522
clear on the
difference on why we

321
00:15:37,522 --> 00:15:43,170
say that a broadcast creates CPU
load, yet multicasts and nicasts

322
00:15:43,170 --> 00:15:47,473
do not. In the case of most
of our modern switches,

323
00:15:47,473 --> 00:15:50,607
that stuff wouldn't
have happened anyway.

324
00:15:50,607 --> 00:15:52,471
The first couple
frames might for

325
00:15:52,471 --> 00:15:55,608
like an unknown unicast or even

326
00:15:55,608 --> 00:15:58,117
multicast if the switch does not

327
00:15:58,117 --> 00:16:01,760
support IGMP snooping
or something like that.

328
00:16:01,760 --> 00:16:02,988
It is still possible,

329
00:16:02,988 --> 00:16:04,266
even with today's
switches, to get

330
00:16:04,266 --> 00:16:05,902
a couple frames, or in the case

331
00:16:05,914 --> 00:16:07,775
of multicast, maybe
even a bunch.

332
00:16:07,775 --> 00:16:09,216
The fact of the
matter is is your

333
00:16:09,216 --> 00:16:11,553
network card in hardware will be

334
00:16:11,553 --> 00:16:14,377
throwing that away,
where with a broadcast,

335
00:16:14,377 --> 00:16:16,948
it can't do that because again,

336
00:16:16,948 --> 00:16:20,250
everybody is the destination.

337
00:16:20,250 --> 00:16:21,976
So the network card
looks at that and goes,

338
00:16:21,976 --> 00:16:23,572
well, it's not my MAC address,

339
00:16:23,572 --> 00:16:26,864
but it's a broadcast
so I'm going to

340
00:16:26,864 --> 00:16:32,811
send it on up to the CPU because
he has to decide whether this is

341
00:16:32,811 --> 00:16:35,550
for us or not.

342
00:16:35,550 --> 00:16:37,007
We'll talk more about
that in a little

343
00:16:37,007 --> 00:16:38,572
bit when we get into multicasts

344
00:16:38,572 --> 00:16:41,946
and the advantages
that they give us.

345
00:16:41,946 --> 00:16:43,718
The flip side of
that is, of course,

346
00:16:43,718 --> 00:16:45,826
they bring a little
bit of discussion

347
00:16:45,826 --> 00:16:48,846
to the table. That means
things have to change.

348
00:16:48,846 --> 00:16:50,442
We'll take a look
at that here in

349
00:16:50,442 --> 00:16:51,617
just a second as well.

350
00:16:51,617 --> 00:16:56,617
[music]