Administrator Guide

1. The client initially broadcasts a DHCPDISCOVER message on the subnet to discover available DHCP servers. This message includes
the parameters that the client requires and might include suggested values for those parameters.
2. Servers unicast or broadcast a DHCPOFFER message in response to the DHCPDISCOVER that offers to the client values for the
requested parameters. Multiple servers might respond to a single DHCPDISCOVER; the client might wait a period of time and then act
on the most preferred offer.
3. The client broadcasts a DHCPREQUEST message in response to the offer, requesting the offered values.
4. After receiving a DHCPREQUEST, the server binds the clients’ unique identifier (the hardware address plus IP address) to the
accepted configuration parameters and stores the data in a database called a binding table. The server then broadcasts a DHCPACK
message, which signals to the client that it may begin using the assigned parameters.
5. When the client leaves the network, or the lease time expires, returns its IP address to the server in a DHCPRELEASE message.
There are additional messages that are used in case the DHCP negotiation deviates from the process previously described and shown in
the illustration below.
DHCPDECLINE A client sends this message to the server in response to a DHCPACK if the configuration parameters are
unacceptable; for example, if the offered address is already in use. In this case, the client starts the configuration
process over by sending a DHCPDISCOVER.
DHCPINFORM A client uses this message to request configuration parameters when it assigned an IP address manually rather
than with DHCP. The server responds by unicast.
DHCPNAK A server sends this message to the client if it is not able to fulfill a DHCPREQUEST; for example, if the requested
address is already in use. In this case, the client starts the configuration process over by sending a
DHCPDISCOVER.
Figure 30. Client and Server Messaging
Implementation Information
The following describes DHCP implementation.
• Dell EMC Networking implements DHCP based on RFC 2131 and RFC 3046.
• IP source address validation is a sub-feature of DHCP Snooping; the Dell EMC Networking OS uses access control lists (ACLs)
internally to implement this feature and as such, you cannot apply ACLs to an interface which has IP source address validation. If you
configure IP source address validation on a member port of a virtual local area network (VLAN) and then to apply an access list to the
VLAN, Dell EMC Networking OS displays the first line in the following message. If you first apply an ACL to a VLAN and then enable IP
source address validation on one of its member ports, Dell EMC Networking OS displays the second line in the following message.
% Error: Vlan member has access-list configured.
% Error: Vlan has an access-list configured.
NOTE:
If you enable DHCP Snooping globally and you have any configured L2 ports, any IP ACL, MAC ACL, or DHCP
source address validation ACL does not block DHCP packets.
• Dell EMC Networking OS provides 40000 entries that can be divided between leased addresses and excluded addresses. By
extension, the maximum number of pools you can configure depends on the subnet mask that you give to each pool. For example, if all
pools were configured for a /24 mask, the total would be 40000/253 (approximately 158). If the subnet is increased, more pools can
be configured. The maximum subnet that can be configured for a single pool is /17. Dell EMC Networking OS displays an error
message for configurations that exceed the allocated memory.
• This platform supports 4000 DHCP Snooping entries.
• All platforms support Dynamic ARP Inspection on 16 VLANs per system. For more information, refer to Dynamic ARP Inspection.
Dynamic Host Configuration Protocol (DHCP)
233