The first one we're going to look at is DHCP Snooping.
DHCP Snooping is a security technology that network administrators can use combat the problem of rogue DHCP servers. With DHCP Snooping enabled switches are configured to only allow DHCP messages from ports that are defined as "trusted" while discarding messages received on all other ports.
And that's it. Simple, yes? But wait, there's more!
As a function of this snooping a DHCP Snooping enabled switch also creates a snooping binding database to store all the DHCP related information it sees. This snooping binding database can be leveraged by two more security technologies, IP Source Guard and Dynamic ARP Inspection, that I'll look at in this 3 post series.
But I think I'm getting a little too far ahead of myself. Lets back up and look at DHCP Snooping in action, and then move outward from there.
For this series of Blog posts I'm going to be using this very simple topology.
R6 will be our DHCP client, R7 is a DHCP relay agent configured with a helper-address, and R8 will be our DHCP server. Cat2 is sitting between R6 and R7 and will be configured for DHCP Snooping. OSPF is running between R7 and R8 with all interfaces in area 0.
To configure DHCP Snooping on our switch we must first enable it globally, and then enable it on our target VLAN. Finally, we specify which port(s) our DHCP server is connected to by marking them as trusted.
Cat2(config)#ip dhcp snooping
Cat2(config)#ip dhcp snooping vlan 67
Cat2(config-if)#ip dhcp snooping trust
And viola! DHCP Snooping is now enabled. But what does this really mean? And what have we gained?
Well, for starters, we have changed the behavior of this switch with regards to the way it now handles DHCP packets. Let's look at the basic information:
Cat2#sh ip dhcp snoopingSwitch DHCP snooping is enabledDHCP snooping is configured on following VLANs:67DHCP snooping is operational on following VLANs:67DHCP snooping is configured on the following L3 Interfaces:Insertion of option 82 is enabledcircuit-id format: vlan-mod-portremote-id format: MACOption 82 on untrusted port is not allowedVerification of hwaddr field is enabledVerification of giaddr field is enabledDHCP snooping trust/rate is configured on the following Interfaces:Interface Trusted Rate limit (pps)------------------------ ------- ----------------FastEthernet0/7 yes unlimitedCat2#
We can see that snooping is enabled, and that we is configured and operational on VLAN 67. We also see that insertion of option 82 is enabled, and the format used for the suboptions. At the end we see that we have defined port F0/7 as trusted.
Let's give this a test now shall we?
R6(config-if)#do sh run int f0/0
Current configuration : 85 bytes
ip address dhcp
We should get an address pretty quickly... I'm going to turn on 'debug dhcp' to watch... I'm editing the output for brevity. Run your own debug to see the entire output.
Looking at out timestamps we're over a minute waiting for DHCP to work. This is not the way things should be working. Before turning on DHCP snooping this did work, so why is it not now? What's missing?
The answer is nothing is missing, and that's the problem!
The reason why this is not working was shown to us above in the output of the 'show ip dhcp snooping' command.
Insertion of option 82 is enabled
Those cold, hard words have forced upon us a reality where the default setting for two different types of Cisco devices will simply not interoperate. One says tomato, the other says tomato.
(That doesn't really work in print as well as it does when spoken...)
What I'm taking my sweet time to get around to saying is that when we enabled DHCP Snooping on our switch we also enabled the behavior where the switch inserts option 82 into DHCP DISCOVER packets that traverse it. The problem with this is that by default Cisco routers do not trust option 82 and if a DHCP relay sees an DHCP DISCOVER with the option 82 suboption of GIADDR set to all zeros then it will drop the packet!
The proof is in the pudding:
This post is starting to read like a Tarantino film, what with everything out of order... Let's back up (again) and look at DHCP Option 82.
DHCP Option 82 is designed to allow a DHCP server to know where a DHCP client actually connects to the network so it can allocate an address form the correct pool. This scenario is important when you have a DHCP server that is not on the same segment as the DHCP clients, as is the case in many many networks. There are 3 sub options inside option 82. These are:
Option 82 is specified in RFC 3046, and if you wish to read up on the suboptions above, I encourage you to do so. In our experiment the only suboption we're concerned with is GIADDR, and that's the only field I'm going to discuss here.
GIADDR means "gateway IP address", and this field is usually populated by DHCP relay agents with the IP of the interface that received the DHCP packet. When the DHCP server receives a DISCOVER it looks at the GIADDR field and then compares that address to the pools it has configured to decide from which pool it should allocate an address from. Basically this is saying that the DHCP server allocates an address from the same range of addresses that the GIADDR address is a part of.
Back to our little problem... Let's look again at the relevant output of 'show ip dhcp snooping":
Insertion of option 82 is enabledcircuit-id format: vlan-mod-portremote-id format: MAC
This is great... But what about GIADDR? Well, since it doesn't say I'll tell you. The switch sets GIADDR to all zeros because it doesn't know what the GIADDR should be, and it has no way to know. Option 82 must contain all three suboptions, and because we are inserting option 82 it uses the only value it can: all zeros.
Moving forward again to our default router behavior, a Cisco router will drop a DHCP packet with a GIADDR of all zeros. Normally this is not a problem because most DHCP clients by default do not insert option 82, and therefore there is no GIADDR at all. But when we enabled DHCP snooping on our switch, the switch, by default, inserts option 82 with a GIADDR of all zeros, and we now have the problem we are seeing.
There's 2 ways to fix this. We can either tell the switch to not insert option 82, or we can tell the router to trust DHCP packets with a GIADDR of all zeros:
Cat2(config)#no ip dhcp snooping information option
R7(config)#ip dhcp relay information trust-all
Either way our problem will be "fixed" and R6 will finally get an address:
Alright, so what else do we have here? Well, we now have the beginnings of our DHCP snooping bindings database:
This database is used to track which MAC address is assigned which IP address, and on what port is resides. It also tracks the lease time, and the method which it knows about the binding (Type). A switch can either learn about a binding via DHCP Snooping, or they can be statically defined by an administrator by using the following EXEC mode command:
The only other bit I should show you is what happens when we get a rogue DHCP server. To do that I'm going to add R2 on port f0/2 of Cat2, and fire up a DHCP server there without marking the port as trusted. Here's the 'debug ip dhcp server' on R2:
R2#deb ip dhcp server packetDHCP server packet debugging is on.R2#
Yeh... Pretty informational eh? Well, the thing is that Cat2 doesn't even forward the DHCP DISCOVER to R2 since it's not connected to a trusted port. In other words, our rogue DHCP server never gets a chance to respond to the DHCP request at all!
Just for kicks, here's the entire 'debug ip dhcp snooping' and 'debug ip dhcp snooping packet' output from Cat2 with the configuration we created above, and R2 connected as our rogue. If you read through it you'll see all the neat little bits happening.
And that's going to be it for DHCP Snooping. You can find the next two follow up posts using the following links: