IP-addresses are not distributed in the Nubian network: how to identify the culprit (except for enikey)?

Question

Computer networks

Good evening. (Below is all the Nubian tin, and the extreme degree of enikeyism, and bad humor.) There is something reminiscent of a LAN, of the following form:

- Switch HP V1910
     - DC1 (W2012: AD, DNS, DHCP, ...)
     - DC2 (Реплика DC2)
     - D-Link DIR-320 (прости, Господи) -> WAN

     - Какой-то PC0
     - Какой-то MFP0

     - AP0
     - AP1

     - Мини-АТС 

     (дальше — веселее)

     - StupidSwitch0 (D-Link DGS-1008)
          - PC0
          - PC1
          - ...
          - PCn
          - MFP

     - StupidSwitch1
          - PC0
          - PC1
          - ...
          - PCn
          - MFP
          
          - StupidSwitch2
                    - PC0
                    - PC1
                    - ...
                    - PCn
                    - MFP

     - StupidSwitchN
          - PC0
          - PC1
          - ...
          - PCn
          - MFP

Nobody heard about any nonsense, like VLAN, or routing, or proxies. Stupid NAT. Stupid UTP.
DCs on Windows Server 2012 run failover regular DHCPs on them, the logs of which do not reveal excesses in any way.
In this case, IP is not issued to anyone.
Computers with unexpired leasing work, computers with static work.
Visual inspection of the loops did not reveal.
And it all started like this: there was an office for itself, and everything worked. The office left, people and their computers remained, the above-drawn equipment (in fact, everything inside the StupidSwitch) was thrown up, mixed and reconnected - but the general structure remained the same. Yes, there is an additional fun: the root switch was configured to receive an IP from DHCP, and the scanner does not detect it on the network.
And so, how can you find out if this is really a loop, and how would you find it faster? Or what other problems could there be?

Answer 1

Correct answer:

1. Wireshark revealed that there are no return requests to DHCP, therefore, hurray, there are no loops.
2. Wireshark revealed that, DHCP requests reach the DHCP server, but it does not try to send answers.
3. And in the end, the little brain guessed to inspect the screw DHCP server and found that the interfaces had fallen off from it. Or interfaces from the server. Moreover, immediately from both (hot-swappable servers). Removing the role, rebooting and installing the role saved the poor enikey. (Even the settings of the areas did not fly off.)

Answer 2

It seems to me that the problem lies in the HP V1910 settings.
In general, for starters, run wireshark on the winserver and see if dhcp requests arrive at it.

Answer 3

There are many options for the problem. Start from the very minimum, turn off everything superfluous, try the Server + 1 PC, if it works, then connect the first Dlink, the PC into it, check again. This is if you do not know how to use wireshark.
In general, there is a feeling that these are really HP settings. Either the DHCP address pool is over...

Answer 4

Come on, maybe outwardly homosexual, but the presence of two AD controllers, the presence of at least one managed switch, the presence of a separate hardware router (yes, dir 320 is not Windows XP with two network cards) - it’s quite ok, for such and such number of computers.
The problem, by the way, is either in the network settings on AD1 or in the HP settings, which, for the sake of treatment, can be reset to default.

Answer 5

Looks like DC1 was plugged into the wrong hole on the HP switch. He ended up in some kind of VLAN, and the problem computers do not see him.
Or see? Checked?
I join the previous speakers about the serial connection of computers with DC via D-Link and resetting HP to default.