DHCP Snooping and Option 82

This is yet another one of those topics I always passed over.  "DHCP snooping", I'd say to myself, "is too simple to bother with".  I've also never put it into production, so I've absolutely never set it up.  Figured this was as good a time as any.  When I write about these topics I like to learn all aspects of them, so I'll delve into the problems created by DHCP option 82 as well.

We'll start out really simple on this one just to get the feature working.

One VLAN (100), one subnet.  R1 will be the DHCP server, R3 will be the DHCP client.  SW1 will be running DHCP snooping.  Once again, I tend to use GNS3 for diagrams (probably obvious from the icons), but this cannot actually be labbed in GNS as the 16-port switch that can be inserted in the 3725 doesn't have the capacity to perform DHCP snooping.  I'm using real 26xx series routers and 3560 switches.

First we'll start without snooping.

R1:
interface FastEthernet0/0
 ip address 192.168.100.1 255.255.255.0

ip dhcp pool DHCPSERVER
   network 192.168.100.0 255.255.255.0

SW1:
interface FastEthernet0/1
 switchport access vlan 100
 switchport mode access

interface FastEthernet0/3
 switchport access vlan 100
 switchport mode access

R3:
interface FastEthernet0/0
 ip address dhcp

And the outcome?

R3:
*Mar  2 18:28:21.315: %DHCP-6-ADDRESS_ASSIGN: Interface FastEthernet0/0 assigned DHCP address 192.168.100.6, mask 255.255.255.0, hostname R3

OK great, we were assigned 192.168.100.6.  Of interesting note, but will only briefly be touched on in this document, are the mentions of "pool class" and "circuit id" - these fields are part of Option 82, which will be discussed later.

We'll turn on DHCP snooping next, but first let's consider why we'd want to turn it on.  There are four primary reasons:
- Prevent rogue DHCP servers from answering before the real DHCP server(s).  Rogue DHCP servers would likely be interested in handing out a malicious default gateway that could intercept information before handing it off to the real default gateway.
- Prevent a malicious "client" from requesting hundreds of addresses and using up the entire pool; a DOS-style attack, where new clients would be unable to get an address.
- IP Source Guard (discussed later)
- Dynamic ARP Inspection (discussed later)

SW1:
ip dhcp snooping
ip dhcp snooping vlan 100  ! you need to turn it on on the specific VLANs you want it on.

interface Fa0/1
  ip dhcp snooping trust  ! don't forget to trust the port your DHCP server is connected to
  ip dhcp snooping limit rate 5 !  DHCP packets allowed per second (keep low to avoid DOS)

Should work great right?

R3(config-if)#no ip address dhcp
R3(config-if)#ip addr dhcp

[wait 60 seconds]

R3(config-if)#do show ip int fa0/0 | i DHCP
  Internet address will be negotiated using DHCP

Uh-oh, no IP address.  We also have no output on R1, so we're going to have to enable the debug to find out what's going on.

R1#debug ip dhcp server packet
*Mar  2 19:11:28.969: DHCPD: inconsistent relay information.
*Mar  2 19:11:28.969: DHCPD: relay information option exists, but giaddr is zero.

Wait what?  giaddr?

Defined in RFC 2131, the giaddr is used in DHCP relay scenarios to indicate which pool/subnet the DHCP server should assign the address from.  There's really no need for it here, as we're not using a relay.  However, option 82 has been set by the snooping process on the 3560.  Option 82?  Option 82 is used in provider networks to give extra information to the DHCP server regarding where a device is located.  The details of Option 82 aren't key to this post, or, as best I can tell, to the CCIE R&S.  However, if a router sees Option 82, by default, it expects the giaddr to be non-zero as well. 

So now we have two options:
- Tell the switch not to set Option 82
- Tell the router to ignore Option 82

For the first option, we can globally disable the setting of Option 82 with:

SW1:
no ip dhcp snooping information option

R3(config-if)#no ip address dhcp
R3(config-if)#ip addr dhcp
R3(config-if)# Mar  2 20:11:27.989: %DHCP-6-ADDRESS_ASSIGN: Interface FastEthernet0/0 assigned DHCP address 192.168.100.6, mask 255.255.255.0, hostname R3

Or we can turn that option back on:

SW1:
ip dhcp snooping information option

And disable the check for zero gi-addr on the DHCP server:

R1:
ip dhcp relay information trust-all

This command instructs the DHCP server that blank giaddr is acceptable, even if option 82 is set.

Let's make this trickier and add a dhcp relay.



We've stuck VLAN 101 on the back end of R3.  R3 will relay DHCP requests from VLAN 101 back to R1.  Here's the relevant added config:

R1:
ip dhcp pool DHCPSERVER101
   network 192.168.101.0 255.255.255.0

router eigrp 1    ! R1 has to have a route back to R3's interface on VLAN 101
 network 0.0.0.0

R3:
interface FastEthernet0/1
 no shutdown
 ip address 192.168.101.1 255.255.255.0
 ip helper-address 192.168.100.1  ! Relay VLAN 101 requests to the DHCP server

router eigrp 1   ! R3 has to advertise a route back to its interface on VLAN 101
 network 0.0.0.0

SW2 is generally blank except for the creation of VLAN 101 and the appropriate access port assignments.

R5:
interface FastEthernet0/1
 no shutdown
 ip address dhcp

Once again, should be all peachy, right?

Not so fast....

SW1# *Mar  2 21:22:44.713: %DHCP_SNOOPING-5-DHCP_SNOOPING_NONZERO_GIADDR: DHCP_SNOOPING drop message with non-zero giaddr or option82 value on untrusted port, message type: DHCPDISCOVER, MAC sa: 0012.43c1.6f20

Now we have a condition where giaddr is set and option 82 isn't on the packet headed from R3 towards R1 via SW1.  The giaddr must be set; otherwise R1 wouldn't know which pool to assign from.  How to fix this?

We basically have to push the DHCP "trust boundary" downstream.  In this case, R3 now also needs to become a trusted port:

SW1(config)#int fa0/3
SW1(config-if)#ip dhcp snoop trust

...and then all is well:

R5(config-if)# *Jan  4 01:00:58.896: %DHCP-6-ADDRESS_ASSIGN: Interface FastEthernet0/1 assigned DHCP address 192.168.101.2, mask 255.255.255.0, hostname R5

This isn't really related to DHCP snooping, but here's a way to create a really nasty debugging task - by default, the "ip helper-address" command does a number of things, including relaying DHCP requests.  But did you know that the DHCP function can actually be disabled?

R3(config)#no service dhcp

R5(config-if)#no ip add
R5(config-if)#ip add dhcp

[wait 60 seconds]

...no address.

The service dhcp needs to be enabled for ip helper-address to relay DHCP requests.

Now let's look at one last scenario:



VLAN 100 spans both switches.  It's on a trunk between SW1 and SW2.  Now let's setup DHCP snooping on both switches.  It's already enabled on SW1.

SW2:
ip dhcp snooping vlan 100
ip dhcp snooping
R5(config-if)#no ip add
R5(config-if)#ip add dhcp
SW1#*Mar  2 22:11:23.017: %DHCP_SNOOPING-5-DHCP_SNOOPING_NONZERO_GIADDR: DHCP_SNOOPING drop message with non-zero giaddr or option82 value on untrusted port, message type: DHCPDISCOVER, MAC sa: 0019.2fb8.d552

We've seen this before.  Except this time, option 82 is set, and giaddr isn't.  We don't really care about option 82 in this topology, so we have two choices of how to deal with this problem:
- Stop SW2 from setting option 82 (As seen earlier)
   SW2(config)#no ip dhcp snooping information option- Tell SW1 to accept option 82 on untrusted ports
   SW1(config)#ip dhcp snooping information option allow-untrusted

In addition, the DHCP snooping process creates a database of IP address to MAC addresses that can be used for other security tasks, discussed below.  Since this database can be of some importance, you can optionally store it to flash, tftp, etc.  For example:

ip dhcp snooping database flash:/dhcp.txt
In the introduction I mentioned that IP Source Guard and Dynamic ARP Inspection were motivating factors for using DHCP Snooping.  Both of these features rely on the DHCP snooping database to function.

IP Source Guard will inspect traffic from hosts to be certain they're not spoofing their IP address or, optionally, MAC address.  As mentioned, it knows the MAC and IP information from the DHCP snooping database.  Enabling the feature is simple:

SW1(config-if)#ip verify source ! check IP addresses
SW1(config-if)#ip verify source port-security ! check IPs & MACs

If you don't want to rely strictly on the DHCP snooping database, you can make manual entries:

SW1(config)#ip source binding mac-address vlan vlan ip-address interface interface

Of important note, source guard can be used in a non-DHCP environment using the above command to populate the reference table, however, you must still enable dhcp snooping globally and on the specific VLAN in order for source guard to function!

Dynamic ARP inspection blocks "a variety of ARP-based attacks", according to the documentation.  The usage is simple.  Drop ARPs that shouldn't be coming based on the information seen in the DHCP snooping table. 

SW1(config-if)#ip arp inspection trust  ! need to trust other switches
SW1(config)#ip arp inspection vlan 100  ! turn the feature on globally for the VLAN
That's the basics for enabling it.

Cheers,

Jeff