DHCP snooping problem

[gkuzmowycz]

I'm having a problem with DHCP snooping on a 3560. The switch is running 12.2(40)SE, and is acting as a DHCP server for one VLAN only. A second VLAN has its DHCP server external to the switch. If I turn on DHCP snooping for both VLANs, I only get the bindings for the first. The relevant portions of the config are:

ip dhcp pool voice (this is VLAN 174)

   network 172.17.4.0 255.255.255.0

   option 150 ip 172.17.0.10

ip dhcp snooping vlan 174,424

ip dhcp snooping database tftp://172.16.10.100/dhcptest.dat

ip dhcp snooping

On the interfaces

switchport access vlan 424

switchport mode access

switchport voice vlan 174

ip dhcp snooping limit rate 100

On the uplinks

switchport trunk encapsulation dot1q

switchport trunk allowed vlan 1,5,20,21,31,101,110,174,404,420,424,430,450,454

switchport mode trunk

ip dhcp snooping trust

This is the only switch on the network on which I have enabled DHCP snooping so far. In this configuration, the phones get a 174 DHCP address and that gets written properly to the bindings database. The workstations do not get a DHCP address (I have not yet sniffed, but it seems they don't even send a DHCP packet out to the server) and nothing on 424 gets written to the bindings database. The only way I can get the workstations to get a DHCP address on 424 is to turn off DHCP snooping on their port.

sh ip dhcp snoop produces this:

Switch DHCP snooping is enabled

DHCP snooping is configured on following VLANs:

174,424

DHCP snooping is operational on following VLANs:

174,424

with the relevant host interfaces showing Trusted of "no" and the uplinks showing Trusted of "yes"

[Peter Paluch]

Hello,

Is the external DHCP server for the VLAN 424 running IOS? If yes, you need to configure the external DHCP server using the global configuration command

ip dhcp relay information trust-all

The reason is that your 3560 is inserting the DHCP Relay Option 82 identifying the original switch and port where the DHCP request was received from a client, to make sure that when the DHCP server responds (the response will also contain this Option 82 copied from the request), the response will be forwarded only through the port where the request was received. However, switches performing DHCP Snooping do not fill in the Relay Agent IP address in the DHCP request, and IOS DHCP servers are notorious for dropping such packets. The reason is that they fail a sanity check - that if the Option 82 is present, the Relay Agent IP address must also be non-zero.

The above command executed on the external DHCP server allows accepting DHCP requests containing Option 82 and all-zero IP address of a relay agent.

Try to use this command and please let me know if it worked.

Best regards,

Peter

[gkuzmowycz]

Thanks for your prompt and detailed reply. The external DHCP server is an ASA, running 8.4(1). I do not have administrative control of it, and am not familiar with the ASA OS, so I can't tell you what it's doing with Option 82. I thought that was off on the 3560. There are no L3 interfaces for 424 on the 3560, and no SVI, so there is no relay agent defined anywhere.

[Peter Paluch]

Hello,

Yes, the 3560 is configured just as I expected. Hmmm, we can then configure the 3560 to not insert the Option 82, although it should be considered a temporary solution, and if I find out how to reconfigure the ASA (if that's possible at all), then the administrator of the ASA box should be ask to correct its configuration instead.

Try using the following command on the 3560 in the global configuration mode:

no ip dhcp snooping information option

Best regards,

Peter

[Jon Marshall]

Just to add. ASA version 8.4 does not support option 82,  see Table 11-2 in this link -

http://www.cisco.com/en/US/docs/security/asa/asa84/configuration/guide/basic_dhcp.html#wp1194349

Jon

[Peter Paluch]

Jon,

I am not so much interested in seeing whether the ASA supports Option 82 (the IOS does not support it either; the Option 82 is only seldom used by DHCP servers to aid in IP address assignment as it is defined as an opaque value) but rather in knowing

• whether ASA requires that if Option 82 is present then the giaddr must be non-zero
• if the ASA can be configured to accept DHCP packets with Option 82 and all-zero giaddr

Best regards,

Peter

[Jon Marshall]

Peter

Oops, sorry, next time i will read the thread more thoroughly

Jon

[Peter Paluch]

Hey Jon,

No need to apologize. Option 82 is one of the most confusing aspects about the DHCP Snooping. You may have noticed that even I have confirmed some of my "suspicions" in the LAN Switching Ask the expert session, and some things I have found out are slightly different than I originally envisioned them. Kind of sad that there is no solid Cisco whitepaper about the inner workings of DHCP Snooping... Too many misconceptions are out there around the whole DHCP Snooping.

Best regards,

Peter

[gkuzmowycz]

Well, that worked. I now get a DHCP assignment on VLAN 424, and it's inserted in the DHCP snooping database. My question now is why that "should be considered a temporary solution". What do we lose by leaving Option 82 turned off on the access-layer switch? From what I've read, Option 82 is useful primarily in scenarios which do not fit us.

[Peter Paluch]

Hello,

I've had some discussions about the Option 82 on these forums already. If you don't mind, I'll point you towards them as they contain an in-depth discussion.

https://supportforums.cisco.com/message/3262823#3262823

https://supportforums.cisco.com/message/3409873#3409873

In short, the Option 82 is very helpful in limiting the scope of flooding the DHCP response so that it cannot be delivered to another client. Deactivating the Option 82 removes one layer of protection in DHCP snooping. It will not break down, neither will it become useless, but it one of its protection mechanisms will be deactivated.

Best regards,

Peter

[gkuzmowycz]

Thanks again for your comprehensive responses. I have read through the earlier threads that you pointed to, as well as RFC 3046 -- I'm far deeper into this subject that I thought I'd need to be. However, this all leaves me with another question.

  If, as noted in the ASA docs referenced by Jon Marshall above, the ASA's DHCP implementation does not support Option 82, then it seems that neither its apparent behavior (performing a sanity check and dropping the DHCP request packet) nor your desired behavior (copying back the Option 82 field verbatim, with a zero giaddr) are strictly RFC-compliant. The RFC says: "DHCP servers unaware of the Relay Agent Information option will ignore the option on receive and will not echo it back on responses." It seems to me that even if the switch inserts Option 82, all the ASA is required to do is send a DHCP reply without Option 82. Am I missing something here?

[Peter Paluch]

Hello,

There is a confusion, I believe, regarding the meaning of the expression "this DHCP server supports the Option 82". Clearly, the Option 82 requires special handling. One aspect is that the Option 82 should be echoed back to the client. Another aspect is about using the value of the Option 82 as an additional criterium for address assignment to a client. The ASA seems to have a basic understanding about the Option 82 - read further.

While the ASA DHCP server may not allow us to assign addresses depending on the value of the Option 82 (the second aspect), it clearly knows that the Option 82 should be echoed back to client in each server response (the first aspect). Hence, the ASA does in fact understand what the Option 82 is which is completely sufficient for most operations.

The sanity check performed by the ASA DHCP server is not strictly RFC mandated but because of the nature of the Option 82, it is quite logical - the Option 82 is intended to be inserted by relay agents, in which case their address should be inserted into the GIADDR field. An Option 82 present with a zero GIADDR can be considered as a spoofing attempt (an end host inserting its own Option 82 to its requests). That is the reason why such packets are dropped. The fact that it does not align with the DHCP Snooping is caused by the fact that the Option 82 is indeed not added by a relay agent but rather by a switch.

If the ASA knew absolutely nothing about Option 82 then it would simply ignore that option and respond back with a reply without the Option 82, just as you mentioned. However, the ASA appears to understand the Option 82 and the requirement to echo it back, and hence performs the sanity check typical for Cisco implementations. In ideal situation, the ASA should accept the requests with Option 82 even with zero GIADDR and respond back including the Option 82 copied from the request.

Does that make at least a little sense?

Best regards,

Peter

[gkuzmowycz]

It does make sense on one level, yes, and thanks again for so much detail.

It doesn't make sense on another level, as it seems that the switch people at Cisco and the IOS DHCP (or ASA) people are busy shooting each other in the foot, or at the very least are working at cross purposes. If I implement two software features on two different Cisco devices, as designed, using default values/parameters, then completely fundamental technology breaks (i.e. an end device can't get a DHCP address.) I mean, come on, Option 82 is 10 years old, DHCP is nearing 20.

[Peter Paluch]

Hello,

Yes, you are right. If at least there was a clear warning in the documentation about DHCP Snooping that these complications can happen. Being on the safer side and dropping suspicious packets rather than being naively open to the world is not bad per se but these things should be clearly communicated to customers.

In any case... I am glad you got it working. I have skimmed over the ASA documentation but there seems to be no configuration command to allow DHCP requests with zero GIADDR and Option 82 present. We are probably stuck with the current setting on your 3560 for now.

Best regards,

Peter