Error some other host already uses address centos

Как обнаружить дублирующийся IP-адрес в сети в Linux

“Error, some other host already uses address” при выполнении команды «service network restart» или «ifup ethX» в системе CentOS / RHEL.

Как проверить наличие дублирующего IP-адреса в сети?

Использование команды arping

Запустите команду arping с ключом -D, чтобы включить обнаружение повторяющихся адресов.

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

Команда «echo $?» Проверяет возвращаемое значение команды.

Если это сообщает 0, то IP-адрес не дублируется.

Если это сообщает 1, то IP-адрес дублируется.

Приведенный ниже пример проверяет наличие дубликатов 192.168.5.2 в сети, подключенной к интерфейсу eth0.

В этом примере адрес обнаружен в другой системе:

Как перезапуск сети ifup или службы обнаруживает дублирующийся IP-адрес

При выполнении ‘service network restart‘ или ‘ifup ethX команда ifup-eth в /etc/sysconfig/network-scripts/ выполняет то же самое обнаружение дублирующихся адресов, что и при использовании arping:

Если обнаружен повторяющийся адрес, печатается сообщение ‘Error, some other host already uses address [IP.ADDRESS]’

Использование сервиса arpwatch

Служба arpwatch отслеживает таблицы ARP в локальной системе и может регистрировать сообщение при обнаружении адреса “flip flop”

Проверьте, есть ли сообщения о «flip flop» в файле /var/log/messages:

Затем демон arpwatch находит, что MAC-адрес, который связывается с 10.00.100.108, изменился на 01: 13: gh: ef: cd: ac.

Использование службы ipwatchd

Сторонний сервис ipwatchd использует libpcap для перехвата всего трафика ARP и обнаружения дублированных IP-адресов.

Дополнительную информацию об этом инструменте можно найти по адресу https://ipwatchd.sourceforge.io/.

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

Источник

ошибка, какой-то узел уже использует адрес

Ситуация следующая: есть компьютер на centos 5 с айпи 192.168.1.20. выключаем этот компьютер, ставим на его место другой тоже с айпишником 192.168.1.20 и сетевой интерфейс не поднимается, получаю ошибку «ошибка, какой-то узел уже использует адрес 192.168.1.20». Важно чтобы у нового компьютера айпи был именно такой. С другим айпи интерфейс поднимается. Роутер перезагружал, айпи не зарезервирован.

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

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

совершенно верно мак адрес разный, где то зарезервирован этот 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:

Стало быть, можно смело включать 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, вот цитата из документации:

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

Источник

“Error, some other host already uses address” при выполнении команды «service network restart» или «ifup ethX» в системе CentOS / RHEL.

Как проверить наличие дублирующего IP-адреса в сети?

Использование команды arping

Запустите команду arping с ключом -D, чтобы включить обнаружение повторяющихся адресов.

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

# arping -D -w 5 -I ethX IP.ADDRESS.TO.TEST
# echo $?

Команда «echo $?» Проверяет возвращаемое значение команды.

Если это сообщает 0, то IP-адрес не дублируется.

Если это сообщает 1, то IP-адрес дублируется.

Приведенный ниже пример проверяет наличие дубликатов 192.168.5.2 в сети, подключенной к интерфейсу eth0.

В этом примере адрес обнаружен в другой системе:

# arping -D -w 5 -I eth0 192.168.5.2
ARPING 192.168.5.2 from 0.0.0.0 eth0
Unicast reply from 192.168.5.2 [52:54:00:00:05:02] for 192.168.5.2 [52:54:00:00:05:02] 3.741ms
Sent 1 probes (1 broadcast(s))
Received 1 response(s)

Как перезапуск сети ifup или службы обнаруживает дублирующийся IP-адрес

При выполнении ‘service network restart‘ или ‘ifup ethX команда ifup-eth в /etc/sysconfig/network-scripts/ выполняет то же самое обнаружение дублирующихся адресов, что и при использовании arping:

# cat /etc/sysconfig/network-scripts/ifup-eth

if ! LC_ALL=C ip addr ls ${REALDEVICE} | LC_ALL=C grep -q "${ipaddr[$idx]}/${prefix[$idx]}" ; then
[ "${REALDEVICE}" != "lo" ]
   if ! /sbin/arping -q -c 2 -w 3 -D -I ${REALDEVICE} ${ipaddr[$idx]} ; then
     echo $"Error, some other host already uses address ${ipaddr[$idx]}."
     exit 1  
fi

Если обнаружен повторяющийся адрес, печатается сообщение ‘Error, some other host already uses address [IP.ADDRESS]’

Использование сервиса arpwatch

Служба arpwatch отслеживает таблицы ARP в локальной системе и может регистрировать сообщение при обнаружении адреса “flip flop”

# yum install arpwatch
# service arpwatch start
# chkconfig arpwatch on

Проверьте, есть ли сообщения о «flip flop» в файле /var/log/messages:

Nov  1 15:42:42 hostname arpwatch: new station 10.00.100.108 01:13:gh:ef:cd:ab   
Nov  1 15:43:32 hostname arpwatch: changed ethernet address 10.00.100.108 01:13:gh:ef:cd:ab (01:13:gh:ef:cd:ab)   
Nov  1 15:43:59 hostname arpwatch: flip flop 10.00.100.108 01:13:gh:ef:cd:ab (01:13:gh:ef:cd:ac)  
From the above messages, this machine first records the ARP mapping information: 10.00.100.108 to MAC 01:13:gh:ef:cd:ab

Затем демон arpwatch находит, что MAC-адрес, который связывается с 10.00.100.108, изменился на 01: 13: gh: ef: cd: ac.

Использование службы ipwatchd

Сторонний сервис ipwatchd использует libpcap для перехвата всего трафика ARP и обнаружения дублированных IP-адресов.

Дополнительную информацию об этом инструменте можно найти по адресу https://ipwatchd.sourceforge.io/.

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

Раз вы упоминаете широковещательную передачу в контексте преобразования сетевого адреса в канальный, то имеете ввиду 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 адресов.

ZANSWER ★

(03.11.17 06:51:13 MSK)

Последнее исправление: ZANSWER 03.11.17 06:53:53 MSK
(всего

исправлений: 2)

If you have an error that another web host is already using the centos vmware address on your system, then this user manual might help.

PC running slow?

Improve the speed of your computer today by downloading this software — it will fix your PC problems.

If you have always started VMWare ESXi and made some configuration changes that have nothing to do with changing the IP address, you may receive the following error message when running the method.

“Calling interface eth0: error, another host is already using 192.168.101.10 which you [failed]”

As you can imagine, this will not run from the network and you will not be able to connect to a host that is available on VMWare ESXi on the market.

Most of the time on ESXi this problem occurs on a host that may be running Linux distributions. In this picture, I had this specific issue on a CentOS 6 host.

This short article shows you how to fix this problem.

Change Any IP Address To Check The Problem

In my case, due to this particular VM host, I would often increase the RAM from 2GB to 4GB and restart the VM, which resulted in this problem message appearing.

Although nothing has changed in the cellular settings, including the IP address in this case, in order to get rid of the above error message, I changed the IP address devices to allow them to do other things. (i.e. from 192.168.101.10 to 192.168.101.20).

# Pussy / etc / sysconfig / network-scripts / ifcfg-eth0DEVICE = eth0BOOTPROTO = staticONBOOT = yesHWADDR = from: 60: 61: bc: cf: d5IPADDR = 192.168.101.20NETMASKE = 255.255.255.0

After changing the IP address, I get the error “Reasons for the RTNETLINK file: exists” when I restart execution:

RTNETLINK file responses: exists

Since changing the internet protocol address was causing this new error, I went back to the original IP (i.e. 192.168.101.10) with the IP of the remote VM to help, and when I restarted the VM, I again launched it. got the very first error message:

# anyone / etc / sysconfig / network-scripts / ifcfg-eth0..IPADDR = 192.168.101.10..

After returning to the IP address, the following error occurred again:

Bring the original eth0 cp: error, another host is already using the service address 192.168.101.10 [FAILED]

In your case, if you most likely allow yourself to change the IP address of the VMware host and do not always receive the message “RTNETLINK replies: file error present” on the newm IP address, maybe you can just change the IP address. address and leave it there. Or, you can go back to your old IP address and stay updated until the next step.

Check The Response To The Beep

At my stage, I realized that something like this has to do with ARP, talking about ARP caching or proxy, or something else with ARP on the VM host.

I sent an ARP echo request from another server to disable this IP to see what is going on.

# arping -c 2 3 -p -D -I eth0 192.168.101.10ARPING 192.168.101.10 of 0.0.0.0 eth04 probes sent (40 diffusions)Answers received

As you can see from the above output, unfortunately it did not receive an ARP response for the IP address.

Now I logged into the console associated with the host of the virtual machine that caused the error message, tried the arping instructions and got the following response.

ARPING 192.168.101.10 received from 0.0.0.0 eth0Unicast response 192.168.101.10 [50: 3D: E5: 1E: A9: 1B] 0.743 ms1 probe sent (1 broadcast (s))1 answer (s) received

Workaround For The Disappeared Problem

I’m looking for a script that displays “Error, hell It is already in use by another host.

In this example, the ifup-eth script installed in the / etc / sysconfig / network-scripts / directory gets the text that triggers network urinary incontinence when it starts up, our error message.

The following snippet is undoubtedly the snippet from the ifup-eth file that displays our error message:

# moggie / etc / sysconfig / network scripts / ifup-ethif ! arping -q -c 2 -n 3 -D -I $ REALDEVICE $ IPADDR – – then echo $ “Error, another host is immediately using $ IPADDR.” Exit 1Fi

In a great case, I know for sure that the real problem has nothing to do with an IP conflict, as I have never used 192.168.101.10 anywhere else on our network.

Therefore, using this host VM as a short term workaround, I ignored this marketing error and moved on.

To do this, I commented out the next block using the new Exit to 1 below.

# / etc. / sysconfig / network scripts / ifup-ethso cat! arping -x -c 2 -w 3 -D -I $ REALDEVICE $ IPADDR; So echo $ “Error, other hosts are already using $ IPADDR.” #output 1Fi

Into this In case, the system displayed this error message during startup and started the network without mutual errors.

After that, I was able to connect to the host IP without any problems.

If after a few days I notice that I don’t get this error message often on Xbox. So I went and uncommented this right away after about a week.

This should sometimes happen when you are on a clean VLAN. If you try to change your personal VLAN, this error may go away, but when you switch back to your VLAN, you will see this error message again.

Also explain that in your case this issue can naturally occur if you have any type of NIC binding, NIC aggregation, NIC association, etc. 0 HA management on your system.

But now you can at least try doing this as a temporary workaround and see if it helps again.

Improve the speed of your computer today by downloading this software — it will fix your PC problems.

Resolução De Problemas, No Entanto, Outro Host Já Usa O Endereço Vmware Centos Maneira Mais Fácil
Solucionar Problemas De Un Segundo Host Que Ya Usa La Dirección De Vmware Centos La Forma Más Fácil
Устранение неполадок другого хоста, уже покупающего адрес Vmware Centos Самый простой способ
Problemen Oplossen Met Een Andere Host Die Al Vmware Centos-adres Gebruikt Eenvoudigste Manier
Dépannage D’un Hôte Différent Utilisant Déjà L’adresse Vmware Centos Manière La Plus Simple
Fehlerbehebung Bei Einem Anderen Host, Der Bereits Eine Vmware Centos-Adresse Erstellt Der Einfachste Weg
Felsöka Ett Nytt Kast Som Redan Använder Vmware Centos-adress Enklaste Sättet
Vmware Centos Address를 사용하여 현재 다른 호스트 문제 해결 가장 쉬운 방법
Risoluzione Dei Problemi Di Un Host Aggiuntivo Che Già Utilizza L’indirizzo VMware CentOS Il Modo Più Semplice