Попингуй. Или по ssh постучить, а то окажется что адрес действительно занят.

mac-адрес ?

Стучал, пинговал, не отзывается. Привязок к маку нет не на роутере, не в конфигах интерфесов

совершенно верно мак адрес разный, где то зарезервирован этот ip под определенный мак адрес, клонируй мак адрес от машины что работает...

В сети есть dhcp-сервер? Смотрите его настройки, наверняка там стоит привязка mac-IP.

проверил. нет привязки)

Что-то я видимо запамятовал, но, я не припомню, чтобы CentOS выполнял проверку доступности IPv4 адреса присваиваемого интерфейсу.

Или это какой-то Network Manager или что-то подобное такое делает? Если да, то, каким образом оно это делает?

проверил. нет привязки)

Чудес не бывает :). Хорошо, если Вы в момент загрузки и назначения адреса интерфейсу вообще отсоедините его от сети, все штатно пройдет, адрес присвоится? И что будет в логах после подключения к сети? Можно еще tcpdump запустить на этом интерфейсе, посмотреть, что происходит.

Я не понял, а при чём тут DHCP сервер с его привязкой? Если DHCP сервер выполняет проверку доступности адреса, только при его запросе клиентом.

Что именно вы проверяете с автором таким образом? Поясните, будьте так добры.

Я не понял, а при чём тут DHCP сервер с его привязкой?

Если данный IP не привязан к MAC-адресу и находится в dhcp-пуле, то вполне вероятно, что dhcp-сервер выдал его какому-либо другому устройству в сети. В этом случае в логах должны появиться ошибки вроде тех, о которых говорит автор.

В любом случае загрузка с отключенной сетью должна пройти штатно.

Если нет, то проблему надо искать не в сети, а в настройках конкретной машины.

Если же все нормально загрузилось, статический адрес назначился, то воткнув такую машину в сеть и запустив там tcpdump, можно, как минимум, увидеть mac-адрес конфликтного устройства с таким же IP-адресом.

Насколько я понял эту ошибку автор видит на клиенте, а не на DHCP сервере, может быть я не правильно его понял.

Относительно назначения статического адреса на интерфейсе, кто выполняет такую проверку? Я возможно уже забыл, но я не припомню, чтобы CentOS выполнял проверку занятости адреса. К тому же, в отличие от IPv6, где при назначение адреса рекомендуется выполнять Duplicate Address Detection (DAD), через отправку специально сформированного Neighbor Solicitation (NS) пакета.

RFC 5257: IPv4 Address Conflict Detection только в 2008 году утвердили, поэтому я и пытаюсь понять, как CentOS и с какого релиза выполняет проверку наличия конфликта для IPv4 адреса назначаемого статически.

Насколько я понял эту ошибку автор видит на клиентеНасколько я понял эту ошибку автор видит на клиенте

Ну да, она и должна быть на клиенте.

поэтому я и пытаюсь понять, как CentOS и с какого релиза выполняет проверку наличия конфликта для IPv4 адреса назначаемого статически.

Я не работал с CentOS, так что тут ничего сказать не могу. Но с такими ошибками (в сеть в качестве точки доступа воткнули несконфигурированный роутер с активным dhcp-сервером) сталкивался лет 7 назад, а то и раньше. В логах появляются ошибки о конфликте адресов. Видел такое на Gentoo, Debian. Уверен, что CentOS тут ничем не отличается.

И да, назначение обычно проходит нормально, конфликт выявляется несколько позже. Поэтому и предлагаю автору темы провести загрузку без сети, чтобы однозначно разделить сферы, где могут быть проблемы - сеть и конфигурацию самой машины.

Поскольку вы единственный, кто отвечает, буду пытать вас, как вы поняли, что у него DHCP сервер на CentOS? Я видимо сегодня совсем разучился читать вопрос, но мне показалось, что DHCP сервер у него на маршрутизаторе, а не на CentOS узле.

Для DHCP сервера это нормально, он обязан выполнять проверку занятости адреса, перед его выдачей клиенту, он делает это банальной отправкой ICMP запроса.

Но, клиенты делают такие проверки реже, вот Windows делает такую проверку, направляя специальным образом сформированный ARP запрос, в котором указывает, что желает получить информацию о IP адреса самого-себя. Но, в CentOS я не помню, чтобы выполнялась такая проверка, да и документация об этом нечего не говорит у Red Hat, может не там ищу?

P/S/ С радостью бы тоже посмотрел бы на tcpdump/tshark дамп с интерфейса, где он получает такое сообщение.

И так, CentOS по умолчанию не выполняет не каких проверок IPv4/IPv6 DAD, но это делает Network Manager:

dad-timeout int32 -1

Timeout in milliseconds used to check for the presence of duplicate IP addresses on the network. If an address conflict is detected, the activation will fail. A zero value means that no duplicate address detection is performed, -1 means the default value (either configuration ipvx.dad-timeout override or 3 seconds). A value greater than zero is a timeout in milliseconds.

Стало быть, можно смело включать tcpdump/tshark и смотреть ARP пакеты, на предмет ARP response с IP адресом который назначается нашему интерфейсу, а далее ищем узел, который ответил на наш ARP запрос.

как вы поняли, что у него DHCP сервер на CentOS?

Я это и не понимал :). Видимо, неудачно формулирую свои мысли, раз Вы так меня понимаете.

но мне показалось, что DHCP сервер у него на маршрутизаторе, а не на CentOS узле.

Да, у меня тоже сложилось такое мнение.

Для DHCP сервера это нормально, он обязан выполнять проверку занятости адреса, перед его выдачей клиенту, он делает это банальной отправкой ICMP запроса.

Только в том случае, если он сам выдал адрес. По поводу ICMP-запроса - по-моему, Вы ошибаетесь. По крайней мере, ISC dhcpd никаких запросов не шлет.

Вот выдержка из документации:

When a client requests an address using the DHCP protocol, dhcpd allocates an address for it. Each client is assigned a lease, which expires after an amount of time chosen by the administrator (by default, one day). Before leases expire, the clients to which leases are assigned are expected to renew them in order to continue to use the addresses. Once a lease has expired, the client to which that lease was assigned is no longer permitted to use the leased IP address.

Именно поэтому появление в сети нелегального dhcp-сервера чревато такими серьезными последствиями.

Но, клиенты делают такие проверки реже

Угу, поэтому ошибка обычно не сразу всплывает. Но довольно быстро (минуты).

Но, в CentOS я не помню, чтобы выполнялась такая проверка, да и документация об этом нечего не говорит у Red Hat, может не там ищу?

Все системы, с которыми я работал, так или иначе, подобную проверку делали.

И так, CentOS по умолчанию не выполняет не каких проверок IPv4/IPv6 DAD, но это делает Network Manager

Мне кажется, Вы ошибаетесь - я ловил эти ошибки, когда никаких Network Manager'ов еще не было, а сеть конфигурировалась командами ifconfig и route ;).

Стало быть, можно смело включать tcpdump/tshark и смотреть ARP пакеты, на предмет ARP response с IP адресом который назначается нашему интерфейсу, а далее ищем узел, который ответил на наш ARP запрос.

Угу, именно это я автору темы и посоветовал.

Относительно ISC DHCPD, вот цитата из документации:

https://www.isc.org/wp-content/uploads/2017/08/dhcp41conf.html

IP ADDRESS CONFLICT PREVENTION

The DHCP server checks IP addresses to see if they are in use before allocating them to clients. It does this by sending an ICMP Echo request message to the IP address being allocated. If no ICMP Echo reply is received within a second, the address is assumed to be free. This is only done for leases that have been specified in range statements, and only when the lease is thought by the DHCP server to be free - i.e., the DHCP server or its failover peer has not listed the lease as in use.

If a response is received to an ICMP Echo request, the DHCP server assumes that there is a configuration error - the IP address is in use by some host on the network that is not a DHCP client. It marks the address as abandoned, and will not assign it to clients. The lease will +remain abandoned for a minimum of abandon-lease-time seconds.

If a DHCP client tries to get an IP address, but none are available, but there are abandoned IP addresses, then the DHCP server will attempt to reclaim an abandoned IP address. It marks one IP address as free, and then does the same ICMP Echo request check described previously. If there is no answer to the ICMP Echo request, the address is assigned to the client.

The DHCP server does not cycle through abandoned IP addresses if the first IP address it tries to reclaim is free. Rather, when the next DHCPDISCOVER comes in from the client, it will attempt a new allocation using the same method described here, and will typically try a new IP address

Я могу ошибаться, но упоминание в документации о существование IPv4 DAD для не NM конфигурации, я не нашёл, но я сейчас проверю это, у меня есть CentOS в стенде.

Да и вообще, в FreeBSD или Solaris, такой проверки я не помню тоже, хотя конечно могло что-то уже поменяться.

И так, я протестировал поведение CentOS 7:

- при использование Network Manager, IPv4 DAD выполняется

- при использовании ip/ifconfig, IPv4 DAD не выполняется

- при использовании network.service, IPv4 DAD выполняется

CentOS 5/6 у меня под рукой нет, чтобы проверить, что там было до перехода на systemctl. Готов представить, что возможно и раньше мог выполнятся скрипт, хотя я такого не припомню. Но только для случая старта службы сети и настройки интерфейсов через ifcfg-X.

Странно, никогда не видел такой проверки.

IMHO, IPv4 тут вообще не причем. Это особенность функционирования ethernet-сетей. Каждая сетевая карта периодически шлет широковещательные запросы - какой mac-адрес у такого-то IP? И если приходят два ответа, регистрируется ошибка. Просто послушайте свою сеть tcpdump'ом, сами все увидите.

На обоих статика настроена? И может есть третий, просто centos 5 его не видит, а «другой» видит?

Такую проверку выполняет Cisco DHCPD, Microsoft DHCPD и ISC DHCPD, как мы уже с вами выяснили, возможно и другие, не смотрел.

Раз вы упоминаете широковещательную передачу в контексте преобразования сетевого адреса в канальный, то имеете ввиду ARP протокол, поскольку Neighbour Discovery протокол использует многоадресную передачу.

О том, что это особенность Ethernet протокола, который обладает поддержкой широковещательной передачи, на канальном уровне, я должен с вами не согласиться. Возьмём для примера ATM или Frame Relay, они оба являются Non-Broadcast Multi-Access протоколами и могут использовать inverse ARP, что в ряде случаев приводит к тому, что они направляют inARP request через каждый PVC. При этом они не являются протоколами реализующими поддержку широковещательной передачи на канальном уровне, как Ethernet. Но, каждый узел получит ровно такой же ARP запрос, как и в случае Ethernet.

Более того, в стандарте IEEE 802.1/2/3 нет не слова о регистрации конфликтов IP адресов, этот уровень лежит вне поля компетенции Ethernet протокола. Поэтому IETF утвердила стандарты под номерами RFC 5257: IPv4 Address Conflict Detection, а так же RFC 4429: Optimistic Duplicate Address Detection (DAD) for IPv6, регламентирующие поведение узлов реализующих IP протокол в отношение проверки конфликтов сетевого уровня и их устранения.

Я не очень понял, что вы имели ввиду, когда говорили об ошибке, в том случае, если узел получает два ответа на ARP request. Где вы наблюдаете такое поведение? И самое главное, к чему ведёт такая ситуация на узле получателе?

- с точки зрения узла, получившего два ответа, нет не какой проблемы, он заменит первый пришедший ответ, вторым.

- с точки зрения узлов, которые дали такой ответ, проблемы тоже нет, поскольку они используют одноадресный ARP reply, иными словами оба узла буду считать, что второго узла не существует в сети с таким же адресом.

Если мы заглянем в ARP пакет, направляемый при выполнение процедуры IP DAD, воспользовавшись tcpdump, то увидим, что ARP request выглядит следующим образом:

nbytes: (ar$sha) Source MAC нашего узла mbytes: (ar$spa) 0.0.0.0 nbytes: (ar$tha) FF:FF:FF:FF:FF:FF (00:00:00:00:00:00) mbytes: (ar$tpa) IP адрес нашего узла

ar$tpa содержит наш собственный адрес, а ar$spa заполнен 0.0.0.0, что совершенно не характерно для классического ARP request, поэтому такой пакет называется ARP Probe.

Ответом на такой ARP Probe, будет ARP reply, на наш MAC адрес, указанный в поле ar$sha, что автоматически позволит нашему узлу узнать, что такой адрес уже занят.

Стандарт так же предписывает, выполнять следующую проверку, когда наш узел получает ARP request/reply, если ar$sha != MAC любого из наших интерфейсов, а ar$spa = IP любого из наших интерфейсов, то в сети существует конфликт IP адресов.

Но, получить ARP reply мы можем только в одном случае, если он был направлен не одноадресным кадром, а широковещательным. Лично я не встречал таких реализаций, а значит проверка сужается только до ARP request пакетов.

Исходя из выше изложенного я считаю, что ваше утверждение о том, что это особенность функционирования Ethernet сетей, ошибочна. Хотя в случае inverse ARP, ar$sha содержит Frame Relay DLCI или ATM VCI/VPI, который к тому же, ещё и меняется на каждом коммутаторе, тем не менее, это не ломает логику проверки, а только слегка меняет её.

Если мы получили кадр который содержит ar$sha = DLCI/VCI/VPI нашего PVC, а это всегда будет правдой, наш интерфейс заменяет ar$sha кадра при получение на собственный и ar$spa = IP нашего любого интерфейса, то в сети существует конфликт IP адресов.

Дополню немного случай получения ARP reply, наш узел, согласно стандарту обязан ещё послать ARP Announcement, а так же Gratuitous ARP, после назначения IP адреса на интерфейс.

С точки зрения формата пакета, они равнозначны, разница лишь в opcode поле, которое для первого установлено в значение Request, а для второго в Reply.

При получение такого пакета, у нашего узла тоже есть шанс зарегистрировать конфликт IP адресов, поскольку оба пакета будут широковещательными в случае Ethernet.

P/S/ Но, как я уже ранее писал, не ip из iproute2, не ifconfig из net-tools, таких проверок при назначение адреса, не выполняют, только демоны Network Manager и SystemD Network.Service.

выясни mac компьютера который использует нужный адрес. Возможно это прольет свет на то какой именно это компьютер.

Роутер перезагружать бесполезно.

При получение такого пакета, у нашего узла тоже есть шанс зарегистрировать конфликт IP адресов, поскольку оба пакета будут широковещательными в случае Ethernet.

Именно про этот случай я и говорю.

P/S/ Но, как я уже ранее писал, не ip из iproute2, не ifconfig из net-tools, таких проверок при назначение адреса, не выполняют, только демоны Network Manager и SystemD Network.Service.

Я, к сожалению, не имею сейчас возможности углубляться в документацию, но ошибки в логах при конфликте IP-адресов получал задолго до появления таких сервисов как Network Manager и SystemD Network.Service. Собственно говоря, у меня и сейчас на сервере нет ни одной из этих служб, что не мешает ему отлавливать конфликты.

В общем интерфейс поднялся с отключенным ланом. Сунул лан - все работает. service network restart - айпи адрес используется другим узлом. магия какая-то)

Добый день и спасибо

У меня такая же проблема Началась с обновления ПО роутера Потом IP уже занят вышел из положения благодаря Вам

нашел следующее решение в сети, может кому пригодится. Проблема решена, спасибо за такую активность)

1. Открываем файл /etc/sysconfig/network-scripts/ifup-eth

2. Ищем и комментируем строчки

# if ! /sbin/arping -q -c 2 -w 3 -D -I ${REALDEVICE} ${ipaddr[$idx]} ; then
#net_log $"Error, some other host already uses address ${ipaddr[$idx]}."
#exit 1
#fi

Супер! У вас в роду страусов не было?