About DHCP server troubleshooting

After learning about DHCP, how can we apply it to actual operations? Many people are also unable to cope with many network errors. Next we will share our experience on Troubleshooting DHCP servers. An administrator suddenly finds that the IP address cannot be automatically obtained through the DHCP server, so he can remotely log on to the DHCP server to troubleshoot the problem. First, open the console, add the DHCP component, look at the server, and prompt that it is not authorized. It is so strange that it has never been a problem. What happened suddenly? Log on to the Remote Desktop and check the system logs. In addition to the DHCP Server error, the error code 1030 is displayed.

Here we need to describe the company's network environment:

There is a domain controller, a file server, and a gateway server (computer that installs Routing and Remote Access Services). The file server and gateway server use dual NICs to provide services for the two network segments, two network card IP addresses of the file server: network card 01-172.20.2.8, network card 02-172.20.5.8, network card 03-172.20.2.10, and network card 04-172.20.5.10.

DHCP server troubleshooting: First, we suspect that a DNS problem occurs, so we re-set the DNS and Ping the server with the FQDN. After the test is passed, we can Ping each server, however, after re-authorization, the DHCP server cannot work normally, and the DNS problem is temporarily thrown to one side.

Reset the IP address, and the Remote Desktop Connection is interrupted. After two minutes, the connection still fails. You cannot Ping the new IP Address by using the Ping command, and the original IP address cannot be pinged, it seems that the network card is faulty. It may be that the network card is dead or the driver is not stable. After logging on to the server, restart or uninstall the network card and let the system re-detect and update the driver, the DHCP server still failed to perform normal authorization and lost for a while, so it opened the link provided by the log to check whether the test domain is normal and whether it can communicate with the domain controller, on the DHCP server, Ping the Domain controller's FQDN (Fully Qualified Domain Name: Fully Qualified Domain Name). The correct IP address can be resolved and the access can be normal through ICMP packets, I tested \ my domain \ again, and the access can also be normal. Is my permission insufficient and the authorization cannot be completed normally?

I checked the membership of my account on the domain controller. It was an enterprise administrator. Didn't the domain controller handle the request correctly? So I restarted the domain controller, restarted the DHCP server, and authorized again, still cannot succeed.

When I was about to give up and use the System State backup a few days ago for restoration, I suddenly thought of a strange phenomenon when a client was troubleshooting, when I Ping "My Domain", I resolved a public IP address, so I looked at the DNS server (Domain Controller) again and checked the logs. There were no errors, on the DHCP server, Run "IPconfig/flushdns" and then restart the DNS server in "IPconfig/registerdns". The fault persists.

I was really prepared to give up. I tried it and pinged "My Domain" on the Domain controller, prompting that the Domain could not be resolved. So I opened the DNS console, check the SRV resource records of all roles in AD. They are normal. Stop DNS again and Ping "My Domain". It turns out to be a public IP address. The loss instantly drops from 80% to 5%, A host record pointing to "My Domain" is created (pointing it to the Domain controller) [This is used to correctly resolve the Domain name. Do not incorrectly resolve the IP address of the Domain controller to another IP address, the group policy cannot be applied, or some operations that need to send requests to the Domain controller cannot be completed], and the DNS server is restarted, and the Domain controller can Ping "My Domain" again ", finally, the resolution was successful. With a try, the DHCP server was released again and the DNS was re-registered. The attempt to authorize the DHCP server was a dead horse, and the exciting time was coming, the red downward arrow turns into a green upward arrow !!! DHCP server authorization is successful.

DHCP server troubleshooting Summary: I have read some online saying that it is useless to use the same model and install the same driver if a single Nic is required. I have a dual-nic. Not only are the models different, but the transmission rate is not the same!

The above DHCP server troubleshooting experience only reminds you that when you cannot solve the problem on one server, you can look a little more broadly and try to look at the parent server related to it, or the associated server, the problem may become simple.