Let's start off with the question.
Let's imagine that you and I are on a network where they've
set up a DHCP server, and so it's
handing out IP addresses, default gateway, DNS
information to clients.
Clients are all happy, happy, but then one day,
somebody either maliciously or accidentally
plugs in a device that's acting also as a DHCP server,
and now some of the clients are getting an IP address that
is not the right subnet, they're getting a default gateway that
leads somewhere else, possibly to the DHCP server,
and that's a huge problem.
It could be a disruption of service for sure, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It could be a disruption of service for sure,
but it also could be the beginning
of a man-in-the-middle attack.
So as a solution to that, wouldn't it
be awesome if we could set up a structure
or some type of security that protected DHCP services?
So if somebody did bring in a DHCP server that
was non-authorized, whether it was on accident
or whether it was malicious, the switch could just
step in and say, you know what?
No, I'm not allowing any of your DHCP server stuff today.
We can do that with a feature called DHCP snooping
on a Catalyst switch.
And to provide a backdrop for how DHCP snooping works, let's WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And to provide a backdrop for how DHCP snooping works, let's
imagine this network where we have the legitimate DHCP
server sitting right here plugged into port 3/3,
and then we have three clients-- client 1, 2, and 3 off
of these ports respectively, and let's imagine
this is subnet 10.16.20 with the 24-bit mask,
and the default gateway is 10.16.27.
So these clients, when they boot up,
if they're configured to use DHCP,
they'll do the door process, they'll
send a DHCP discover, the server will send the offer, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
send a DHCP discover, the server will send the offer,
if there is a server that hears that request,
then the client will request that,
and then the server will send an acknowledgment.
So some of these packets that are involved
involve the client piece and some involve the server piece.
So with one authorized DHCP server no unauthorized DHCP
servers, life is good, but the moment somebody intentionally
or accidentally plugs into that VLAN
a DHCP server, if the DHCP server
hears a discover message, it's going to give an offer.
And if the client accepts it and requests that IP address, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And if the client accepts it and requests that IP address,
we then have a client with misinformation
about what the default gateway is, what
the subnet is, and so forth.
So here's how we solve the problem with this feature
called DHCP snooping.
We configure the switch, and we tell it to pay attention
to DHCP server-type messages, like the offers,
acknowledgments, and there's a few others,
but they're all server-based.
So once we enable this feature and we
say that we want to use this feature on VLAN 30, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
say that we want to use this feature on VLAN 30,
the switch starts listening to all that and says,
you know what?
The answer is just say no.
Just say no to what, Keith?
Just say no to any DHCP server-type messages,
like offers and acknowledgments, just
say no on every single port in that VLAN.
And then the question is, well, what about the real
the DHCP server?
Doesn't he need to do offers and acknowledgments back
into the networks so the clients can see him?
And the answer is yes.
So what we do is once we've enabled DHCP snooping
and we've applied it to the VLAN,
we would then take the ports-- WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we would then take the ports--
and I'll circle is right here.
We take the ports that lead to the real
the DHCP server and we say, I trust you.
From a DHCP snooping perspective,
that would be a DHCP snooping trusted port.
And as a result, those DHCP server-type messages
are allowed into the switch on that port
because it's a DHCP snooping trusted port.
And that way, all the other ports on this switch,
including 1/0, 1/1, and 1/2, if they start acting
like a DHCP server and start doing
offers and acknowledgments and so forth, the switch-- WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
offers and acknowledgments and so forth, the switch--
because by default, once this feature is enabled,
DHCP snooping, all the ports that
are not explicitly trusted, like 3/3,
all the other ports are explicitly
non-trusted or untrusted ports from a DHCP snooping
perspective, and that way, no rogue
DHCP servers will successfully get on your network
because all the other ports by default are untrusted
and the switch just simply won't let that traffic in.
And that, my friend, is the concept behind DHCP snooping.
It basically says every port, once the feature's enabled, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It basically says every port, once the feature's enabled,
every port is not trusted unless we specifically trust it,
and we trust only those ports that
lead to the real and authorized DHCP servers.
And that way, bogus DHCP servers cannot be introduced
to our network by connecting to any of the other ports
on the switch.
So in the very next video, we'll take a look
at some of the commands and configurations
to implement DHCP snooping, and then as we continue together,
we'll do additional labs on both configuring and verifying
that DHCP snooping is working.
So I'll see you in the next video. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So I'll see you in the next video.
Meanwhile, I hope this has been informative for you,
and I'd like to thank you for viewing.