Search this Blog

Thursday, January 6, 2011

DHCP snooping on globally and on the right VLANS the DHCP relaying between the core and the DHCP server

Scenerio:

As part of a tech refresh project at a large campus and due to several issues caused by (l)users plugging in home routers to the network and causing DHCP issues we am looking to enable DHCP snooping. During the tech refresh the access switches will be upgraded first then the core. The new access switches are 4510R+E/Sup7 running latest IOS XE base license and only doing switching . The new cores are 6509 Sup 720's configured as a VSS cluster, handle all the routing for VLANS and have the IP helper statements. The DHCP server that supports all the VLANS is a Windows 2008 server directly connected to the core. We have also read all the info we could find on DHCP snooping but am still a little fuzzy about if it changes how the DHCP server handles requests.

Questions:

  • 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? In particular they dont need IP helper statements or layer-3 interfaces for all of their VLANS, right?
  • While we understand that DHCP snooping will only be marginally effective if it is not turned on on the core, there is no reason we 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.
  • We got that on the access layer switches the uplinks to the core are trusted, but we are not 100% on whether the same interfaces are trusted on the cores. We dont think so but want to be sure. Of cource the cores do trust the actual interface the DHCP server is plugged in on
  • The most confusing part is all the Option-82 stuff. As near as we can tell its optional for the server to use the Option-82 information. We believe that if all we 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?

Are there really any gotchas to this or in our case do we really just need to turn it on globally and per vlan, trust the uplinks on the acccess switches and the DHCP server interface on the core and call it a day?

Tips:

Q. 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.

Q. 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.

Q. While we understand that DHCP snooping will only be marginally effective if it is not turned on on the core, there is no reason we 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.

Click here for the Configuration Guide. From the 2960 Configuration Guide at

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!

Q. 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?

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)

Click here for the docs

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
Citation - This blog post does not reflect original content from the author. Rather it summarizes content that are relevant to the topic from different sources in the web. The sources might include any online discussion boards, forums, websites and others.

No comments :

Post a Comment

 
/* Google Analytics begin ----------------------------------------------- */ /* Google Analytics end ----------------------------------------------- */