Troubleshooting DHCPv4 is the most important topic because of the importance of DHCP services. It is the most important service for a small, medium and large network. In this article, we will take a look at several common DHCP errors and their solution.DHCPv4 failure occurs due to multiple reasons, such as problem in operating system, network interface card, line cable issues, relay agent problem and also the configuration problem. The systematic approach is needed to troubleshoot DHCP server problems.
Troubleshooting DHCPv4 IP Address Conflicts
An IP address conflict occurs when two communication terminals on a network are assigned the same IP address. The terminal can be a mobile device, PCs, or any network interface card (NIC). Normally IP address conflicts between two devices make either one or both of them unusable for network operations.
When the lease of a device using DHCP has expired and the client still connected to a network. If the client does not renew the lease on expiring, then the server can reassign that address to another client. When the first client reboots, it requests an IPv4 address from the server. When the server does not respond quickly, the client uses the last assigned IPv4 address. This situation results in an IP address conflict. We can check the IP address conflict using show ip dhcp conflict. The command shows all address conflicts recorded by the DHCPv4 server.
The client uses ARP to detect conflicts and the server uses the ping command to detect clients. If an address conflict is detected, the address is removed from the pool and not assigned until an administrator resolves the conflict.
Verify Physical Connectivity
Verify the physical connectivity of the devices with servers. We can also use the show interfaces <interface> command to verify that the router interface acting as the default gateway. The state of the interface must be up; otherwise, the port does not pass traffic, including DHCP client requests.
Test Connectivity using a Static IP Address
We can verify the network connectivity using the static IPv4 address information on a client computer. If the client computer is unable to reach network resources with a statically configured IPv4 address, the cause of the problem is not DHCPv4. At this point, network connectivity troubleshooting is required.
Troubleshooting DHCPv4 Operation on the Same Subnet or VLAN
The problem of DHCP may be related to the DHCP relay agent. To differentiate whether DHCPv4 is functioning correctly when the client is on the same subnet or VLAN as the DHCPv4 server. If DHCPv4 is working correctly within the same subnet or VLAN, the problem may be the DHCP relay agent.
Verify Router DHCPv4 Configuration
In case there is a DHCPv4 server on a separate LAN from the client, the router interface connected to that client must be configured to relay DHCPv4 requests using “IPv4 helper-address” command. If the IPv4 helper address is not set, client DHCPv4 requests are not forwarded to the DHCPv4 server. To verify the IPv4 helper address configuration use the following procedure:
The ip helper-address command is necessary to be configured on the correct interface. It and must be configured on the inbound interface of the LAN containing the DHCPv4 client workstations. The IP address of the DHCPv4 server must be correct. We can check and verify this information using the show running-config command. The figure below illustrates the output of the show running-config command.
We can also use the show ip interface command to verify the DHCPv4 relay on an interface. Which is already discussed in the previous lesson.
Another important verification is a service dhcp. Verify that the no service dhcp has not been configured. If the router is configured with this command then all DHCPv4 server and relay functionality on the router is disabled. The running-config file will now display the service dhcp because it is the default configuration. If no service dhcp is configured simply use the service dhcp command in global configuration mode
Some time routers configured as DHCPv4 servers not receiving requests from the client and the client cannot get an IP address from the server. So, the first thing is to verify that the router is receiving the DHCPv4 request from the client. For this purpose, we can use an ACL for debugging output.
We know that port number 67 and port number 68 are used as DHCPv4 ports. So we can configure ACL for these ports permitting them. The figure below shows an extended ACL permitting only packets with UDP destination ports of 67 and 68 and apply the ACL to corresponding interface inbound. After configuring an extended ACL we can use the debug ip packet command to display only DHCPv4 messages.
Now we can verify the incoming traffic from gigabitEthernet 0/2 for UDP port 67 and 68 using the “debug ip packet 101” command Another command for troubleshooting DHCPv4 operation is the debug ip dhcp server events command. This command reports server actions, like address assignments and database updates.