Я собираюсь ответить ... (больше места;)
Сначала вопрос. Испытываете ли вы задержку в получении правильного IP с сервера? На мой взгляд, для получения правильного IP потребовалось более полутора минут (192.168.1.33). Если это так, может быть, мы должны посмотреть ближе к запросам.
Я думаю, что протокол правильный, как сейчас.
Я фильтровал только трафик из / в LenovoMo в / из MS-NLB-PhysServer. (По крайней мере, я думаю, что я сделал;)
я использовал фильтр
((((eth) && !(bootp.hw.mac_addr == 00:bb:3a:89:67:be)) && !(bootp.hw.mac_addr == b4:98:42:d6:63:c1)) && !(bootp.hw.mac_addr == e0:69:95:74:b2:43)) && !(bootp.hw.mac_addr == 78:e4:00:9d:fd:6b)
Вот что я получил (щелкните правой кнопкой мыши и выберите "открыть в новой вкладке" для увеличения):
- Глядя на первый запрос DHCP (строка № 1), ваш клиент запрашивает 192.168.1.35.
- Он получает DHCP NAK (без правильного IP) с сервера.
- Клиент переходит в режим обнаружения DHCP и отправляет несколько пакетов для обнаружения (как и должно быть).
- Сервер отправляет предложение DHCP (также несколько раз), и я думаю, что оно предлагает 192.168.1.33.
- В строке 9 клиенты снова пытаются получить 192.168.1.35 с запросом DHCP
(дважды, почему? может быть, он упрямый;) (клиенту разрешено отправлять несколько запросов)
- Снова сервер отвечает DHCP NAK.
- ...
- Это продолжается минуту.
- ...
- Наконец, в строке # 63 клиент делает запрос DHCP с IP 192.168.1.33.
с «Опцией: (54) Идентификатор сервера DHCP» (как и должно быть). (увидеть ниже)
Я не уверен (пока), почему это занимает так много времени, но все запросы DHCP, которые клиент делает (до строки 63), запрашивают 192.168.1.35 и, таким образом, являются запросами на ОБНОВЛЕНИЕ того же IP во время INIT-REBOOT.
Вопрос: корректно ли поведение DHCP-клиента? Могут ли стандарты измениться?
Но... Я думаю, что ответ на вопрос ...
ДА, это правильное поведение клиента
и НЕТ, стандарты не изменились;)