none
win2k8 dhcp криво работает RRS feed

  • Вопрос

  • Собственно сабж, сегодня утром некоторые компы перестали получать адреса. В логах чисто, никаких ошибок нет. Причем один и тот же комп может получить адрес в одной подсети, а в другой уже нет. Я понимаю, телепатов тут нет, но если были бы ошибки, я бы и сам разобрался, а так, подскажите, куда копать и что смотреть можно?
    10 июля 2012 г. 9:51

Ответы

Все ответы

  • Есть компы, для которых адреса зарезервированы, но все равно не могут их получить.
    10 июля 2012 г. 11:12
  • кабель проверяли на некоторых компах?

    поподробнее про подсети. МБ вы vlan'ы имеете в виду.

    резервации не создавали для компа который не может получить адрес?

    10 июля 2012 г. 11:36
  • Только вчера все работало.

    Да, я имею ввиду вланы,  но суть, вроде, не меняется :)

    Пока только один  комп с зарезервированным ипом не может его получить. Если прописать его вручную, сеть прекрасно работает, но это не выход. 

    Уже около 6-7 компов не могут получить адрес.

    10 июля 2012 г. 11:48
  • проверьте в каком состоянии резервация.

    или попросту ее прибейте и создайте заново (проверьте корректность MAC'а)

    да и гляньте внутренние логи DHCP, т.е. были ли попытки получить адрес.

    в принципе это можно проверить с клиента - если клиент получил IPv4 адрес по APIPA, то значит до DHCP он не достучался, если достучался, но сервер отреджектил запрос айпишник будет по нулям.

    • Изменено Svolotch 10 июля 2012 г. 12:02
    10 июля 2012 г. 11:59
  • еще можно попробовать сделать на scope или на всем сервере reconcile

    • Помечено в качестве ответа Anton_Ivanov 10 июля 2012 г. 14:39
    • Снята пометка об ответе Anton_Ivanov 10 июля 2012 г. 14:39
    10 июля 2012 г. 13:21
    Модератор
  • Внутренние логи, это те, которые лежат в system32/dhcp? Там ничего, обращения клиента нет на тот период времени, когда я подключаюсь.

    Резервация тут непричем, т.к. не получают компы и без нее, и те, у кого был ип арендован, и даже если  аренду убиваю.

    Клиент получает 169.....
    10 июля 2012 г. 14:37
  • Согласовал, ничего не изменилось
    10 июля 2012 г. 14:40
  • снифер на клиента и надо посмотреть что бегает по dhcp
    10 июля 2012 г. 15:30
    Модератор
  • Раз есть VLAN'ы, значит есть коммутатор и есть маршрутизатор, осуществляющий рутинг между VLAN'ами. Возможно сосуществование коммутатора и маршрутизатора в одном корпусе. ;-) На этом же маршрутизаторе должен быть или dhcp-relay, или проксирование DHCP-запросов/ответов. Может быть, на нём что-то покрутили и оно отъехало?

    Если ваши компьютеры получают адреса IANA (вида 169.254.*.*), значит, они не дождались ответа от DHCP-сервера. Если в логах DHCP нет ничего, значит DHCP-запросы до него не доходят. Хотя, это можно проверить с помощью tcpdump'а или winshark'а запущенного на DHCP-сервере.


    Сергей Панченко


    • Изменено Daemon-GTC 11 июля 2012 г. 3:52
    11 июля 2012 г. 3:49
  • Да, есть коммутатор с dhcp relay, но там вроде ничего не крутил
    11 июля 2012 г. 5:41
  • Да, есть коммутатор с dhcp relay, но там вроде ничего не крутил
    Проверьте сниффером, что пакеты DHCP проходят от клиента к серверу и обратно. "Ничего не крутил" - это не значит, что всё работает как должно быть.

    Сергей Панченко

    11 июля 2012 г. 6:01
  • на dhcp сервере по dhcp протоколу смотрел wiresharkom, так только один из моих шлюзов говорил, что неправильная контрольная сумма, других запросов вообще нет. На клиенте ищет, но не может найти.
    11 июля 2012 г. 6:30
  • Я правильно Вас понимаю, что клиент отправляет запросы, а до сервера они не доходят? Ну, так значит, надо пинать Ваш коммутатор/маршрутизатор...

    Сергей Панченко

    11 июля 2012 г. 6:34
  • да, вижу. Сервер отвергает запросы, из за неверной контрольной суммы.
    Которую, в свою очередь, неверно предоставляет шлюз.

    но там в конце концов компы получают адрес. Да, виноват длинк мой скорее всего.
    11 июля 2012 г. 7:34
  • нетворк монитор показал, что клиент получает адрес шлюза. а так же по msgpytpe=inform какую то машинку из той подсети. 
    11 июля 2012 г. 8:54
  • Как я понял их нетворк монитора, загуглив чуток теории по этим запросам, сервак получает дискавер от клиента, посылает ему оффер, который до клиента уже не доходит. Вернее в миониторе на клиенте иногда проскакивает оффер, но не подхватывается. хотя вроде бы там все требуемые параметры есть
    11 июля 2012 г. 10:35
  • Клиент получает DHCPOFFER не по параметрам внутри, а по MAC-адресу.

    Сергей Панченко

    11 июля 2012 г. 11:37
  • в общем не знаю что делать. Вот на тестовой машинке в конце концов все пробилось и она без потерь получает адрес. А стоит удалить ее из дхцп, так снова облом, причем оффер вроде получила,  шлет реквест, но тот не доходит :(



    11 июля 2012 г. 12:18
  • виноват длинк мой скорее всего.

    ....в общем не знаю что делать.

    Перезагрузить Ваш D-Link пробовали? Ещё можно попробовать обновить в нём софт. Ну, а потом - выкинуть и купить нормальный.

    У пакета DHCPOFFER должен быть MAC-адрес назначения равный MAC-адресу компьютера. для которого этот DHCPOFFER предназначен. Думаю, что единственный вариант, по которому компьютер его не берёт - не верно указан этот самый MAC. Если компьютер его всё же, берёт, но не использует - значит, возможно беда другая. Надо читать RFC и сравнивать, что имеем. Скорее всего D-Link что-то путает при ретрансляции DHCP-запросов и ответов. Сравните то, что отправляет компьютер с тем, что получает сервер. И обратно - то, что отвечает сервер с тем, что Вы видите на клиенте. Смотрите не только содержимое пакетов. но и IP-заголовки, и заголовки Ethetnet-фрейма. Хотя бы, узнаете, КАК косячит Ваш D-Link. Ну, а далее - или на форум дэ-линкчан, или... в магазин.


    Сергей Панченко


    • Изменено Daemon-GTC 11 июля 2012 г. 12:33
    11 июля 2012 г. 12:27
  • Вечером буду пробовать другой такой же ставить. Да, перезагружал. Про обновление прошивки забыл, тоже займусь.
    11 июля 2012 г. 12:33
  • И как успехи?

    Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции корпорации Microsoft. Вся информация предоставляется "как есть" без каких-либо гарантий
    Follow us on TwitterFollow MSTechnetForum on Twitter

    Посетите Блог Инженеров
    Доклады на Techdays: http://www.techdays.ru/speaker/Vinokurov_YUrij.html

    16 июля 2012 г. 7:41
  • Тема переведена в разряд обсуждений по причине отсутствия активности


    Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции корпорации Microsoft. Вся информация предоставляется "как есть" без каких-либо гарантий
    Follow us on TwitterFollow MSTechnetForum on Twitter

    Посетите Блог Инженеров
    Доклады на Techdays: http://www.techdays.ru/speaker/Vinokurov_YUrij.html

    18 июля 2012 г. 7:05
  • Проблема была в свиче, из за жары он по каким то причинам резал пакеты :) Сейчас прохладно, все работает чудесно :)
    • Помечено в качестве ответа Vinokurov Yuriy 23 июля 2012 г. 18:55
    23 июля 2012 г. 18:53
  • скорее всего не хватало быстродействия, а в таких случая udp первые кандидаты на отброс.
    23 июля 2012 г. 19:13
    Модератор