Короткий ответ

Конфликт — два интерфейса считают себя владельцами одного IPv4, чаще 10.0.10.10 или шлюз 10.0.10.1. Не меняйте адрес «пострадавшего» сервера первым шагом: вы замаскируете дубль. Снимите ARP с нескольких точек: MAC A и MAC B на один IP. По MAC найдите порт коммутатора, VM, резервацию DHCP.

Windows пишет Microsoft-Windows-TCPIP Event ID 4199 (и связанные 4198). Ubuntu: duplicate address detected в dmesg/journalctl.

Симптомы и как отличить

  • Всплывающее «Windows detected an IP address conflict»;
  • SSH/RDP «то свой хост, то чужой» (ключ host mismatch);
  • ping есть, но MAC в arp -a меняется;
  • DHCP-клиент уходит в APIPA после NAK.

Не путать:

  • Один MAC, неверный IP в кеше — ARP-кеш.
  • Нет адреса вовсе — 169.254.
  • Одинаковый IP в разных VLAN без L2 — это не конфликт, а совпадение RFC1918; ломается при ошибочном бридже.
  • Маска шире, чем сеть — «лишние» узлы кажутся локальными: маска.

Возможные причины

  1. Статика 10.0.10.10 вручную + та же аренда DHCP другому MAC.
  2. Клон VM / шаблон с тем же IP и тем же или другим MAC.
  3. Два DHCP без согласования пулов.
  4. Второй шлюз с 10.0.10.1 (забытый роутер, ICS, телефон).
  5. Кластер/CARP/VRRP настроен неверно (два master).
  6. Порт в native VLAN + access VLAN схлопнулись.
  7. Резервная копия VM включена параллельно с продом.

Диагностика

1. Зафиксировать IP и оба MAC

На пострадавшем Windows:

Get-NetIPAddress -AddressFamily IPv4
Get-NetIPConfiguration
arp -a
Get-NetNeighbor -AddressFamily IPv4 | Where-Object IPAddress -like '10.0.10.*'
Get-WinEvent -FilterHashtable @{LogName='System'; Id=4199} -MaxEvents 10

Ubuntu:

ip -br addr
ip neigh
journalctl -k -b --grep='duplicate'
ip addr show

Запишите: IP, свой MAC, чужой MAC из предупреждения.

2. Опросить соседей и шлюз

С третьего узла в 10.0.10.0/24:

ping -n 2 10.0.10.10
arp -a 10.0.10.10
Get-NetNeighbor -IPAddress 10.0.10.10
ping -c 2 10.0.10.10
ip neigh show 10.0.10.10

Повторите 5 раз с паузой. Два MAC по очереди — живой конфликт. Один MAC — возможно, уже выиграли, но дубль ещё включается.

3. DHCP: кто выдавал

Get-DhcpServerv4Lease -ComputerName DC01 -ScopeId 10.0.10.0 | Where-Object IPAddress -eq '10.0.10.10'
Get-DhcpServerv4Reservation -ComputerName DC01 -ScopeId 10.0.10.0 | Where-Object IPAddress -eq '10.0.10.10'

Аренда на MAC-A, в ARP ещё MAC-B — статика на B или второй сервер. Ищите rogue через tcpdump UDP/67-68.

4. Коммутатор: на каком порту MAC

На Cisco-подобном:

show mac address-table address <MAC-B>
show ip arp 10.0.10.10

Два порта для одного MAC — петля (flapping). Разные порты, разные MAC, один IP — классический дубль.

5. Клон VM

Сверьте BIOS UUID, MachineGuid, MAC в гипервизоре. Две VM с одинаковым статическим IP из шаблона — частая причина после «просто скопировал диск».

Решение

Сценарий A. Статика пересеклась с DHCP

Оставьте серверу статику вне пула. На клиенте — ipconfig /release / dhclient, получит другой адрес. Обновите резервацию, если адрес должен быть фиксированным — один MAC.

Сценарий B. Два шлюза 10.0.10.1

Выключите лишний (ICS, домашний роутер). Проверьте, что VRRP: один master. Обновите ARP на клиентах:

Remove-NetNeighbor -IPAddress 10.0.10.1 -Confirm:$false
ping 10.0.10.1
sudo ip neigh flush dev eth0
ping -c 2 10.0.10.1

Сценарий C. Клон включили рядом

Выключите клон. Не меняйте IP прода, пока клон жив. Затем уникальные MAC/имя/IP на клоне.

Сценарий D. Два DHCP

Оставьте один сервер или split-scope без пересечения. Пока оба живы, новые клиенты будут ловить конфликты и APIPA.

6. Захват gratuitous ARP и сравнение с DHCP

Конфликт часто проявляется коротким всплеском: самозванец шлёт gratuitous ARP, затем молчит. На Ubuntu-шлюзе 10.0.10.1 снимите минуту:

sudo tcpdump -n -i eth0 'arp' -w /tmp/arp-conflict.pcap

Откройте pcap: кто отвечает на who-has 10.0.10.10. Два MAC — достаточно для тикета, не нужно «менять адрес сервера, чтобы пользователи отстали». На Windows-клиенте параллельно:

Get-NetNeighbor -IPAddress 10.0.10.10 | Format-List *
ping -n 30 10.0.10.10

Если ping чередует TTL или размер ответа, это разные стеки, не «магия коммутатора». Проверьте Hyper-V/KVM: клон с тем же IP часто поднимают «на тест» в том же VLAN. Сверьте MAC в гипервизоре с CAM. Для шлюза 10.0.10.1 эталонный MAC должен быть в документации; любое расхождение — инцидент, не «подождём, само рассосётся». После изоляции дубля пройдите соседей с Remove-NetNeighbor только для спорного IP. Не делайте массовый flush ARP на DC: кратковременно потеряете соседство со всеми, включая 10.0.10.2.

Запишите в заявку: IP, оба MAC, порты, hostname DHCP lease, действие (выключена VM / снят кабель / исправлена статика). Без этого конфликт вернётся после включения «забытой» копии.

Как проверить, что проблема устранена

С трёх узлов: Get-NetNeighbor / ip neigh на спорный IP даёт один MAC стабильно 2–3 минуты. Журнал без новых 4199. DHCP lease совпадает с этим MAC. Ping и Test-NetConnection до узла стабильны. На коммутаторе MAC-таблица: один порт.

Если не помогло

  • Конфликт только после фаиловера кластера — VIP/ARP gratuitous, не «лишний ПК».
  • Только Wi‑Fi: клиент isolation выключен, два STA с одинаковой статикой.
  • IPv6 dad failed параллельно — отдельный дубль SLAAC, не IPv4.
  • MAC меняется, но это VM live migration — норма, если гипервизор шлёт RARP; смотрите, нет ли второй копии.

Профилактика

  • Статика только вне scope; резервации — в DHCP, не «и статика, и lease».
  • Запрет клонов из работающей VM без sysprep/cloud-init.
  • DHCP snooping, мониторинг duplicate на SVI.
  • Алерт на два MAC в ARP шлюза за минуту.

FAQ

Кто «прав» при конфликте — кто первый получил адрес?

Стек ОС: оба считают себя правыми, связь рвётся. Права схема адресации, не «кто пинганулся».

Помогает ли ipconfig /renew?

Если ваш адрес из DHCP и сервер знает дубль — можете получить NAK и APIPA. Это симптом, не лечение второго владельца.

Конфликт на 10.0.10.1. Менять шлюз на 10.0.10.254?

Только если так решили в проекте. Обычно быстрее выключить самозванца. Смена шлюза потребует DHCP option 3 и всех статик.

arp -d * безопасен?

На рабочей станции — да. На сервере с кучей сессий снесёт соседние записи до следующего трафика. Лучше удалить одну запись 10.0.10.10.

Event 4199 нет, а MAC флапает. Это конфликт?

Да, если два MAC. 4199 может не писаться, если дубль не на этой Windows. Смотрите ARP на третьем узле.