Сетевой специалист проверяет правильно ли работает dhcp клиент на компьютере он вводит команду
Средство восстановления
Внимание!
Диагностика на стороне сервера
Итак, диагностика на стороне клиента показала, что проблем не обнаружено. Независимо от реализации DHCP-сервера, теперь необходимо пошагово проверить ряд предположений, начиная с самых простых и очевидных.
Сетевая получает неправильный IP 169.254.X.X
Параметры командной строки программы Tracert
Программа tracert поддерживает несколько параметров, которые описаны в следующей таблице.
tracert [-d] [-h максЧисло] [-j списокУзлов] [-w интервал] имя
Запущен ли DHCP как сервис?
В зависимости от ОС, дистрибутива и реализации DHCP-сервера, проверить это можно по-разному. Если сервис остановлен и есть ошибки в конфигурационных файлах, то запустить его не удастся. Это первая отправная точка. Если сервис запущен, можно переходить к следующему шагу.
9.2.1 Введение
Просмотр конфигурации с помощью команды ipconfig /all
Устраняя неполадки сетевых соединений TCP/IP, начинайте с проверки конфигурации TCP/IP на компьютере, на котором возникают эти неполадки. Для получения сведений о конфигурации компьютера, включая его IP-адрес, маску подсети и основной шлюз, можно использовать программу ipconfig.
Для клиентов Windows 95 и Windows 98, а также Windows Millennium Edition используйте вместо ipconfig программу winipcfg
Например, если компьютер имеет IP-адрес, который уже присвоен другому компьютеру, то маска подсети будет иметь значение 0.0.0.0.
В следующем примере показаны результаты команды ipconfig /all на компьютере с Windows XP Professional;, который настроен на использование DHCP-сервера для автоматического конфигурирования TCP/IP, а WINS- и DNS-серверов — для разрешения имен.
Если с конфигурацией TCP/IP все в порядке, следующим шагом должна быть проверка возможности соединения с другими узлами TCP/IP-сети.
Вариант 1. Текущий IP-адрес имеет вид 169.254.Х.Х
Скорее всего, на клиентской машине при этом установлена ОС Windows. Это значит, что клиенту действительно не удалось получить сетевые настройки, потому что DHCP-сервер не отвечал, и адрес был сгенерирован службой APIPA (Automatic Private IP Addressing) из диапазона 169.254.0.0 – 169.254.255.255. Если клиент — Linux-машина, адрес может принимать вид 0.0.0.0, либо отсутствовать в принципе.
Пожалуй, самое очевидное действие в такой ситуации — попытаться снова получить IP-адрес, отправив повторно DHCP-запрос, а заодно убедиться, что на устройстве запущен DHCP-клиент. Это можно сделать несколькими способами:
- отключиться от сети на 10–30 секунд и подключиться снова;
- перезагрузить устройство;
- выполнить последовательно команды. В командной строке Windows: ipconfig /release, затем ipconfig /renew. В терминале Linux: dhclient -v -r, потом dhclient или dhcpcd -k, затем dhcpcd ().
При выводе каких-либо ошибок и/или предупреждений нужно в первую очередь их устранить — например если DHCP-клиент не запущен, сперва его необходимо включить. После этого нужно снова проверить настройки. Если результат остался прежним, проверьте работоспособность сетевого драйвера и стека протоколов TCP/IP в целом. Проще всего это сделать с помощью команды ping 127.0.0.1 (так называемая проверка внутренней обратной петли). Если в результате выполнения команды ответ от собственного сетевого адаптера получен, можно считать диагностику на стороне клиента завершённой и переходить к диагностике со стороны DHCP-сервера.
Приходят ли запросы от клиентов на DHCP-сервер?
Чтобы определить это, нужно снова запустить анализатор сетевого трафика. На этот раз на сервере. После запуска на сервере tcpdump, dhcpdump или Wireshark клиенту, у которого проблемы с получением адреса, необходимо попытаться получить его снова любым способом, описанным в начале статьи. Если DHCP-сервер работает в штатном режиме, то должны быть и запросы, и ответы. Но всё может быть иначе.
Предположим, что у нас есть по крайней мере один клиент, которому не удаётся получить настройки, и запрос от него точно должен был прийти на сервер. Если этого не произошло, очевидно, что клиент либо сам не отправляет запрос, либо запрос не доходит до сервера по разным причинам. Может, он блокируется на промежуточном сетевом оборудовании или в сети некорректно работает ретрансляция DHCP-запросов dhcp_relay.
Чтобы это проверить, можно в первом случае вернуться к диагностике на стороне клиента и проследить с помощью анализатора сетевого трафика, что клиент отправляет DHCP-запрос. Во втором — проверить настройки на промежуточном сетевом оборудовании.
Диагностика на стороне клиента
Чтобы понять, что происходит, первым делом, конечно, следует проверить, подключён ли клиент физически к проводной или беспроводной сети. Если да, то самое время приступать к проверке сетевых настроек на устройстве клиента с помощью утилит ipconfig /all (в командной строке Windows), ifconfig или ip addr (в терминале Linux).
Вывод команд покажет текущий IP-адрес и другие настройки на сетевом адаптере (или всех адаптерах, если их несколько). При этом, если на сетевом адаптере нет корректного IP-адреса, возможных вариантов его настроек может быть немного.
Вариант 3. Текущий IP-адрес корректный, но доступа к интернету и другим сетевым ресурсам по-прежнему нет
Если это так, то стоит вернуться к проверке не только самого IP-адреса, но и всех остальных настроек. И особенно к проверке маски, адреса шлюза по умолчанию и адресов DNS-серверов, так как именно через шлюз устройству предстоит связываться с другими сетями, а с помощью DNS-серверов — преобразовывать доменные имена в IP-адреса.
Следует помнить, что DHCP-сервер может раздавать настройки выборочно, а сам клиент может выборочно их применять. Например, только IP-адрес, маску и шлюз. Это скорее исключение, но в таком случае адреса DNS придётся прописать руками. Гораздо хуже, если настройки адресов DNS-серверов от DHCP-сервера игнорируются просто потому, что их переопределяет стороннее ПО или неверные статические настройки. Такое тоже бывает.
Устранение неполадок с помощью tracert
Команду tracert можно использовать для определения места в сети, в котором нарушается нормальная передача пакетов. В следующем примере основной шлюз определил, что не существует подходящего пути к узлу 192.168.10.99. Причиной может быть неправильная конфигурация маршрутизатора или отсутствие сети с адресом 192.168.10.0 (неправильный IP-адрес).
Программа Tracert полезна при устранении неполадок в больших сетях, в которых к одному и тому же узлу могут вести несколько путей.
Проверка маршрутизаторов с помощью программы pathping
Программа pathping — это средство трассировки маршрута, сочетающее функции программ ping и tracert и обладающее дополнительными возможностями, которых не имеют две эти программы. Команда pathping отправляет пакеты каждому маршрутизатору на пути к месту назначения на протяжении некоторого времени, а затем вычисляет результат на основании пакетов, возвращенных каждым маршрутизатором. Так как эта команда показывает степень потери пакетов на любом маршрутизаторе или канале, с ее помощью легко определить, какие маршрутизаторы или каналы вызывают неполадки в работе сети. Она поддерживает набор параметров, которые описаны в следующей таблице.
По умолчанию разрешается выполнять не более 30 прыжков, а стандартное время ожидания равно 3 секундам. Период по умолчанию равен 250 миллисекундам, а число запросов каждого маршрутизатора — 100.
Ниже приводится пример отчета команды pathping. Вычисленная статистика, выведенная после списка узлов, показывает потерю пакетов на каждом из маршрутизаторов.
9.2.2 Упрощенный алгоритм взаимодействия DHCP-сервера и DHCP-клиента.
Сразу скажу, что сейчас мы разберем упрощенный алгоритм взаимодействия между DHCP-сервером и клиентом, мы не будем рассматривать специфичные случаи, а прикинемся, что работаем в идеальной сети, где нет никаких конфликтов, дублирований и проблем. В дальнейшем этот алгоритм мы будем расширять.
Первое и важное условие нормальной работы DHCP-сервера заключается в том, что он должен находиться в одной подсети/канальной среде с клиентом, иначе ничего работать не будет. В дальнейшем мы убедимся, что это не всегда так и если сервер и клиент находятся в разных подсетях, то им необходим посредник, который называется DHCP Relay Agent. Ну а теперь перейдем к алгоритму взаимодействия между клиентом и сервером по DHCP.
Запрос(ы) есть, ответа(ов) нет?
Самая простая и очевидная причина в этом случае — закончился пул свободных адресов. Это легко проверить на самом DHCP-сервере по списку выделенных IP-адресов (leases). Если причина действительно в этом — задумайтесь: возможно, пришло время для увеличения пула пригодных для использования IP-адресов на сервере. Чтобы решить проблему прямо сейчас, можно почистить список существующих адресов, выданных в аренду клиентам, уменьшить время аренды и перезапустить сервис DHCP. Но быстрые решения помогают не всегда, а причин может быть гораздо больше. В таком случае придётся детально просматривать логи, а также последние изменения в конфигурации на сервере.
В этой статье описывается, как устранять неполадки, возникающие на DHCP-сервере.
9.2.3 DHCP-клиент и DHCP-сервер, базовая настройка.
Теперь нам нужно закрепить полученные знания о взаимодействие между DHCP-сервером и DHCP-клиентом на практике, для этого мы расчехлим Cisco Packet Tracer и соберем простую схему, которая показана ниже.
9.2.2 Схема сети для демонстрации взаимодействия между DHCP-клиентом и сервером
Вокруг этой схемы мы и будем плясать, в центре схемы находится обычный L2 коммутатор, в его настройки мы не лезем, поэтому можно смело утверждать, что все устройства в нашей сети находятся в одной канальной среде. К коммутатору подключен роутер, который будет выпускать наших клиентов в Интернет, его мы безбожно обозвали основной шлюз (про разницу между хабами, коммутаторами и роутерами можно почитать здесь). Также на схеме есть два DHCP-сервера, которые уже подключены к коммутатору и три клиента, из которых пока подключен только один.
Перед началом настройки схемы не забудьте переключить Cisco Packet Tracer в режим симуляции. Роутеру и двум серверам нужно будет назначить статический IP-адрес, так как здесь адреса ни при каких сбоях не должны измениться, роутер для клиентов является основным шлюзом, а DHCP-сервера источником настроек. Клиент должен получать настройки динамически.
9.2.3.1 Настройка протокола DHCP на сервере и клиенте в Cisco Packet Tracer
Покажу настройку только одного DHCP-сервера, на втором настройки должны быть идентичны, за исключением IP-адреса. Для начала назначим серверу IP-адрес вручную, сам себе сервер выдавать IP-адреса не умеет.
9.2.3 Настройки протокола IP на DHCP сервере
Серверу я не стал давать адрес шлюза по умолчанию, так как серверу не нужен доступ в Интернет, где найти IP настройки для устройств в Cisco Packet Tracer, вы уже должны знать, показывал и не один раз. Следующим пунктом нашей программы будет настройка DHCP на сервере. Для этого перейдите на вкладку Services и в левом меню выберете DHCP.
9.2.4 Настройки DHCP на сервере
Обратите внимание, здесь уже заполнены поля Start IP Address и Subnet Mask, мы же еще помним, что и клиент, и сервер должны находиться в одной канальной среде, чтобы было всё гуд. Когда мы назначили IP-адрес на интерфейс сервера, Cisco Packet Tracer сам назначил значения в эти поля за нас, если IP-адрес не назначать, то в этих полях будут унылые нули.
Предлагаю пока не трогать эти поля, а изменить значения у полей Pool Name и Default Gateway. Мои настройки показаны ниже.
9.2.5 Продолжаем настраивать DHCP сервер
Все изменения я выделил, для начала был включен DHCP при помощи чекбокса, затем я дал имя новому пулу IP-адресов, который сервер будет использовать для выдачи клиентам, а также была указана дополнительная опция в виде адреса шлюза по умолчанию. Чтобы пул был добавлен, следует нажать кнопку Add, после чего внизу у нас появится два пула IP-адресов: один – этот тот, что создали мы, второй – это тот, что был создан Cisco Packet Tracer автоматически. Чтобы не было проблем, удалите второй, для этого его нужно выделить и нажать на кнопку Remove, если не получится удалить автоматический пул, настройте его так, как я показал и удалите свой собственный. На втором сервере настройки нужно сделать аналогичными, разница будет только в IP-адресе, который вы назначите серверу.
Итак, что мы сделали, чтобы настроить DHCP-сервер, а сделали мы следующее:
- Настроили IP-адрес на интерфейсе сервера.
- Создали пул IP-адресов, из которого сервер будет выдавать настройки клиенту.
- Дали этому пулу имя, так как пулов у DHCP-сервера может быть несколько.
- Указали начальный IP-адрес пула (поле Start IP Address), это означает, что сервер будет пытаться выдавать IP-адреса, начиная с 192.168.0.1 (а не с 192.168.0.0, ведь сервер понимает, что это номер сети, а также он немного в курсе о том, что в 21 веке мы все используем маску подсети переменной длины, а про классовые сети мы все уже забыли).
- Также мы дали указание серверу выдавать две опции: маску подсети и IP-адрес шлюза по умолчанию.
Собственно, это всё, что нам сейчас необходимо. Сейчас мы сконфигурировали DHCP-сервер в режиме автоматической выдачи динамических IP-адресов, для нас этот режим самый интересный.
9.2.3.2 Настройки DHCP на клиенте
Настройка DHCP на клиенте гораздо проще, нужно только поставить галочку напротив «Получать IP-адрес по DHCP» и забыть про утомительный ручной труд.
9.2.6 Настройка протокола DHCP на клиенте
Фразы «Гибкая настройка» и Cisco Packet Tracer плохо совместимы, в реальных операционных системах вы сможете задать: какие параметры рабочая станция должна получить по DHCP, а какие параметры вы можете ввести своими руками. Но это нам сейчас не интересно, нам важно разобраться с тем, как клиент получает IP-адрес от DHCP сервера и это мы сделаем. Настройка протокола DHCP на клиенте на этом закончена.
Отображение статистики соединений с помощью программы netstat
Командой netstat можно пользоваться для отображения статистики протокола и текущих TCP/IP-соединений. Команда netstat –a выводит сведения обо всех подключениях, а команда netstat –r отображает таблицу маршрутизации и сведения об активных подключениях. Команда netstat –o отображает коды процессов, что позволяет просмотреть владельца порта для каждого подключения. Команда netstat –e выводит статистику интерфейса Ethernet, а команда netstat –s отображает статистику протоколов. При использовании команды netstat –n адреса и номера портов не преобразуются в имена. Ниже показаны примеры отчетов, получаемых с помощью программы netstat:
9.2 Процесс получения IP-адреса по DHCP. DHCP-клиент и DHCP-сервер
Вариант 2. Текущий IP-адрес не из диапазона 169.254.0.0 – 169.254.255.255, но и не из того диапазона адресов, которые должен выдавать DHCP-сервер
Как известно, чудес не бывает. Если настройки, которые получает клиент, не от доверенного DHCP-сервера в сети, значит, их раздаёт кто-то другой. Тот, кто случайно или специально подключил к сети DHCP-сервер со своей конфигурацией. Возможно, это обычный Wi-Fi-роутер, к которому кабель по ошибке подключили через один из LAN-портов. Тогда ваша задача — найти недоверенный DHCP-сервер и предотвратить такие попытки в будущем.
Здесь нужно вспомнить, как работает DHCP-протокол. Клиент отправляет широковещательный запрос (DHCPDISCOVER), который получат все DHCP-серверы в сети и отправят в ответ свои предложения IP-адреса (DHCPOFFER). При этом клиент примет первое полученное предложение (DHCPOFFER), скорее всего, от ближайшего DHCP-сервера, а остальные отклонит.
Очевидно, что предложение от доверенного DHCP-сервера приходит позже, скорее всего, потому, что он дальше от клиента. Для последующей диагностики на устройстве клиента нужно установить анализатор сетевого трафика (Wireshark или tcpdump), запустить его, отфильтровав трафик по типу протокола DHCP или портам 67–68, и посмотреть в DHCP-ответах IP и MAC адрес DHCP-сервера, который их отправляет:
Обновление конфигурации с помощью команды ipconfig /renew
Устраняя неполадки сетевых соединений TCP/IP, начинайте с проверки конфигурации TCP/IP на компьютере, на котором возникли эти неполадки. Если компьютер настроен на использование DHCP и получает конфигурацию от DHCP-сервера, можно инициировать обновление аренды, выполнив команду ipconfig /renew.
Когда выполняется команда ipconfig /renew, все сетевые адаптеры компьютера, на котором используется DHCP (за исключением тех, которые настроены вручную), пытаются связаться с DHCP-сервером и обновить имеющиеся или получить новые конфигурации.
Можно также выполнить команду ipconfig с параметром /release, чтобы немедленно освободить текущую конфигурацию DHCP для узла.
На DHCP-клиентах Windows 95, Windows 98 и Windows Millennium Edition для ручного освобождения или обновления выделенной клиенту IP-конфигурации используйте вместо команд ipconfig /release и ipconfig /renew параметры release и renew команды winipcfg.
9.2.4 Как клиент получает IP-адрес по DHCP
Схема собрана и настроена, теперь нам надо понять, как клиент получает IP-адрес по DHCP от сервера. В тот момент, когда вы завершите настройку DHCP на клиенте, машина поймет, что она не имеет IP-адрес, а также увидеть указание о том, что она должна получить этот IP-адрес по DHCP. Поэтому первое, что сделает DHCP-клиент – это сформирует запрос DHCPDISCOVER, которым попытается найти сервер.
На зеленый пакет, сформированный сервером, не обращайте внимание. Нас интересует желтый пакет, который сформировал клиент, это и есть DHCPDISCOVER, давайте на него посмотрим.
Здесь сразу видно, что пртокол DHCP работает на прикладном уровне моделей OSI 7 и TCP/IP. Также тут видно, что клиент еще не разу не получал IP-адрес от сервера и даже не знает, где этот сервер находится. На транспортном уровне протокол DHCP инкапсулируется в UDP дейтаграммы, когда клиент делает запрос серверу, то в качестве порта источника он выбирает 68 порт, а в качестве порта назначения используется 67 порт.
Клиент не знает IP-адрес сервера, да и своего у него еще нет, поэтому на сетевом уровне в качестве IP-адреса источника он использует IP-адрес 0.0.0.0, а в качестве IP-адреса назначения используется 255.255.255.255. Мы видим, что это широковещательный запрос.
На канальном уровне клиент указывает свой мак-адрес в качестве источника и широковещательный мак-адрес в качестве назначения. Ниже показана структура пакета DHCPDISCOVER, но с ней мы будем разбираться на примере дампа Wireshark.
9.2.9 Структура пакета DHCPDISCOVER в Cisco Packet Tracer
А сейчас продолжим разбираться и посмотрим, что будет, когда запрос DHCPDISCOVER дойдет до серверов.
9.2.10 Запрос DHCPDISCOVER дошел до всех участников канальной среды
Здесь мы видим, что DHCPDISCOVER, посланный клиентом, дошел до всех участников канальной среды, что и не мудрено, ведь он широковещательный, но этот запрос оказался интересным только двум нашим DHCP-серверам. Когда сервер получил DHCPDISCOVER он понял, что в сети появился клиент, которому нужно выдать IP-адрес, сервер смотрит на пул IP-адресов, который у него есть и ищет свободный адрес, обычно это процесс упорядоченный и клиенту будет выдан первый свободный адрес из пула.
Но тут всё не так просто, дело в том, что компьютерная сеть – это то место, где изменения происходят очень быстро, поэтому прежде чем сформировать DHCPOFFER, сервер должен убедиться, что в сети еще не появился какой-нибудь негодяй, который уже начал использовать IP-адрес, который сервер решил выдать этому клиенту, а может случиться так, что другой сервер выдал выбранный адрес клиенту чуть раньше, это надо проверить.
Поскольку у нас канальная среда Ethernet, то для проверки будет идеальным протокол ARP, он позволяет опросить все устройства в канальной среде. Вы же знаете, что при помощи ARP-запроса машины узнают мак-адреса по известному IP-адресу. И дело тут в том, что серверу известен IP-адрес, который он хочет выдать клиенту, он его и использует в ARP-запросе и кричит на всю канальную среду: кто использует IP-адрес такой-то?
ARP-запрос – это зеленый пакет, на котором нет значка паузы. Наши сервера настроены одинаково, базы данных у них сейчас одинаковые, поэтому и ARP-запросы они делают одинаковые, сам запрос показан ниже.
9.2.11 DHCP-сервер делает ARP запрос, чтобы проверить занятость IP-адреса
Тут мы видим, что наш первый сервер спрашивает всех соседей по канальной среде: у кого IP-адрес 192.168.0.1, я сервер с IP-адресом 192.168.0.2? Но, как мы помним, адрес 192.168.0.1 мы настроили на роутере, он уже занят. И ничего страшного, что этот адрес занят нашим маршрутизатором, маршрутизатор получит ARP-запрос и любезно на него ответит своим ARP-ответом, получив ответ, наши сервера поймут, что адрес 192.168.0.1 занят и нужно искать следующий адрес для выдачи.
В зависимости от реализации, после ARP-запроса, сервер может еще попробовать и попинговать IP-адрес 192.168.0.1, чтобы окончательно убедиться в том, что он занят. Такие проверки будут продолжаться до тех пор, пока DHCP-сервера не доберутся до IP-адрес 192.168.0.4 в своем пуле, ведь это первый адрес, который еще не используется в нашей сети, для этого адреса будет сформирован ARP-запрос, на который никто не ответит.
9.2.13 ARP-запрос от DHCP сервера, на который никто не ответит
9.2.16 Внутренности пакета DHCPOFFER
Во-первых, сервер понимает, что у клиента еще нет IP-адреса, понимает сервер это потому, что в его базе данных еще нет мак-адреса клиента и нет сопоставления этого мак-адреса с IP-адресом, который был выдан. Во-вторых, мы видим, что сервер предлагает клиенту получить IP-адрес 192.168.0.4. В-третьих, в пакете DHCPOFFER сервер указывает свой IP-адрес, чтобы клиент знал, кто ему это всё предложил.
Получив DHCPOFFER клиент не забирает себе IP-адрес, сперва он должен убедиться, что этот адрес еще никто не использует, для этого он делает ARP-запрос в сеть, в данном случае ему был предложен адрес 192.168.0.4, значит и спрашивать клиент будет: кто в сети использует адрес 192.168.0.4? Клиенты не используют ICMP для проверки, им это не надо, а вот серверам надо, в дальнейшем мы поймем – в каких ситуациях это действительно необходимо.
- С каким сервером клиент захотел работать.
- На какой IP-адрес клиент согласился.
В процессе написания я столкнулся с еще одной странностью в Cisco Packet Tracer: после ARP-запроса клиент получил IP-адрес и на этом всё закончилось. Поэтому дальше только словесное описание, а потом мы его дополним дампами из Wireshark.
Если в командной строке клиента сейчас выполнить команду ipconfig, то можно будет увидеть настройки, которые клиент получил от сервера.
Сетевая получает неправильный IP 169.254.X.X
merial » 12 янв 2012, 13:39
Компу присваевается неверный IP(должен быть 192.168.Х.Х). Стоит автоматическое получение.
DHCP работает.
ipconfig /renew не работает
"Произошла ошибка при обновлении интерфейса. Не удается связаться с DHCP сервером. Превышено время ожидания".
Файрволов нет. Антивирей нет. Ос Windows 7 32. Драйвера на сетевую ставил разные.
Раньше на компе стояла XP и все работало, но после того как был пойман вирь, было решено снести XP и поставить 7. После этого сетевуха не работает.
Как победить заразу?
Postman Pechkin » 12 янв 2012, 13:50
Nick_III » 12 янв 2012, 13:55
У меня 169-е адреса получаются, когда карта "висит в воздухе".
В первую очередь переткнул бы в другой порт на свитче, поменял кабель.
Более экзотичный вариант - рестарт DHCP-сервера.
___
В беспроводном варианте - не работает Wi-Fi / Bluetooth конечного устройства.
merial » 12 янв 2012, 13:57
Postman Pechkin писал(а) 12 янв 2012, 13:50: Может драйвер для сетевухи криво встал? В диспечере устройств она верно показывается?
Nick_III писал(а) 12 янв 2012, 13:55: В первую очередь переткнул бы в другой порт на свитче, поменял кабель.
Nick_III » 12 янв 2012, 13:58
Nick_III писал(а) 12 янв 2012, 13:55: В первую очередь переткнул бы в другой порт на свитче, поменял кабель.
S.E.S. » 12 янв 2012, 14:05
А /release перед этим делали?
ipconfig /all нормальный MAC выдает или все нули?
Если IP статикой прописать - работает?
imperor » 12 янв 2012, 14:06
merial
адреса из этого диапазона выдаются, когда сетевуха не может получить адрес с DHCP сервера, к примеру, косяк на промежуточном оборудовании.
Nick_III » 12 янв 2012, 14:10
Сервера, конечно.
Если у вас ещё и на клиентской машине DHCP-сервер (не клиент) запущен - бедлам в сети знатный получится.
Но перед этим лучше всё-таки исключить неисправность карты / кабеля / порта.
merial » 12 янв 2012, 14:12
Nick_III писал(а) 12 янв 2012, 13:58: Это ради бога - но другой конец провода куда-то втыкается ведь?
S.E.S. писал(а) 12 янв 2012, 14:05: А /release перед этим делали?ipconfig /all нормальный MAC выдает или все нули?Если IP статикой прописать - работает?
imperor писал(а) 12 янв 2012, 14:06: адреса из этого диапазона выдаются, когда сетевуха не может получить адрес с DHCP сервера, к примеру, косяк на промежуточном оборудовании.
Если у вас ещё и на клиентской машине DHCP-сервер (не клиент) запущен - бедлам в сети знатный получится.
Nick_III » 12 янв 2012, 14:17
S.E.S. » 12 янв 2012, 14:18
Тогда остается BIOS обновить, раз уж сеть исправна.
imperor » 12 янв 2012, 14:19
Nick_III
скорее кабель, если проблема с дровами, тогда сетевой просто не будет или будет со знаком ошибки.
Вольтик » 12 янв 2012, 14:23
Проверить наличие свободных адресов на серваке (может все заняты или ограничено присваиваемое количество).
Глянуть логи DHCP на серваке на предмет ошибок.
Проверить физический линк.
merial » 12 янв 2012, 14:27
Перед этим стояла и работала другая сетевуха, но вчера она умерла. Поставлена была так как не хотелось на тот момент разбираться со встроенной.
imperor писал(а) 12 янв 2012, 14:19: скорее кабель, если проблема с дровами, тогда сетевой просто не будет или будет со знаком ошибки.
Вольтик писал(а) 12 янв 2012, 14:23: Проверить наличие свободных адресов на серваке (может все заняты или ограничено присваиваемое количество).
RomualdOso » 12 янв 2012, 14:34
imperor писал(а) 12 янв 2012, 14:19: скорее кабель, если проблема с дровами, тогда сетевой просто не будет или будет со знаком ошибки.
По всем параметрам всё же что-то с кабелем, коннектором на кабеле, портом на свиче. Самое правильное на этот кабель попытаться повесить другой компьютер или ноутбук и посмотреть - он заработает или нет. А может сетевуха не просто так умерла вчера?!
Тогда повременить с подключением другого компьютера.
Как вариант переткнуть в другой порт на свиче.
imperor » 12 янв 2012, 14:38
merial
Андрей, попробуй на ходу сделать сетевухе Disable, потом Enable.
И ещё на сервере DHCP в Address Leases посмотри, есть этот комп? По имени и по МАСу.
Можно попробовать вручную дать компу адрес из того же диапазона, что раздаётся сервером, но точно не занятый (посмотреть свободные адреса в списке Leases).
merial » 12 янв 2012, 14:39
Пипец.
Кабель проверялся на другом компе - работал. На этом нет. Чудеса какие-то, ну как так может быть?. )
5 часов трахался - скакал с бубном.
P.S. Проверил кабель опять на другом компе - работает. Спасибо тем, кто заставили таки поменять кабель.
imperor » 12 янв 2012, 14:55
constax » 14 янв 2012, 16:23
gen74 » 06 мар 2016, 11:28
Хоть тема и мертвая другим поможет.
такой баг бывает при создании сети дома. при раздаче WI-FI интернета с компа.
решил проблему таким путем
Всеми любимый CMD
вводим netsh winsock reset и ввод правда перед этим отключаем локалку. а то может помешать.
потом вводим ipconfig /flushdns ну и ввод
если это не помогло. что бывает
заходим пуск-администрирование -службы ищем службу DHCP отключаем. включаем
то же проделываем с DNS потом перезапускаем соединение и о чудо вместо 169.254. дает 192.168. поздравляю всех))))
Чтобы взаимодействовать с другими, каждому устройству в сети необходимо иметь четыре основные настройки на сетевом адаптере — IP-адрес, маску, шлюз по умолчанию и адреса DNS-серверов (хотя последнее на самом деле опционально). Есть два основных способа назначения сетевых настроек — статически (вручную) и динамически (автоматически по протоколу DHCP от DHCP-сервера).
Описание работы tracert
В следующем примере пакет должен пройти два маршрутизатора (10.0.0.1 и 192.168.0.1), чтобы достигнуть узла 172.16.0.99. Шлюз по умолчанию для узла имеет адрес 10.0.0.1, а IP-адресом маршрутизатора в сети 192.168.0.0 является адрес 192.168.0.1.
1 2 мс 3 мс 2 мс 10.0.0.12 75 мс 83 мс 88 мс 192.168.0.13 73 мс 79 мс 93 мс 172.16.0.99 Трассировка завершена .
Устранение неполадок аппаратных адресов с помощью программы arp
Протокол ARP (Address Resolution Protocol) позволяет узлам определять аппаратные адреса сетевых интерфейсов других узлов, расположенных в той же физической сети, по IP-адресам этих узлов. Для более эффективного использования ARP каждый компьютер кэширует сопоставления IP-адресов с аппаратными адресами, устраняя тем самым повторяющиеся широковещательные запросы ARP.
Для просмотра и изменения таблицы ARP на локальном компьютере можно использовать команду arp. Команда arp служит для просмотра кэша ARP и устранения неполадок с разрешением адресов.
Трассировка сети
Корреляция трассировки сети может означать, что DHCP-сервер выполнялся в момент записи события в журнал. Чтобы создать такую трассировку, выполните следующие действия.
перейдите в GitHubи скачайте файл tss_tools.zip .
Скопируйте файл Tss_tools.zip и разверните его в расположении на локальном диске, например в папке C:\Tools.
Выполните следующую команду из C:\Tools в окне командной строки с повышенными привилегиями:
В этой команде замените и <>> на идентификатор события и канал событий, на которые вы будете сосредоточиться в сеансе трассировки. Файлы Tss.cmd_ReadMe_Help.docx, содержащиеся в файле Tss_tools.zip, содержат дополнительные сведения обо всех доступных параметрах.
После запуска события средство создает папку с именем C:\ MS_DATA. В этой папке будут содержаться полезные выходные файлы, содержащие общие сведения о конфигурации сети и домена компьютера. Наиболее интересным файлом в этой папке является% ComputerName% _date_time_packetcapture_InternetClient_dbg. ETL. С помощью приложения сетевой монитор можно загрузить файл и установить фильтр просмотра для протокола DHCP или DNS, чтобы проверить, что происходит в фоновом режиме.
Контрольный список по устранению неполадок
Проверьте следующие настройки.
Служба DHCP-сервера запущена и работает. Чтобы проверить это, выполните команду net start и найдите DHCP-сервер.
Убедитесь, что аренда IP-адресов доступна в области DHCP-сервера для подсети, в которой находится клиент DHCP. Для этого см. статистику для соответствующей области в консоли управления DHCP-сервером.
Проверьте, можно ли найти в аренде адресов все списки BAD_ADDRESS.
Проверьте, имеют ли устройства в сети статические IP-адреса, которые не были исключены из области DHCP.
Убедитесь, что IP-адрес, с которым связан DHCP-сервер, находится в подсети областей, из которых должны быть арендованы IP-адреса. Это происходит, если агент ретрансляции недоступен. Для этого выполните командлет Get-DhcpServerv4Binding или Get-DhcpServerv6Binding .
Убедитесь, что только DHCP-сервер прослушивает порт UDP 67 и 68. Никакие другие процессы и другие службы (такие как WDS или PXE) не должны занимать эти порты. Для этого выполните следующую команду netstat -anb .
Убедитесь, что исключение IPsec-сервера Добавлено при работе с средой, развернутой по протоколу IPsec.
Убедитесь, что IP-адрес агента ретранслятора можно проверить с DHCP-сервера.
Перечисление и проверка настроенных политик и фильтров DHCP.
Трассировка сетевых соединений с помощью программы tracert
Журналы событий
проверьте журналы событий службы "система и DHCP-сервер" (журналы приложений и службMicrosoft Windows DHCP-сервер), чтобы сообщить о проблемах, связанных с наблюдаемой проблемой. В зависимости от типа проблемы событие заносится в журнал для одного из следующих каналов событий: DHCP- сервер: рабочиесобытияDHCP-сервер события административных событийDHCP-серверасистемные событияоповещенияDHCP-сервер событияаудита DHCP-сервера
Журнал сервера DHCP
Журналы отладки службы DHCP-сервера содержат дополнительные сведения о назначении аренды IP-адресов и динамические обновления DNS, которые выполняются DHCP-сервером. Эти журналы по умолчанию находятся в папке%windir%\System32\Dhcp. Дополнительные сведения см. в статье Анализ файлов журнала DHCP-сервера.
Симптомы
Обычно всё начинается с жалоб на неработающий интернет или отсутствие доступа к локальным сетевым ресурсам. Иногда достаточно провести диагностику только на стороне клиента, но может понадобиться полная диагностика и со стороны сервера в том числе. Начнём с первой опции.
сбор данных
Проверка соединений с помощью программы ping
Как правило, рекомендуется проверять наличие маршрута между локальным компьютером и узлом сети, обращаясь сначала к узлу с помощью команды ping и его IP-адреса. Для этого выполните следующую команду:
ping IP_адрес
Используя команду ping, следует выполнить перечисленные ниже действия.
Команда ping использует разрешение имен компьютеров в IP-адреса в стиле Windows Sockets. Поэтому, если обратиться с ее помощью по адресу удается, а по имени — нет, то проблема кроется в разрешении имен или адресов, а не в сетевом соединении.
Если обращение с помощью команды ping на каком-либо этапе закончилось неудачей, убедитесь, что:
• | после настройки протокола TCP/IP компьютер был перезагружен; |
• | IP-адрес локального компьютера является допустимым и правильно отображается на вкладке Общие диалогового окна Свойства протокола Интернета (TCP/IP); |
• | включена IP-маршрутизация и связь между маршрутизаторами функционирует нормально. |
Команда ping может выполняться с различными параметрами, задающими такие характеристики, как размер пакетов, число отправляемых пакетов и срок жизни пакета (TTL), и определяющими, нужно ли записывать используемый маршрут и устанавливать флаг, запрещающий фрагментацию пакетов. Для просмотра этих параметров введите команду ping –?.
C:\>ping -n 2 -l 1450 131.107.8.1 Обмен пакетами с 131.107.8.1 по 1450 байт:
Устранение неполадок имен NetBIOS с помощью программы nbtstat
NetBIOS через TCP/IP (NetBT) разрешает имена NetBIOS в IP-адреса. TCP/IP предоставляет много способов разрешения имен NetBIOS, включая поиск в локальном кэше, запросы к WINS-серверу, широковещательные запросы, запросы к DNS-серверу и поиск в файлах Lmhosts и Hosts.
Программа Nbtstat — удобное средство для устранения неполадок с разрешением имен NetBIOS. Команду nbtstat можно использовать для удаления или исправления предварительно загруженных записей:
Читайте также: