WEBVTT

1
00:00.000 --> 00:00.643 align:middle line:84%


2
00:00.643 --> 00:02.060 align:middle line:90%
Let's start off
with the question.

3
00:02.060 --> 00:04.518 align:middle line:90%
Let's imagine that you and I
are on a network where they've

4
00:04.518 --> 00:06.050 align:middle line:90%
set up a DHCP
server, and so it's

5
00:06.050 --> 00:09.320 align:middle line:90%
handing out IP addresses,
default gateway, DNS

6
00:09.320 --> 00:10.440 align:middle line:84%
information to clients.

7
00:10.440 --> 00:12.890 align:middle line:90%
Clients are all happy,
happy, but then one day,

8
00:12.890 --> 00:15.980 align:middle line:90%
somebody either
maliciously or accidentally

9
00:15.980 --> 00:20.000 align:middle line:90%
plugs in a device that's
acting also as a DHCP server,

10
00:20.000 --> 00:22.520 align:middle line:90%
and now some of the clients
are getting an IP address that

11
00:22.520 --> 00:25.790 align:middle line:90%
is not the right subnet, they're
getting a default gateway that

12
00:25.790 --> 00:28.280 align:middle line:90%
leads somewhere else,
possibly to the DHCP server,

13
00:28.280 --> 00:29.550 align:middle line:84%
and that's a huge problem.

14
00:29.550 --> 00:31.560 align:middle line:90%
It could be a disruption
of service for sure,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

14
00:29.550 --> 00:31.560 align:middle line:90%
It could be a disruption
of service for sure,

15
00:31.560 --> 00:32.977 align:middle line:90%
but it also could
be the beginning

16
00:32.977 --> 00:34.358 align:middle line:84%
of a man-in-the-middle attack.

17
00:34.358 --> 00:35.900 align:middle line:90%
So as a solution to
that, wouldn't it

18
00:35.900 --> 00:38.120 align:middle line:90%
be awesome if we could
set up a structure

19
00:38.120 --> 00:41.660 align:middle line:90%
or some type of security
that protected DHCP services?

20
00:41.660 --> 00:44.810 align:middle line:90%
So if somebody did bring
in a DHCP server that

21
00:44.810 --> 00:47.150 align:middle line:90%
was non-authorized,
whether it was on accident

22
00:47.150 --> 00:49.760 align:middle line:90%
or whether it was malicious,
the switch could just

23
00:49.760 --> 00:51.230 align:middle line:84%
step in and say, you know what?

24
00:51.230 --> 00:55.100 align:middle line:90%
No, I'm not allowing any of
your DHCP server stuff today.

25
00:55.100 --> 00:58.340 align:middle line:90%
We can do that with a
feature called DHCP snooping

26
00:58.340 --> 00:59.980 align:middle line:84%
on a Catalyst switch.

27
00:59.980 --> 01:04.700 align:middle line:90%
And to provide a backdrop for
how DHCP snooping works, let's
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

27
00:59.980 --> 01:04.700 align:middle line:90%
And to provide a backdrop for
how DHCP snooping works, let's

28
01:04.700 --> 01:07.880 align:middle line:90%
imagine this network where
we have the legitimate DHCP

29
01:07.880 --> 01:11.130 align:middle line:90%
server sitting right here
plugged into port 3/3,

30
01:11.130 --> 01:14.480 align:middle line:90%
and then we have three
clients-- client 1, 2, and 3 off

31
01:14.480 --> 01:16.880 align:middle line:90%
of these ports respectively,
and let's imagine

32
01:16.880 --> 01:20.030 align:middle line:90%
this is subnet 10.16.20
with the 24-bit mask,

33
01:20.030 --> 01:22.920 align:middle line:90%
and the default
gateway is 10.16.27.

34
01:22.920 --> 01:24.470 align:middle line:90%
So these clients,
when they boot up,

35
01:24.470 --> 01:26.120 align:middle line:90%
if they're configured
to use DHCP,

36
01:26.120 --> 01:27.830 align:middle line:90%
they'll do the door
process, they'll

37
01:27.830 --> 01:31.610 align:middle line:90%
send a DHCP discover, the
server will send the offer,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

37
01:27.830 --> 01:31.610 align:middle line:90%
send a DHCP discover, the
server will send the offer,

38
01:31.610 --> 01:33.660 align:middle line:90%
if there is a server
that hears that request,

39
01:33.660 --> 01:35.420 align:middle line:90%
then the client
will request that,

40
01:35.420 --> 01:37.610 align:middle line:90%
and then the server will
send an acknowledgment.

41
01:37.610 --> 01:39.470 align:middle line:90%
So some of these packets
that are involved

42
01:39.470 --> 01:42.970 align:middle line:90%
involve the client piece and
some involve the server piece.

43
01:42.970 --> 01:46.940 align:middle line:90%
So with one authorized DHCP
server no unauthorized DHCP

44
01:46.940 --> 01:50.210 align:middle line:90%
servers, life is good, but the
moment somebody intentionally

45
01:50.210 --> 01:53.150 align:middle line:90%
or accidentally
plugs into that VLAN

46
01:53.150 --> 01:55.850 align:middle line:90%
a DHCP server, if
the DHCP server

47
01:55.850 --> 01:58.770 align:middle line:90%
hears a discover message,
it's going to give an offer.

48
01:58.770 --> 02:01.330 align:middle line:90%
And if the client accepts it
and requests that IP address,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

48
01:58.770 --> 02:01.330 align:middle line:90%
And if the client accepts it
and requests that IP address,

49
02:01.330 --> 02:03.230 align:middle line:90%
we then have a client
with misinformation

50
02:03.230 --> 02:05.120 align:middle line:90%
about what the default
gateway is, what

51
02:05.120 --> 02:06.823 align:middle line:84%
the subnet is, and so forth.

52
02:06.823 --> 02:08.990 align:middle line:90%
So here's how we solve the
problem with this feature

53
02:08.990 --> 02:14.150 align:middle line:84%
called DHCP snooping.

54
02:14.150 --> 02:17.630 align:middle line:90%
We configure the switch, and
we tell it to pay attention

55
02:17.630 --> 02:22.240 align:middle line:90%
to DHCP server-type
messages, like the offers,

56
02:22.240 --> 02:23.990 align:middle line:90%
acknowledgments, and
there's a few others,

57
02:23.990 --> 02:25.628 align:middle line:84%
but they're all server-based.

58
02:25.628 --> 02:27.170 align:middle line:90%
So once we enable
this feature and we

59
02:27.170 --> 02:30.168 align:middle line:90%
say that we want to use
this feature on VLAN 30,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

59
02:27.170 --> 02:30.168 align:middle line:90%
say that we want to use
this feature on VLAN 30,

60
02:30.168 --> 02:32.210 align:middle line:90%
the switch starts listening
to all that and says,

61
02:32.210 --> 02:32.960 align:middle line:84%
you know what?

62
02:32.960 --> 02:37.010 align:middle line:84%
The answer is just say no.

63
02:37.010 --> 02:38.240 align:middle line:84%
Just say no to what, Keith?

64
02:38.240 --> 02:41.420 align:middle line:90%
Just say no to any DHCP
server-type messages,

65
02:41.420 --> 02:43.580 align:middle line:90%
like offers and
acknowledgments, just

66
02:43.580 --> 02:46.615 align:middle line:90%
say no on every single
port in that VLAN.

67
02:46.615 --> 02:48.740 align:middle line:90%
And then the question is,
well, what about the real

68
02:48.740 --> 02:49.550 align:middle line:84%
the DHCP server?

69
02:49.550 --> 02:52.490 align:middle line:90%
Doesn't he need to do offers
and acknowledgments back

70
02:52.490 --> 02:54.420 align:middle line:90%
into the networks so
the clients can see him?

71
02:54.420 --> 02:55.500 align:middle line:84%
And the answer is yes.

72
02:55.500 --> 02:57.985 align:middle line:90%
So what we do is once
we've enabled DHCP snooping

73
02:57.985 --> 02:59.360 align:middle line:90%
and we've applied
it to the VLAN,

74
02:59.360 --> 03:00.740 align:middle line:84%
we would then take the ports--
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

74
02:59.360 --> 03:00.740 align:middle line:84%
we would then take the ports--

75
03:00.740 --> 03:02.280 align:middle line:84%
and I'll circle is right here.

76
03:02.280 --> 03:04.340 align:middle line:90%
We take the ports
that lead to the real

77
03:04.340 --> 03:08.030 align:middle line:90%
the DHCP server and
we say, I trust you.

78
03:08.030 --> 03:10.200 align:middle line:90%
From a DHCP snooping
perspective,

79
03:10.200 --> 03:13.100 align:middle line:90%
that would be a DHCP
snooping trusted port.

80
03:13.100 --> 03:15.740 align:middle line:90%
And as a result, those
DHCP server-type messages

81
03:15.740 --> 03:17.720 align:middle line:90%
are allowed into the
switch on that port

82
03:17.720 --> 03:21.140 align:middle line:90%
because it's a DHCP
snooping trusted port.

83
03:21.140 --> 03:23.400 align:middle line:90%
And that way, all the
other ports on this switch,

84
03:23.400 --> 03:26.270 align:middle line:90%
including 1/0, 1/1, and
1/2, if they start acting

85
03:26.270 --> 03:28.490 align:middle line:90%
like a DHCP server
and start doing

86
03:28.490 --> 03:31.130 align:middle line:90%
offers and acknowledgments
and so forth, the switch--
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

86
03:28.490 --> 03:31.130 align:middle line:90%
offers and acknowledgments
and so forth, the switch--

87
03:31.130 --> 03:33.500 align:middle line:90%
because by default, once
this feature is enabled,

88
03:33.500 --> 03:35.570 align:middle line:90%
DHCP snooping,
all the ports that

89
03:35.570 --> 03:38.630 align:middle line:90%
are not explicitly
trusted, like 3/3,

90
03:38.630 --> 03:40.700 align:middle line:90%
all the other ports
are explicitly

91
03:40.700 --> 03:44.150 align:middle line:90%
non-trusted or untrusted
ports from a DHCP snooping

92
03:44.150 --> 03:46.640 align:middle line:90%
perspective, and
that way, no rogue

93
03:46.640 --> 03:49.640 align:middle line:90%
DHCP servers will successfully
get on your network

94
03:49.640 --> 03:52.520 align:middle line:90%
because all the other ports
by default are untrusted

95
03:52.520 --> 03:55.820 align:middle line:90%
and the switch just simply
won't let that traffic in.

96
03:55.820 --> 03:58.970 align:middle line:90%
And that, my friend, is the
concept behind DHCP snooping.

97
03:58.970 --> 04:01.820 align:middle line:90%
It basically says every port,
once the feature's enabled,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

97
03:58.970 --> 04:01.820 align:middle line:90%
It basically says every port,
once the feature's enabled,

98
04:01.820 --> 04:05.570 align:middle line:90%
every port is not trusted
unless we specifically trust it,

99
04:05.570 --> 04:07.010 align:middle line:90%
and we trust only
those ports that

100
04:07.010 --> 04:09.890 align:middle line:90%
lead to the real and
authorized DHCP servers.

101
04:09.890 --> 04:12.950 align:middle line:90%
And that way, bogus DHCP
servers cannot be introduced

102
04:12.950 --> 04:15.920 align:middle line:90%
to our network by connecting
to any of the other ports

103
04:15.920 --> 04:16.637 align:middle line:84%
on the switch.

104
04:16.637 --> 04:18.470 align:middle line:90%
So in the very next
video, we'll take a look

105
04:18.470 --> 04:20.269 align:middle line:90%
at some of the commands
and configurations

106
04:20.269 --> 04:23.900 align:middle line:90%
to implement DHCP snooping, and
then as we continue together,

107
04:23.900 --> 04:26.870 align:middle line:90%
we'll do additional labs on
both configuring and verifying

108
04:26.870 --> 04:28.880 align:middle line:84%
that DHCP snooping is working.

109
04:28.880 --> 04:30.330 align:middle line:90%
So I'll see you
in the next video.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

109
04:28.880 --> 04:30.330 align:middle line:90%
So I'll see you
in the next video.

110
04:30.330 --> 04:32.720 align:middle line:90%
Meanwhile, I hope this has
been informative for you,

111
04:32.720 --> 04:35.890 align:middle line:90%
and I'd like to thank
you for viewing.