Никому уже не надо объяснять, что сервер DHCP является очень удобной штукой, снимающей с админа кучу механической работы. Хочется остановиться на некоторых особенностях работы DHCP-системы клиент-сервер, которых непросто найти в документации.

1. Если на w2003 server установлен сервер DHCP и одновременно включен файервол на сетевом интерфейсе, через который сервер DHCP должен раздавать адреса клиентам, то клиенты не могут получить адрес по протоколу DHCP (команда ipconfig /renew после длинной паузы завершается с сообщением об ошибке получения адреса - не найден сервер “DHCP”). Проблема решается отключением файервола на сетевом интерфейсе сервера DHCP (у клиентов отключать файервол не обязательно).

2. Своеобразно работает связка w2003+сервер DHCP+ISA2004+клиент XP. Если на XP включен файервол, то IP по DHCP выдается всегда только со второй попытки, причем серверу DHCP напрочь отрывает крышу (может, потому, что он работает вместе с ISA 2004) - перестает работать NIC, через который был выдан адрес по DHCP (то есть по этому NIC адреса больше не выдаются, да и вообще трафик через него не идет, даже ping не работает). Серверный NIC снова начинает работать только тогда, когда его запретить и снова разрешить (из контекстного меню NIC). Проблема фиксится, если опять-таки вырубить файервол на клиенте XP.

3. Несколько неожиданно на первый взгляд работает механизм обновления адреса по команде ipconfig /renew - если не истек срок аренды, то клиент даже не пытается сменить адрес с помощью доступного сервера DHCP. Я впервые столкнулся с таким поведением клиента, когда в сети менял сервер DHCP. Действовал по стандартному плану - новому серверу DHCP задал область (scope), непересекающуюся с областью старого сервера DHCP, подсоединил к сети новый сервер, а затем удалил из сети старый. Затем решил попробовать, как работает новый сервер DHCP, запуская на клиентах команду ipconfig /renew - удивление мое было безмерным - создавалось впечатление, что новый сервер DHCP не функционирует, а в сети остался призрак старого сервера, поскольку ни один из клиентов (w2k, w2003, XP) не хотел брать адрес из области нового сервера и упорно брал свой старый адрес (из области старого сервера DHCP). Не спасали перезагрузки клиентов, полное выключение питания с последующим включением, отсоединение/присоединение сетевого кабеля, запрет/разрешение интерфейса. Однако если на клиенте назначить любой (от балды) статический адрес, а потом снова включить автоматическое назначение адреса, то теперь адрес выдавал, как и положено, новый сервер DHCP. Наверное, в алгоритме работы протокола DHCP заложена проверка на попадание старого арендованного адреса в маску подсети нового сервера DHCP, и на основании этого принимается решение о целесообразности получения нового адреса или об оставлении старого. Такой вывод напрашивается потому, что если клиента подсоединить в другую подсеть, то протокол DHCP срабатывает правильно.

4. Если настроить разные области адресов, относящихся к разным подсетям в надежде на то, что через разные сетевые интерфейсы будут выдаваться соответствующие именно “родной” подсети адреса, то это работает, хотя привязки для разных NIC существуют только на сервер целиком (области к NIC привязываются неявно).

5. Странности в установке DHCP-сервера:
а) Устанавливался DHCP на w2003 Server Standard Edition, rus. Все обновления, кроме SP1. На сервере стоит 3 сетевушки - InetLan (внешняя, для Интернета), LocalLan и EnemyLan (внутренние, которые и должен обслуживать DHCP-сервер).
б) После нормального назначения роли и установки DHCP-сервера, запустился мастер создания области. Как обычно, создал область (Enemy150_200, диапазон 192.168.2.150-200).
в) После создания и активирования области сервер оказался помечен красной стрелкой - дескать, еще не все в порядке. Если щелкнуть на имени сервера в консоли управления DHCP, то в правом окне пишет, что нужно сервер авторизовать для успешной его работы в составе Active Directory. Перезапуск сервера нечего не давал (стрелка зеленой не становилась). Область активна, сервер работает, но красная стрелка на имени сервера присутствует (с предложением авторизовать).
г) Предложение авторизовать сервер DHCP в AD странно по двум причинам - сервер домену AD не принадлежит, входит просто в группу WORKGROUP, и в меню отсутствует пункт по авторизации, как предлагается в подсказке по авторизации.
д) Создал вторую область (Local150_200, диапазон 192.168.3.150-200), активировал её.
е) Проверил привязки (оставил только на интерфейсы LocalLan и EnemyLan).
ж) Красная стрелка до сих пор присутствует. Проверил, как DHCP выдает адреса. Оказалось, что EnemyLan выдает их нормально, а LocalLan не выдает. Перезапуск сервера DHCP, запрещение и разрешение интерфейсов ничего не дают. Если назначить адрес на клиенте вручную, то ping через сеть LocalLan проходит (интерфейс LocalLan на сервере физически исправен).
з) После того, как деактивировал область Local150_200 и снова активировал, все неожиданно заработало, и красная стрелка сменилась на зеленую.
Вывод: чаще пляшите с бубном, господа.

6. Использование классов - DHCP Class ID - позволяет различным группам компьютеров Windows получать адреса из разных пулов. Это также делает возможным компьютерам с Windows (они совместимы с DHCP Class ID) давать адреса из одного пула, а другим “неинтеллектуальным” устройствам, например, IP-телефонам - из другого пула. В операционных системах Windows NT DHCP Class ID назначается командой ipconfig /setclassid. Просматривается командой ipconfig /all.