Получение IP-адреса DHCP-клиентом
Для корректной работы абонента требуется передавать в OFFER/RESPONSE, кроме выданного IP-адреса, как минимум опции serverIdentifier (идентификатор DHCP-сервера), gate (шлюз), subnetMask (маска подсети), leaseTime (время в секундах, на которое выдаем IP-адрес), dns (DNS-сервера в порядке важности).
dhcp.option.serverIdentifier=10.0.6.56dhcp.option.leaseTime=600#dhcp.net.option.193.106.88.0:255.255.255.0.gate=193.106.88.1dhcp.net.option.193.106.88.0:255.255.255.0.subnetMask=255.255.255.0dhcp.net.option.193.106.88.0:255.255.255.0.dns=194.165.18.6В опции serverIdentifier обычно нужно указать IP-адрес InetAccess; в некоторых случаях - 0.0.0.0 или адрес Cisco ASR/Redback (если он - relay, который пересылает запросы биллингу).
Опции gate, subnetMask, dns можно указать в IP-ресурсе в соответствующих полях, а не через конфигурацию устройства. Также в конфигурации IP-ресурса можно указать опции, привязанные к этому ресурсу, аналогично конфигурации устройства, через префикс dhcp.option.
Важно учитывать что при истечении времени T1 (или по другому - renewal time) DHCP-клиент переходит в стадию RENEW и начинает отправлять запросы RENEW на продление lease. Если ответа он не получает, то при истечении времени T2 (или по другому - rebinding time) DHCP-клиент переходит в стадию REBIND и отправляет REBIND-запросы для продления lease выданного ранее IP-адреса. Время T1 по умолчанию - это (leaseTime * 0.5), T2 - это (leaseTime * 0.875).
Существуют опции renewalTime и rebindingTime, с помощью которых можно указать конкретные значения, когда DHCP-клиент должен перейти в стадию RENEW, а когда в REBIND. Значение renewalTime должно быть меньше rebindingTime, а значение rebindingTime - меньше leaseTime.
dhcp.option.leaseTime=600dhcp.option.renewalTime=180dhcp.option.rebindingTime=420По умолчанию сервер InetAccess не отвечает на RENEW-запросы (чтобы заставить DHCP-клиент перейти в стадию REBIND), но это работает далеко не всегда и далеко не во всех схемах. Чтобы включить обработку RENEW-запросов, в конфигурации корневого устройства (обычно это Access+Accounting) нужно указать (требуется перезапуск InetAccess):
dhcp.renew=1Существует множество реализаций DHCP-клиентов и не все они работают согласно RFC.
Например, по RFC DHCP-клиент должен посылать DISCOVER и REQUEST из одной сессии запроса IP-адреса с одинаковым xid (Transaction ID), но некоторые DHCP-клиенты в REQUEST, отправляют другой xid (причем isc-dhcp-server обрабатывает это нормально, т.е. не смотрит на xid). Чтобы InetAccess не связывал DISCOVER и REQUEST по xid и обрабатывал такие запросы нормально, в конфигурации корневого устройства (обычно это Access+Accounting) нужно указать (требуется перезапуск InetAccess):
dhcp.xid=0В конфигурации isc-dhcp-server есть параметр always-broadcast:
always-broadcast flag;
The DHCP and BOOTP protocols both require DHCP and BOOTP clients to set the broadcast bit in the flags field of the BOOTP message header. Unfortunately, some DHCP and BOOTP clients do not do this, and there- fore may not receive responses from the DHCP server. The DHCP server can be made to always broadcast its responses to clients by setting this flag to 'on' for the relevant scope; relevant scopes would be inside a conditional statement, as a parameter for a class, or as a parameter for a host declaration. To avoid creating excess broadcast traffic on your network, we recommend that you restrict the use of this option to as few clients as possible. For example, the Microsoft DHCP client is known not to have this problem, as are the OpenTransport and ISC DHCP clients.
Аналогично этому параметру, в конфигурации устройства (не обязательно корневого) можно указать (требуется нажать "Перечитать конфигурацию на серверах"):
dhcp.alwaysBroadcast=1