A DHCP client will not always obtain an IP address because maybe it cannot connect to the DHCP server. An unlikely reason is that the address pool is exhausted; in that case, the local machine will allocate an Automated Private IP Address (APIPA) starting with 169.254.x.x. This is an excellent aid to troubleshooting, as it lets the network engineer know that the client cannot contact the DHCP server. There are many reasons that this happens, so let's look at the DHCP process:

If the DHCP client is on another subnet, it can cause some problems:

• RFC-1542-compliant router: A device that connects different networks and subnets together. DHCP-broadcast traffic will pass through an RFC-1542-compliant router, but in figure, the router is not a RFC-1542-Compliant router, therefore broadcast traffic from Computer A will not get to the DHCP server, and an APIPA address will be allocated that will prevent the client from obtaining network resources.
• Opening ports: If the router is a not an RFC-1542-compliant router, you could open UDP ports 67 and 68 by setting allow rules on the ACL of the router, otherwise the DHCP broadcast will suffer from an implicit deny.
• DHCP relay agent: A DHCP relay agent is programmed with the IP address of the DHCP server, therefore it contacts the server using unicast and not broadcast transmission. The DHCP relay agent acts as a set of ears listening for DHCP discover requests. It then acts as a proxy and obtains an IP address from the DHCP server to return to the requesting client.