WEBVTT

0:00:03.180000 --> 0:00:08.380000
 Hello and welcome to this video, which
 is a DHCP snooping demonstration.

0:00:08.380000 --> 0:00:09.860000
 And that's exactly what
 I'm going to do.

0:00:09.860000 --> 0:00:13.540000
 I'm going to give you a live demonstration
 of DHCP snooping in the lab

0:00:13.540000 --> 0:00:17.120000
 environment. So let's
 just go right to that.

0:00:17.120000 --> 0:00:20.540000
 So here you can see, I'm going to make
 this a little bit bigger so you

0:00:20.540000 --> 0:00:23.820000
 can see it. This is going
 to be our lab topology.

0:00:23.820000 --> 0:00:26.620000
 Just want to point
 out a few things.

0:00:26.620000 --> 0:00:30.380000
 Most of this has already
 been pre-configured.

0:00:30.380000 --> 0:00:33.960000
 So instead of having laptops, we're
 going to be using routers instead

0:00:33.960000 --> 0:00:35.740000
 of for our DHCP client.

0:00:35.740000 --> 0:00:39.400000
 So I've got a router right here and
 he's going to obtain his IP address

0:00:39.400000 --> 0:00:42.480000
 information on this interface
 via DHCP client.

0:00:42.480000 --> 0:00:44.040000
 So he'll be the client.

0:00:44.040000 --> 0:00:49.840000
 We have another router here which is pre
-configured as a rogue DHCP server.

0:00:49.840000 --> 0:00:52.320000
 And right now he is in the
 completely wrong network.

0:00:52.320000 --> 0:00:55.680000
 So this is supposed to be this
 whole network here of 123.

0:00:55.680000 --> 0:00:59.820000
 It's supposed to be
 the 1.1.0 network.

0:00:59.820000 --> 0:01:03.280000
 But notice I've put him in the 99 network
 and that's what he's going to

0:01:03.280000 --> 0:01:07.300000
 be offering. If he sees a DHCP discover,
 he's going to offer an address

0:01:07.300000 --> 0:01:10.780000
 in the completely wrong network
 which is the 99 network.

0:01:10.780000 --> 0:01:15.100000
 Over here we have another router router
 2 which is serving as our legitimate

0:01:15.100000 --> 0:01:19.700000
 DHCP server. And all of our DHCP snooping
 is going to be done on this

0:01:19.700000 --> 0:01:22.400000
 device right here, switch to.

0:01:22.400000 --> 0:01:25.780000
 So let's just get right to it.

0:01:25.780000 --> 0:01:29.760000
 Move this guy back
 to where he was.

0:01:29.760000 --> 0:01:34.600000
 All right, so just some
 quick verification here.

0:01:34.600000 --> 0:01:40.140000
 So first of all, let's look at
 our legitimate DHCP server.

0:01:40.140000 --> 0:01:47.480000
 And we can just confirm that he's got
 a legitimate DHCP pool with the

0:01:47.480000 --> 0:01:51.960000
 correct network address, the correct
 default router which is him.

0:01:51.960000 --> 0:01:57.380000
 He is 1111. And that IP address is actually
 configured right here on his

0:01:57.380000 --> 0:01:58.740000
 physical interface.

0:01:58.740000 --> 0:02:03.020000
 So if the client gets an IP address
 in this pool and is pointing at the

0:02:03.020000 --> 0:02:07.360000
 correct default gateway which is 1111,
 the client should be able to ping

0:02:07.360000 --> 0:02:13.460000
 the internet as referenced by this
 loopback interface right here.

0:02:13.460000 --> 0:02:19.480000
 However we also have another router
 which is router 3 which is our rogue

0:02:19.480000 --> 0:02:24.360000
 DHCP server. Now notice in the topology
 he's actually physically closer

0:02:24.360000 --> 0:02:27.480000
 to the client than our
 legitimate DHCP server.

0:02:27.480000 --> 0:02:33.380000
 So when that client sends out a DHCP
 discover packet as a broadcast, he

0:02:33.380000 --> 0:02:37.200000
 should get a response from
 the rogue server first.

0:02:37.200000 --> 0:02:41.080000
 And the rogue server will offer up an
 address in a completely incorrect

0:02:41.080000 --> 0:02:47.200000
 network. So before we turn on any DHCP
 snooping, let's see if that is

0:02:47.200000 --> 0:02:48.100000
 indeed the case.

0:02:48.100000 --> 0:02:53.300000
 So let's go to our client which
 is router 1 right here.

0:02:53.300000 --> 0:02:56.120000
 Show IP interface brief.

0:02:56.120000 --> 0:03:01.680000
 So we can see right now that FastEthernet
 0.1 is not configured for anything.

0:03:01.680000 --> 0:03:04.580000
 So here's what we're going to do.

0:03:04.580000 --> 0:03:12.840000
 We're going to type in debug DHCP detail
 which gives us client debugging

0:03:12.840000 --> 0:03:15.960000
 availability here
 on the iOS router.

0:03:15.960000 --> 0:03:19.100000
 We're going to go into interface
 FastEthernet 0.1.

0:03:19.100000 --> 0:03:21.260000
 We're going to shut it down.

0:03:21.260000 --> 0:03:29.780000
 Here we go. And now we're going to say
 IP address DHCP so he can simulate

0:03:29.780000 --> 0:03:33.320000
 a client like a laptop for a PC.

0:03:33.320000 --> 0:03:41.620000
 No shut. All right, so we should
 see here momentarily.

0:03:41.620000 --> 0:03:44.460000
 Sometimes this debug does
 not show, OK, here we go.

0:03:44.460000 --> 0:03:47.640000
 Starting DHCP discover
 on FastEthernet 0.1.

0:03:47.640000 --> 0:03:51.800000
 So when you see a whole bunch of zeros,
 that means nothing's happened

0:03:51.800000 --> 0:03:56.400000
 yet. OK. So let's just give this
 a chance here to finish out.

0:03:56.400000 --> 0:04:01.160000
 There we go. Turn the debug off.

0:04:01.160000 --> 0:04:05.780000
 So we can see initially he was sending
 discover attempt number 1.

0:04:05.780000 --> 0:04:08.120000
 Said, hey, I don't currently
 have an IP address.

0:04:08.120000 --> 0:04:10.340000
 My temporary address and
 mask is all zeros.

0:04:10.340000 --> 0:04:11.720000
 That's what I'm trying to get.

0:04:11.720000 --> 0:04:16.940000
 So this went out as a broadcast.

0:04:16.940000 --> 0:04:20.000000
 His first packet went out.

0:04:20.000000 --> 0:04:24.100000
 And then right here received
 a boot reply packet.

0:04:24.100000 --> 0:04:26.460000
 That is the same thing
 as a DHCP offer.

0:04:26.460000 --> 0:04:29.400000
 And look where it came
 from, the 99 network.

0:04:29.400000 --> 0:04:32.420000
 So that came from the
 rogue DHCP server.

0:04:32.420000 --> 0:04:37.760000
 He got 99. And he was offered.

0:04:37.760000 --> 0:04:40.400000
 Let's see here. What
 was he offered?

0:04:40.400000 --> 0:04:51.740000
 So he was offered this subnet, this
 default gateway, and offer received

0:04:51.740000 --> 0:04:56.160000
 right here, temporary
 IP address 99.99.2.

0:04:56.160000 --> 0:05:00.980000
 So that's the address he was offered
 from the rogue server.

0:05:00.980000 --> 0:05:09.180000
 So it looks like, and then down here,
 right here, we received another

0:05:09.180000 --> 0:05:13.640000
 DHCP offer shortly behind that with
 our legitimate information.

0:05:13.640000 --> 0:05:17.020000
 See, this is coming from the
 real DHCP server of 1111.

0:05:17.020000 --> 0:05:21.240000
 But by this time, it was too late.


0:05:21.240000 --> 0:05:24.760000
 That DHCP server came in too late.


0:05:24.760000 --> 0:05:27.520000
 And this guy already
 had the 99 network.

0:05:27.520000 --> 0:05:29.820000
 So we can see here.

0:05:29.820000 --> 0:05:34.140000
 DHCP address assignment, he allocated
 for himself the very first offer

0:05:34.140000 --> 0:05:38.440000
 that he got, which was 99.99.2.

0:05:38.440000 --> 0:05:44.940000
 Which is wrong. Show IP interface brief
 now confirms that he's using the

0:05:44.940000 --> 0:05:50.360000
 wrong address. So let's see how DHCP
 stooping can fix this for us.

0:05:50.360000 --> 0:05:53.640000
 So let's shut down that
 interface on the client.

0:05:53.640000 --> 0:05:56.940000
 So he'll release that address.

0:05:56.940000 --> 0:06:05.080000
 OK, while we're here, let's divert all
 of our debugging output to an internal

0:06:05.080000 --> 0:06:08.900000
 buffer so we can read it later on.


0:06:08.900000 --> 0:06:13.160000
 So logging console 6.

0:06:13.160000 --> 0:06:17.160000
 So I'll basically show us on the
 console everything but debugging.

0:06:17.160000 --> 0:06:24.000000
 Logging buffer 7, which is debug
 and everything below it.

0:06:24.000000 --> 0:06:33.400000
 Killer log, debug DHCP, detail.

0:06:33.400000 --> 0:06:38.380000
 All right. Now before we bring that
 interface up, let's go to our switch

0:06:38.380000 --> 0:06:41.880000
 and configure DHCP snooping.

0:06:41.880000 --> 0:06:48.040000
 So on the switch, we'd
 say IP, DHCP, snooping.

0:06:48.040000 --> 0:06:52.080000
 And now we have to do that same command
 again but apply it against VLAN

0:06:52.080000 --> 0:07:01.100000
 123. So if we do that, now every interface
 in VLAN 123 is currently an

0:07:01.100000 --> 0:07:02.580000
 untrusted interface.

0:07:02.580000 --> 0:07:07.500000
 So if we just leave it that way, we'll
 see that the client doesn't get

0:07:07.500000 --> 0:07:14.560000
 anything. So let's go back to our client,
 which is router 1, interface

0:07:14.560000 --> 0:07:18.980000
 fast ethernet 0.01, no shut.

0:07:18.980000 --> 0:07:22.140000
 Now he's not going to get
 an address from anybody.

0:07:22.140000 --> 0:07:25.860000
 If we start looking at our logs, which
 currently has a debug running,

0:07:25.860000 --> 0:07:32.380000
 so right here we can see.

0:07:32.380000 --> 0:07:34.360000
 So here is a temp number 1.

0:07:34.360000 --> 0:07:37.720000
 Whenever you see all zeros, that means,
 OK, nothing's happened yet.

0:07:37.720000 --> 0:07:44.240000
 If we just keep looking through this output,
 we're not going to see anybody

0:07:44.240000 --> 0:07:46.760000
 responding back to him.

0:07:46.760000 --> 0:07:53.020000
 All right. Now he's sending out a temp
 number 2 because he timed out.

0:07:53.020000 --> 0:07:56.700000
 A temp number 3 timed out.

0:07:56.700000 --> 0:07:58.840000
 And this is just going to keep happening
 over and over and over again

0:07:58.840000 --> 0:08:00.980000
 until eventually this router
 is just going to give up.

0:08:00.980000 --> 0:08:05.980000
 And that's because we didn't make any trusted
 interfaces on the DHCP snooping

0:08:05.980000 --> 0:08:11.280000
 switch. Without a trusted interface, this
 guy's client messages are getting

0:08:11.280000 --> 0:08:13.400000
 absolutely nowhere.

0:08:13.400000 --> 0:08:18.480000
 So let's go back to the switch.

0:08:18.480000 --> 0:08:29.420000
 And let's go to interface fast ethernet
 0.01, IPDCP snooping trust.

0:08:29.420000 --> 0:08:37.060000
 OK, so to confirm, show IPDCP snooping,
 let's see what we've got here.

0:08:37.060000 --> 0:08:43.680000
 So it says it is enabled
 on VLAN 123.

0:08:43.680000 --> 0:08:47.360000
 And fast ethernet 0.10 is
 the trusted interface.

0:08:47.360000 --> 0:08:49.140000
 So this should work.

0:08:49.140000 --> 0:08:51.860000
 You would think, hint hint.

0:08:51.860000 --> 0:08:56.820000
 So let's go back to the switch,
 not the switch, the client.

0:08:56.820000 --> 0:09:04.280000
 Clear the log. Bring his
 interface back up.

0:09:04.280000 --> 0:09:13.980000
 Let's wait a few moments and
 check our debug output.

0:09:13.980000 --> 0:09:25.880000
 All right, so here we see
 discover a temp number 1.

0:09:25.880000 --> 0:09:27.540000
 Eventually it timed out.

0:09:27.540000 --> 0:09:29.780000
 Discover a temp number 2.

0:09:29.780000 --> 0:09:36.180000
 That timed out. Maybe we just
 haven't waited long enough.

0:09:36.180000 --> 0:09:43.000000
 Discover a temp number 3.

0:09:43.000000 --> 0:09:45.940000
 Uh oh, looks like something's
 not working here, doesn't it?

0:09:45.940000 --> 0:09:47.540000
 Now we're going back.

0:09:47.540000 --> 0:09:51.080000
 Discover a temp number now is
 cycling back around again.

0:09:51.080000 --> 0:09:53.180000
 So clearly, this isn't
 working yet.

0:09:53.180000 --> 0:09:56.080000
 We have enabled DHCP
 snooping on switch 2.

0:09:56.080000 --> 0:09:58.200000
 We enabled it for
 the correct VLAN.

0:09:58.200000 --> 0:10:01.280000
 We even trusted fast
 ethernet 0.10.

0:10:01.280000 --> 0:10:02.920000
 What's going on?

0:10:02.920000 --> 0:10:08.540000
 Well, let's go over to the legitimate
 DHCP server and see if we can tell

0:10:08.540000 --> 0:10:10.440000
 if he's even seeing anything.

0:10:10.440000 --> 0:10:14.560000
 So let's shut down this interface
 to begin with on the client.

0:10:14.560000 --> 0:10:20.520000
 If I could type.

0:10:20.520000 --> 0:10:23.800000
 All right, so now let's go
 over to the DHCP server.

0:10:23.800000 --> 0:10:27.160000
 And let's run a different
 debug on him.

0:10:27.160000 --> 0:10:31.200000
 So we'll just let this
 run to the console.

0:10:31.200000 --> 0:10:37.480000
 So instead of debug DHCP detail, which
 is what you run on the client when

0:10:37.480000 --> 0:10:40.840000
 a router's running as a client, to
 see the server-related information,

0:10:40.840000 --> 0:10:46.520000
 you want debug IP DHCP server.

0:10:46.520000 --> 0:10:54.420000
 And we'll just do
 packet and event.

0:10:54.420000 --> 0:11:00.400000
 OK, so let's go ahead and log this
 to the buffer just so we don't miss

0:11:00.400000 --> 0:11:07.380000
 anything. Logging buffer 7.

0:11:07.380000 --> 0:11:10.160000
 All right, so I'm the
 moment of truth.

0:11:10.160000 --> 0:11:15.720000
 Let's go back to the client and
 bring his interface back up.

0:11:15.720000 --> 0:11:21.360000
 Let's go back to our server and see
 if our debug show us anything.

0:11:21.360000 --> 0:11:29.580000
 OK, so we're getting some
 information here.

0:11:29.580000 --> 0:11:32.660000
 It says inconsistent
 relay information.

0:11:32.660000 --> 0:11:39.180000
 Relay information option exists,
 but gateway address is 0.

0:11:39.180000 --> 0:11:41.040000
 What is this really talking about?


0:11:41.040000 --> 0:11:45.160000
 Well, this is about as much information
 as we're going to get on the DHCP

0:11:45.160000 --> 0:11:50.820000
 server himself. But I'll tell you
 what the what's going on here.

0:11:50.820000 --> 0:11:55.560000
 Where it says relay information
 option exists.

0:11:55.560000 --> 0:12:00.300000
 That is how Cisco iOS says,
 hey, I am seeing option 82.

0:12:00.300000 --> 0:12:05.480000
 I'm getting DHCP packets in with option
 82, which would normally be put

0:12:05.480000 --> 0:12:08.260000
 in there from a DHCP relay agent.

0:12:08.260000 --> 0:12:11.340000
 But he's not recognizing
 option 82.

0:12:11.340000 --> 0:12:14.580000
 This goes back to what I told you in
 the previous videos that we need

0:12:14.580000 --> 0:12:20.420000
 to disable option 82 for DHCP snooping
 because servers don't like it.

0:12:20.420000 --> 0:12:24.500000
 So let's shut down our client
 on his interface.

0:12:24.500000 --> 0:12:26.720000
 Let's go back to the switch.

0:12:26.720000 --> 0:12:33.320000
 And notice that when I look at show IP,
 DHCP snooping, it does say option

0:12:33.320000 --> 0:12:37.840000
 82 is enabled. And
 we don't want that.

0:12:37.840000 --> 0:12:44.280000
 So no IP, DHCP snooping
 information option.

0:12:44.280000 --> 0:12:47.780000
 Turn that puppy off.

0:12:47.780000 --> 0:12:53.360000
 Now when we look at show IP, DHCP
 snooping option 82 is disabled.

0:12:53.360000 --> 0:12:56.180000
 Let's see if that
 fixes our problem.

0:12:56.180000 --> 0:12:59.580000
 Let's go back to the client.

0:12:59.580000 --> 0:13:06.760000
 No shut. Let's go back
 to the server.

0:13:06.760000 --> 0:13:11.660000
 Now it's looking a lot better.

0:13:11.660000 --> 0:13:17.440000
 We can turn off our debug.

0:13:17.440000 --> 0:13:23.460000
 And we can see. If we go up to the top
 here, he just received the discover.

0:13:23.460000 --> 0:13:25.360000
 He received the discover.

0:13:25.360000 --> 0:13:28.680000
 Here's the client identifier.

0:13:28.680000 --> 0:13:33.200000
 And if we go down a little bit further,
 he says, okay, I'm binding the

0:13:33.200000 --> 0:13:35.600000
 client to this pool.

0:13:35.600000 --> 0:13:38.040000
 I'm going to give him 1113.

0:13:38.040000 --> 0:13:41.320000
 And that's what we see
 right down here.

0:13:41.320000 --> 0:13:44.200000
 Sending DHCP offer to the client.

0:13:44.200000 --> 0:13:46.660000
 He says, hey client, why
 don't you take this?

0:13:46.660000 --> 0:13:52.320000
 1113. So he sends a boot reply.

0:13:52.320000 --> 0:13:53.680000
 That's the DHCP offer.

0:13:53.680000 --> 0:13:57.400000
 Now he receives the DHCP request from
 the client where the client says,

0:13:57.400000 --> 0:13:58.960000
 great, I'll accept that.

0:13:58.960000 --> 0:14:01.280000
 The client says, I will take 1113.


0:14:01.280000 --> 0:14:03.000000
 Sounds good to me.

0:14:03.000000 --> 0:14:07.660000
 And now the DHCP server sends his
 last message, which is a DHCP app.

0:14:07.660000 --> 0:14:12.660000
 So the client has received it in this,
 in all this time, we never changed

0:14:12.660000 --> 0:14:15.620000
 the rogue server, but the rogue server
 didn't have an opportunity to send

0:14:15.620000 --> 0:14:20.100000
 an offer. Because the rogue server is
 now connected to an untrusted port.

0:14:20.100000 --> 0:14:23.360000
 So he didn't even see the
 DHCP transactions at all.

0:14:23.360000 --> 0:14:27.700000
 And lastly, if we go back to the switch
 running DHCP snooping, and we

0:14:27.700000 --> 0:14:33.980000
 issue this command, show IP, DHCP, snooping,
 binding, we now see the binding

0:14:33.980000 --> 0:14:40.880000
 table. How the switch has now learned
 of the client's information via

0:14:40.880000 --> 0:14:49.200000
 DHCP snooping. So that concludes this
 live demonstration of DHCP snooping.

0:14:49.200000 --> 0:14:49.980000
 Thank you for watching.