Ошибка кода 4710 добавленный узел lan конфликтует с имеющимся узлом lan
Помогите друзя чайнику.
На прошлой работе была сеть на 25 компов, на верхнем этаже стоял D-link dir-620 с адресом 192.168.0.1 в который приходил инет от провайдера, от него шли свитчи по этажу к пк.
От свитча на первый этаж шел кабель к еще одному D-linkу у которого был адрес 192.168.0.2 дсхп отключен и шлюзом прописан первый длинк. Все работало прекрасно в одной подсети.
Сейчас пришел на другую работу, тут две подсети, половина компов друг друга не видят. Решил сделать по той же схеме, что и раньше.
Но когда на втором роутере пытаюсь указать Wan 192.168.0.1 и лан 192.168.0.хх то роутер Tenda W311R+ ругается и не дает мне прописать Lan и Wan в одной подсети, заставля делать две разные подсети.
В чем прикол, и что делать?
Первый роутер, допустим, имеет адрес 192.168.0.1 и dhcp на нем пусть раздает адреса допустим с адреса 192.168.0.100. Второму роутеру допустим прописываем адрес 192.168.0.2 (dhcp на нем выключен и wan Connection Type = Disabled или Assign WAN Port to Switch, т.е. он работает простым коммутатором).
Да второй роутер нужен чтобы, во второй половине здания вайфай ловил , так же к нему несколько ПК подключены, вместо коммутатора.
Я уже понял в чем затупил , втыкал в Ван порт сетку, а надо было в Лан. Просто не понимаю, зачем на 2 компов было делать две подсети, или просто тупо второй роутер воткнули и настроили отдельную подсесть для выхода в инет.а компы друг друга не видят, к принтерам не подключиться . Хочу одну сеть сделать, чтобы без маршрутов и всяких заморочек
192.168.0.1 - сомнительно, чтобы провайдер такие адреса раздавал, больше похоже на шлюз подсети 192.168.0.0/24 которую первый роутер создал.
Если в кратце, то второй роутер, который работает в качестве коммутатора настраивается следующим образом:
1. wan не используется
2. В LAN Settings (Настройки локальной сети) вписать адрес из подсети первого роутера (из свободных естественно, чтобы конфликтов не было), прописать маску, саррее всего 24-ю 255.255.255.0, отключить раздачу dhcp, dns
3. Настроить беспроводную сеть
192.168.0.1 - сомнительно, чтобы провайдер такие адреса раздавал, больше похоже на шлюз подсети 192.168.0.0/24 которую первый роутер создал.
Если в кратце, то второй роутер, который работает в качестве коммутатора настраивается следующим образом:
1. wan не используется
2. В LAN Settings (Настройки локальной сети) вписать адрес из подсети первого роутера (из свободных естественно, чтобы конфликтов не было), прописать маску, саррее всего 24-ю 255.255.255.0, отключить раздачу dhcp, dns
3. Настроить беспроводную сеть
Да так и делаю сейчас, вот только не могу пока с первым роутером разобраться, старый mikrotik, жесть там настройки, надо раздачу айпишников прописать что бы с сотки например начинались
Да так и делаю сейчас, вот только не могу пока с первым роутером разобраться, старый mikrotik, жесть там настройки, надо раздачу айпишников прописать что бы с сотки например начинались
Да так и делаю сейчас, вот только не могу пока с первым роутером разобраться, старый mikrotik, жесть там настройки, надо раздачу айпишников прописать что бы с сотки например начинались
Не пойму, чего так народ микротов пугается? Для обычных целей имеется прекрасная первая вкладка - Quck Set. Если не надо vpn, vlan, хитрые маршруты делать и трафик по портам распределять с ограничениями - Quck Set все что нужно.
Конкретно про айпишники, выставляются настройки в поле Local Network: IP Address: 192.168.0.1 (адрес шлюза), в поле Netmask 255.255.255.0 (/24) маска подсети, ставится крыжик DHCP Server, в DHCP Server Range указывается диапазон адресов, например 192.168.0.10-192.168.0.254, ставится крыжик NAT.
Вот и вся настройка сети.
Единственно, если провайдер выдает "белый" IP, то не помешает почитать хоть вот это Защита WAN-интерфейса в Mikrotik
Не пойму, чего так народ микротов пугается? Для обычных целей имеется прекрасная первая вкладка - Quck Set. Если не надо vpn, vlan, хитрые маршруты делать и трафик по портам распределять с ограничениями - Quck Set все что нужно.
Конкретно про айпишники, выставляются настройки в поле Local Network: IP Address: 192.168.0.1 (адрес шлюза), в поле Netmask 255.255.255.0 (/24) маска подсети, ставится крыжик DHCP Server, в DHCP Server Range указывается диапазон адресов, например 192.168.0.10-192.168.0.254, ставится крыжик NAT.
Вот и вся настройка сети.
Единственно, если провайдер выдает "белый" IP, то не помешает почитать хоть вот это Защита WAN-интерфейса в Mikrotik
Ситуация следующая: есть компьютер на 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 адреса назначаемого статически.
ZANSWER ★ ( 02.11.17 18:08:07 )
Последнее исправление: ZANSWER 02.11.17 18:10:03 (всего исправлений: 2)
Насколько я понял эту ошибку автор видит на клиентеНасколько я понял эту ошибку автор видит на клиенте
Ну да, она и должна быть на клиенте.
поэтому я и пытаюсь понять, как CentOS и с какого релиза выполняет проверку наличия конфликта для IPv4 адреса назначаемого статически.
Я не работал с CentOS, так что тут ничего сказать не могу. Но с такими ошибками (в сеть в качестве точки доступа воткнули несконфигурированный роутер с активным dhcp-сервером) сталкивался лет 7 назад, а то и раньше. В логах появляются ошибки о конфликте адресов. Видел такое на Gentoo, Debian. Уверен, что CentOS тут ничем не отличается.
И да, назначение обычно проходит нормально, конфликт выявляется несколько позже. Поэтому и предлагаю автору темы провести загрузку без сети, чтобы однозначно разделить сферы, где могут быть проблемы - сеть и конфигурацию самой машины.
Поскольку вы единственный, кто отвечает, буду пытать вас, как вы поняли, что у него DHCP сервер на CentOS? Я видимо сегодня совсем разучился читать вопрос, но мне показалось, что DHCP сервер у него на маршрутизаторе, а не на CentOS узле.
Для DHCP сервера это нормально, он обязан выполнять проверку занятости адреса, перед его выдачей клиенту, он делает это банальной отправкой ICMP запроса.
Но, клиенты делают такие проверки реже, вот Windows делает такую проверку, направляя специальным образом сформированный ARP запрос, в котором указывает, что желает получить информацию о IP адреса самого-себя. Но, в CentOS я не помню, чтобы выполнялась такая проверка, да и документация об этом нечего не говорит у Red Hat, может не там ищу?
ZANSWER ★ ( 02.11.17 18:44:07 )
Последнее исправление: ZANSWER 02.11.17 18:45:44 (всего исправлений: 2)
И так, 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
ZANSWER ★ ( 02.11.17 19:26:48 )
Последнее исправление: ZANSWER 02.11.17 19:27:27 (всего исправлений: 1)
Я могу ошибаться, но упоминание в документации о существование IPv4 DAD для не NM конфигурации, я не нашёл, но я сейчас проверю это, у меня есть CentOS в стенде.
Да и вообще, в FreeBSD или Solaris, такой проверки я не помню тоже, хотя конечно могло что-то уже поменяться.
ZANSWER ★ ( 02.11.17 19:29:55 )
Последнее исправление: ZANSWER 02.11.17 19:34:13 (всего исправлений: 2)
И так, я протестировал поведение CentOS 7:
- при использование Network Manager, IPv4 DAD выполняется
- при использовании ip/ifconfig, IPv4 DAD не выполняется
- при использовании network.service, IPv4 DAD выполняется
CentOS 5/6 у меня под рукой нет, чтобы проверить, что там было до перехода на systemctl. Готов представить, что возможно и раньше мог выполнятся скрипт, хотя я такого не припомню. Но только для случая старта службы сети и настройки интерфейсов через ifcfg-X.
ZANSWER ★ ( 02.11.17 20:17:01 )
Последнее исправление: ZANSWER 02.11.17 20:19:30 (всего исправлений: 1)
Странно, никогда не видел такой проверки.
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 адресов.
ZANSWER ★ ( 03.11.17 06:51:13 )
Последнее исправление: ZANSWER 03.11.17 06:53:53 (всего исправлений: 2)
Дополню немного случай получения 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 уже занят вышел из положения благодаря Вам
нашел следующее решение в сети, может кому пригодится. Проблема решена, спасибо за такую активность)
Что такое конфликт ip адресов?
И так представим у вас в организации, работают два человека с полностью идентичными ФИО. Вы задаете вопрос на собрании, кто тут Иванов Иван Иванович, и тут у вас поднимается два человека. Вот в локальной сети, так же появляются два компьютера с одинаковыми адресами, это и называется ситуация, при которой обнаружен конфликт ip адресов. Это хорошо будет, если это два клиентских компьютера, проблема будет минимальна, а что будет, если одним из участников будет сервер, который выполняет важную функцию в организации, например, сервер 1С, поверьте за это вас по головке не погладят.
Подключение к интернету по WAN-LAN
Наконец, последний случай, когда у вас нет никакой домашней или офисной локальной сети, компьютер напрямую подключен к интернету через порт WAN/LAN, а ошибка все равно есть и вы не можете к нему подключиться.
Если у вас выделенная линия со статическим IP, то решить проблему самостоятельно не удастся — дело в настройках провайдера, к которому придется обратиться за помощью. Если же динамический, что бывает в большинстве случаев, то есть 2 варианта, которые могут помочь.
- Переподключиться к интернету, например, отключив сетевое подключение и включив его заново.
Для этого заходим в «Пуск — Панель управления — Сеть и интернет — Центр управления сетями — Изменение параметров адаптера». Находим то соединение, которое связано с интернетом, кликаем по нему правой кнопкой мыши и выбираем отключить. После чего аналогично его активируем обратно.
И пишем в ней команду, которая обновит соединение: «ipconfig /renew»
Доброго дня!
Есть роутер Zyxel Keenetic Lite II (прошивка v2.05(AAKT.5)C2) и мгтс-овский GPON роутер Sercomm ONT RV6688BCM (версия ПО sc3.1.61).
Wi-Fi у Zyxel-я не режет скорость, поэтому хочу использовать его как точку доступа (все девасы в доме только по WiFi). А выход в интернет осуществлять по оптоволокну от мгтс. Но от своего провайдера я отказываться не хочу, поэтому задача - сделать так, чтобы я мог переключаться между провайдерами в пару кликов из админки Zyxel-я, а GPON пусть будет в роли slave. Я понимаю, что путано изъясняюсь - я сети не настраивал до этого)
Вобщем, что было сделано:
GPON роутер был подключен к Zyxel кабелем : из LAN1 в LAN1
роутеры увидели друг-друга в сети.
Вот сетевые настройки для GPON:
ip адрес: 192.168.1.254
маска подсети: 255.255.255.0
DHCP адреса: 192.168.1.1 - 192.168.1.30 (время аренды 7 часов)
DHCP шлюз: 192.168.1.254
Настройки Keenetic Lite 2:
ip: 192.168.1.1
маска подсети: 255.255.255.0
DHCP адреса: 192.168.1.31 - 192.168.1.60 (время аренды 7 часов)
DHCP шлюз 192.168.1.1
Далее, на Роутере GPON, я закрепил адрес 192.168.1.1 за роутером Zyxel, а соответственно на зукселе - закрепил 192.168.1.254 за GPON-ом.
Вобщем-то, все: оба роутера стали видны в сети по их адресам, и я снял галочку "включено" из подключения ISP на кинетике, т.о. отрубив провайдера (Онлайм).
В результате, я подключаюсь по вайфаю к Zyxel и спокойно выхожу в интернет через GPON. Включаю на нем подключение ISP - у меня Онлайм, выключаю - МГТС. То что я и хотел! НО:
По какой-то причине, все работает только на моем ноуте (acer), а при попытке подключить любые другие компьютеры и устройства - интернета они не видят. В сеть доступ есть, можно зайти в админку любого роутера, и они там видны (с одинаковыми ip на каждом роутере), но интернета нет.
Если подключить устройство через WiFi GPON - то интернет конечно же есть, как и доступ в локалку, но устройство регистрируется сразу с двумя разными ip:
Вот такая вот засада.. Как наладить?!
Что пробовал:
Пробовал отключать на Zyxel DHCP(для сегмента сети Home): Устройства получают доступ к интернет, но на вкладке "локальная сеть" Зукселя, все горит красным и написано "адреса из не существующей сети" - это непорядок!
Пробовал поставить для DHCP сервера шлюз и первичный DNS 192.168.1.254 - заработало, но ip по прежнему двоятся и интернет работает медленнее.
Еще есть такая штука: "DHCP ретранслятор" возможно она может помочь, но настроить не смог, ниче не менялось.
Также есть IGMP proxy (отключен), его включение\выключение тоже ниче не дало.
Самое идеальное было бы создать отдельное подключение через LAN1 - (такое же как ISP), т.к. Zyxel умеет превращать любой LAN в WAN.
Но увы не получилось настроить: Создаю новый интерфейс IPoE, ставлю галочки для LAN1: "включить" и "использовать для выхода в интернет".
В автоматическом режиме ip - ничего не работает: ни интернет, ни другой модем не определяется.
Пытался настроить ручной режим:
ip адрес 192.168.1.1
маска 255.255.255.0
шлюз 192.168.1.254
Пишет - "192.168.1.1 - адрес конфликтует с существующими подключениями" Какими??
меняю на 192.168.10.1 - "адрес из несуществующей сети"
Короче, помогите настроить все по нормальному. Если нужны скрины\настройки - все скину.
Причины конфликта IP адресов Windows, WAN и LAN подсетей
Чаще всего это происходит в следующих ситуациях:
- когда IP адреса назначаются вручную и системный администратор случайно задал одинаковые значения двум устройствам,
- когда в настройках ПК прописан IP адрес, но он не зарезервирован за ним в роутере. Но при этом на нем работает DHCP сервер, который автоматически назначил этот адрес какому-то еще устройству в сети,
- или для компьютера, на котором появляется ошибка «обнаружен конфликт IP адресов в сети», задан адрес из другой подсети (wan или lan).
Еще одна частая проблема, когда функция DHCP не активна на сетевом адаптере. О ней будет отдельный разговор.
Конфликт с другой системой
Еще одна менее распространенная, но встречающаяся ситуация, когда возникает конфликт IP адреса с другой системой Windows, когда на компьютере установлены 2 сетевые карты. Например, это бывает нужно на ПК в небольшом кафе или магазине, когда одна из которых работает с локальной сетью и интернетом (чем локальная сеть отличается от интернета?), а другая — с кассой. Случается, что либо компьютер не видит кассовый аппарат, либо не может выйти в глобальную сеть по WAN. Все это из-за того, что обе независимые локалки работают на одной подсети, то есть у обеих сетевых карт IP выглядят как 192.168.1.xxx. Для исправления этой проблемы оставьте одну сеть как есть, а для другой задайте иное значение, например 192.168.0.xxx. Проще всего это сделать в настройках роутера.
Для этого заходим в раздел с его IP, меняем его на 192.168.0.1 и сохраняем-перезапускаем.
Причины появления конфликта ip адресов Windows
Выше я вам показал, что из себя представляет ситуация, с одинаковыми ip адресами в операционной системе Windows. Давайте я вам расскажу, о причинах ее появления:
- Первая причина, это когда у вас в локальной сети, все сетевые адреса на компьютерах, назначаются в ручную (статические ip адреса). Обычно такие настройки делают для серверов, чтобы у них сохранялись всегда одни и те же параметры, но в данном методе есть уязвимое место, это необходимость вести реестр этих адресов, в разном виде и всегда его актуализировать. В противном случае вы можете получать проблемы с одинаковыми адресами. Я такое часто видел в маленьких офисах, где есть так называемый админчик, который так делает, и вот приходит новый компьютер или ноутбук, и для него так же вбивают ip, в итоге в локальной сети обнаружен конфликт ip адресов, как говориться за ошибки нужно платить.
- Второй вариант, это когда у вас есть проблемы с DHCP сервером, на котором у вас либо не настроена функция отслеживания дублирования адресов, либо у вас DHCP сервер кому-то назначил ip, а кто-то другой взял и настроил себе статический, вот и произошла ошибка конфликта ip адреса. Из своей практики я видел такое шапито, когда у одного админа был Kerio Control, на котором была функция DHCP сервера, там адреса назначались с большим резервированием и порой с привязкой. В один из прекрасных, московских дней, случилась ситуация, что у части людей перестал работать интернет. В настройках сети, светился APIPA адрес, этот админ вместо того, чтобы зайти в DHCP сервер и увидеть, что у него кончились адреса в пуле, стал массово перезагружать компьютеры и назначать на них статические айпишники, в итоге тем самым, он создал огромное количество ip конфликтов в сети, он просто не понимал принцип работы службы.
обнаружен конфликт ip адресов Windows. В этой сети уже есть компьютер с таким же IP-адресом. Обратитесь к системному администратору для решения проблемы
Если вы зайдете в настройки сетевого интерфейса, то обнаружите, что в данной ситуации у вас основным адресом, будет IP из APIPA диапазона (169.254.x.x). Это означает, что конфликтный адрес у вас будет не доступен, и вы в локальной сети не сможете общаться практически ни с кем.
Так же если посмотреть логи операционной системы Windows, то вы там обнаружите вот такое уведомление, код события 4199:
В системе обнаружен конфликт IP-адреса 192.168.31.1 с системой, имеющей адрес сетевого устройства 00-0C-29-19-92-76. В результате могут быть нарушены сетевые операции на этих системах.
Из-за чего у вас может быть обнаружен конфликт ip адресов Windows, я вам рассказал, переходим теперь к алгоритму решения данной ситуации.
Давайте с вами рассмотрим какие есть варианты того, чтобы избежать ситуации с пересечением или дублированием адресов на ваших компьютерах в локальной сети.
- Во первых если у вас обычный маленький офис и по каким-то причинам, все локальные адреса назначаются, исключительно в ручном режиме, то обязательно ведите реестр выданных адресов, и к этому вопросу вам необходимо подойти ответственно. В серверном сегменте статика приветствуется, еще как один из гандикапов проверки используйте DNS сервер, в зоне которого регистрируются ваши компьютеры и сервера. Для ведения таблиц, кстати есть удобный программный продукт racktables, он абсолютно бесплатный.
Чтобы в таком случае убрать конфликт ip адресов Windows, попробуйте выполнить:
- Если вы получаете ip-адрес, через какое либо устройство, будь то роутер или маршрутизатор, то попробуйте на него зайти и посмотреть в чем дело, в любом таком устройстве есть меню, где идет выдача адресов (Например, DHCP Clients List). Попробуйте увеличить диапазон раздаваемых адресов, в примере это от 100 до 199, поставьте от 20 до 250. В крайнем случае перезагрузите его.Во
- Если перезагрузка не помогла, то открываем окно выполнить (Сочетание клавиш Win и R) и вводим команду ncpa.cpl. У вас откроется "Панель управления\Все элементы панели управления\Центр управления сетями и общим доступом". Перейдите в левом, верхнем углу в пункт "Изменение параметров адаптера", щелкните правым кликом по вашему сетевому интерфейсу и попробуйте его выключить и включить.
- Если отключение интерфейса не помогло, то зайдите в свойства вашего сетевого адаптера, в интерфейс ipv4. И так, если у вас конфликт ip адреса в сети, происходит из-за того, что у вас на сбойном компьютере установлен не правильный ip адрес, то измените его на нужный, или поставьте получение IP-адреса автоматически. Если у вас уже стоит получение IP-адреса автоматически, то наоборот настройте статический адрес отличный от конфликтного. Все сетевые настройки, в лучшем случае нужно узнать у сетевого админа, но если их нет, то чаще всего в качестве DNS-серверов выступает ip-адрес основного шлюза, он же ваш роутер (коробочка, что дает интернет и WIFI), прописываем его, а вот, маска в 99% случаев 255.255.255.0, а вот основной адрес придется по подбирать, чтобы проверить не занят ли он кем то, без DHCP сервера, выполните до него команду Ping, она все вам ответит.
Еще можно сбросить текущий ip адрес, при условии его автоматического получения, через окно командной стройки, где нужно выполнить ipconfig /release и затем ipconfig /renew. У вас будет обнулен текущий адрес и запрошен новый.
- Если у вас нормальная организация и количество компьютеров исчисляется десятками или более, то вам просто необходим DHCP сервер, который автоматически будет раздавать ip адреса и следить за их использованием. Вы всегда сможете понять кому и какой адрес у вас назначен. Например, у Cisco оборудования, зашито поведение при конфликте ip адресов.
Если мы говорим, о Windows DHCP, то там есть функция защиты от конфликта IP адресов. Открываем оснастку DHCP и выделяем пул IPv4. Щелкаем по нему правым кликом мыши и выбираем из контекстного меню, пункт "Свойства".
Переходим на вкладку "Дополнительно" и находим пункт "Число попыток определения конфликтов (Conflict detection attempts)", по умолчанию там выставлено значение 0, означающее что служба не будет вначале проверять ip адрес на предмет доступности перед его выдачей. Выставляем значение от 1 до 5. Данная функция позволит исключить конфликт ip адреса с другой системой.
Те же настройки "Число попыток определения конфликтов" можно изменить и через powershell, открыв его от имени администратора и введя командлеты:
Как видите, у меня нужный параметр уже имеет значение 5, а не ноль.
Чтобы изменить значение "Число попыток определения конфликтов (Conflict detection attempts)", введите вот такую команду.
Как видите я задал новое значение 4, проверяем что все изменилось. Как видите PowerShell рулит.
Где искать ошибку?
Прежде всего, надо проверить, какой диапазон адресов выделен для использования при работе DHCP сервера в настройках роутера. Если при организации сети ничего не менялось в конфигурации роутера по умолчанию, то IP роутера можно прочитать на днище устройства
Если же его адрес, а также логин и пароль были изменены, то надо их узнать у сисадмина, войти в админку и найти раздел, отвечающий за адрес самого роутера.
В моем примере у роутера адрес 192.168.0.1, а диапазон имеет значения от 2 до 254 — это значит, что IP наших устройств должны быть от 192.168.0.2 до 192.168.0.254 — никак не 192.168.1.2 или 192.168.0.1, так как первый не из нашей подсети, а второй — уже задан для самого маршрутизатора.
Теперь, когда мы знаем наш диапазон, идем в настройки протокола TCP/IP v.4 на компьютере
И смотрим наш адрес. У меня как раз указан неправильный, не из того диапазона, поэтому я задам для него, допустим, 192.168.0.159. Если же у вас все верно, адрес в том же диапазоне и не идентичен роутеровскому, а конфликт IP адресов в сети остается, значит какому-то компьютеру уже задан ваш адрес. Нужно просто поменять цифры в последнем окошке. Также не забудьте в качестве шлюза и DNS-сервера IP адрес самого роутера, чего не сделано на вышепредставленном скриншоте.
Теперь возвращаемся в админку маршрутизатора в раздел, отвечающий за DHCP-сервер.
- Во-первых, активируем ручной режим.
- Во-вторых, выбираем из выпадающего списка нужный нам компьютер по его ID или MAC адресу, и прописываем его не меняющийся IP, который ранее был нами указан в настройках протокола Интернета TCP/IP, как было показано выше.
В том случае, если на вашем компьютере не требуется в обязательном порядке использование статического IP адреса, то проще всего поставить значения IP и DNS на «автомат»
Читайте также: