Hello Nathan,
Given that the access switches are only switching, they only need DHCP
snooping turned on (both globally and on the VLANS) and their uplinks to
the core set as trusted, right?
Correct.
In particular they dont need IP helper statements or layer-3 interfaces for all of their VLANS, right?
Correct. The ip helper-address statement would be necessary only if the switches were performing inter-VLAN routing and the DHCP server was located in a different VLAN.
While I understand that DHCP snooping will only be marginally effective
if it is not turned on on the core, there is no reason I cannot deploy
it first at the access layer without touching the core configurations to
avoid large amounts of change-control paperwork, right? Then when the
core is upgraded and DHCP snooping properly enabled it will work.
To my best knowledge, the contrary is true. The DHCP Snooping is an access layer protection service - it does not belong into the core of the network. There is nothing to protect in the core once the DHCP messages have beein properly sanitized at the network boundary. For some inexplicable reason, many people think that the DHCP Snooping must be activated throughout the network. The fact is that the DHCP Snooping protects from
- DHCP messages being sent to ineligible devices
- Ineligible devices posing as DHCP servers
From this it naturally follows that it is the network boundary, or the access layer, where this protection is most effective. So in your case, I believe that activating the DHCP Snooping only on the access layer is actually what you want to do.
I got that on the access layer switches the uplinks to the core are
trusted, but I am not 100% on whether the same interfaces are trusted on
the cores. I dont think so but want to be sure. Of cource the cores do
trust the actual interface the DHCP server is plugged in on
If you planned to activate the DHCP Snooping on the core devices then the uplinks between the access and core switches would need to be configured as trusted both on the core and access switches. Otherwise, the core ports would drop DHCP messages received from clients because the access layer switches running DHCP Snooping insert the DHCP Option 82 into the sanitized DHCP messages, and untrustred ports drop all DHCP messages that have Option 82 present.
From the 2960 Configuration Guide at
http://www.cisco.com/en/US/docs/switches/lan/catalyst2960/software/release/12.2_55_se/configuration/guide/swdhcp82.html#wp1078853
The switch drops a DHCP packet when one of these situations occurs:
A packet from a DHCP server, such as a DHCPOFFER, DHCPACK, DHCPNAK, or DHCPLEASEQUERY packet, is received from outside the network or firewall.
A packet is received on an untrusted interface, and the source MAC address and the DHCP client hardware address do not match.
The switch receives a DHCPRELEASE or DHCPDECLINE broadcast message that has a MAC address in the DHCP snooping binding database, but the interface information in the binding database does not match the interface on which the message was received.
A DHCP relay agent forwards a DHCP packet that includes a relay-agent IP address that is not 0.0.0.0, or the relay agent forwards a packet that includes option-82 information to an untrusted port.
As I indicated, however, I personally discourage running the DHCP Snooping on core devices - I see no reason for that. Please correct if I am wrong here!
The most confusing part is all the Option-82 stuff. As near as I can
tell its optional for the server to use the Option-82 information. I
believe that if all I do is turn DHCP snooping on globally and on the
right VLANS the DHCP relaying between the core and the DHCP server will
continue working just like it is today, is that correct?
LOL, my favourite stuff about the DHCP Snooping is the Option 82 Interesting how much confusion this topic brings...
The Option 82 was originally created in order to provide the DHCP relay agent the ability to identify itself and the client that sent the original unmodified DHCP message. The DHCP server then may use this information to perform some special assignment policies to the client. The format of the Option 82 is not strictly specified, only its basic structure is fixed. You can read more about it and all the rationale in the RFC 3046. One of the key points to remember here, however, is that the DHCP server may or may not recognize the Option 82, but regardless of that, it has to copy the value of the Option 82 received in a client's DHCP message to all its replies sent to that client.
The DHCP Snooping uses the Option 82 differently. It does not expect nor require that the DHCP server understands the Option 82 or handles it in the special way. The Option 82 is inserted by the access switches performing the DHCP Snooping and it contains two important parts:
- The Circuit ID that identifies the port to which the client is connected (the VLAN and the physical port location in a switch)
- The Remote ID that identifies the access switch to which the client is connected (by the MAC address of the switch)
See http://www.cisco.com/en/US/docs/switches/lan/catalyst2960/software/release/12.2_55_se/configuration/guide/swdhcp82.html#wp1105589
Now, when an access switch performing the DHCP Snooping receives a DHCP client message on an untrusted port, this will happen:
- The switch will insert the Option 82 into the client's DHCP message. The Option 82 will identify the particular switch and the port where the client is attached
- The switch will forward the DHCP message according to its destination MAC address (i.e. in a completely normal way)
- The server will receive the DHCP message containing the Option 82. It is irrelevant to DHCP Snooping whether the server takes the value of the Option 82 into consideration. However, when the server replies, it will insert the original value of the Option 82 to the response.
- The access switch will eventually receive the DHCP response. By looking at the Option 82, it knows exactly through which port shall the message be forwarded back to the client - and only to the client - even if the response was broadcasted!
Note that the Option 82 helps tremendously to exactly identify the access switch and its port where the client is attached. If other switches with DHCP Snooping received this DHCP message (because of flooding or because of broadcast addressing requested by the client), they would drop this message because they would understand after looking at the Option 82 that the client is attached elsewhere. The Option 82 thereby helps to assure that the DHCP communication between a particular client and DHCP server will not leak to other clients.
There is one gotcha related to the Option 82. A switch performing DHCP Snooping inserts the Option 82 into the DHCP messages from clients. However, each DHCP message contains a field called GIADDR where the IP address of the relay agent is recorded if the DHCP message was relayed. Clearly, when a DHCP message passes through a DHCP Snooping switch, it is not relayed (i.e. taken from one VLAN and rerouted into another), so an access switch does not modify the GIADDR field which remains set to 0.0.0.0. However, at least the Cisco DHCP Server implementation in IOS performs a sanity check on received DHCP messages and it drops DHCP messages that contain the Option 82 but whose GIADDR field is set to 0.0.0.0 (i.e. unitialized). This can be seen the debug ip dhcp server packet output:
Router# debug ip dhcp server packet
*Sep 9 01:59:40: DHCPD: inconsistent relay information.
*Sep 9 01:59:40: DHCPD: relay information option exists, but giaddr is zero
Under normal circumstances, such a sanity check is logical - how come that a DHCP message contains the Option 82 (i.e. the DHCP Relay Agent Information Option) when there is no DHCP Relay identified in the GIADDR field? However, with the DHCP Snooping on access layer switches, such DHCP messages are normal and expected. Therefore, it is necessary to deactivate this sanity check on the Cisco box that is running the DHCP server using either the global configuration command ip dhcp relay information trust-all or only on selected routed (i.e. L3) interfaces using the interface level command ip dhcp relay information trusted.
To sum it up:
- The Option 82 is A Good Thing (TM) because it helps to deliver the DHCP messages only to the client for which they are intended. All suggestions to deactivate the insertion of the Option 82 on access switches running DHCP Snooping are junk The Option 82 is inserted by DHCP Snooping switches into DHCP messages by default - no extra configuration is needed.
- Go through the most straightforward way - when deploying the DHCP Snooping, do not initially modify anything regarding the Option 82. Verify whether your clients can receive their IP config via DHCP. If yes then there is nothing more to tweak. Otherwise, proceed further.
- If you are running a DHCP server on an IOS-based device (router, switch), you may need to use the command ip dhcp relay information trust-all (global config) or ip dhcp relay information trusted (interface level) to allow the DHCP messages with the added Option 82 and unitialized GIADDR field to be accepted. These commands are necessary only on the device where the DHCP server is running, not on the access layer switches. You may want first to perform the debug as I suggested earlier, and only if you see that the packets are being dropped, add these commands to the configuration.
- I am not sure if these commands have to be added also to a switch performing DHCP Relay function - I may verify that tomorrow in a lab.
- If you are using a different DHCP server you have to try it experimentally whether it is happy with DHCP messages having Option 82 present and GIADDR field unitialized
Sorry for the lengthy answer... I hope I did not bore you to death. You are welcome to ask further! I'll try to be more concise the next time
Best regards,
Peter
