Для корректной работы абонента требуется передавать в OFFER/RESPONSE, кроме выданного IP-адреса, как минимум опции serverIdentifier (идентификатор DHCP-сервера), gate (шлюз), subnetMask (маска подсети), leaseTime (время в секундах, на которое выдаем IP-адрес), dns (DNS-сервера в порядке важности).
| Блок кода | ||
|---|---|---|
| ||
dhcp.option.serverIdentifier=10.0.6.56 dhcp.option.leaseTime=600 # dhcp.net.option.193.106.88.0:255.255.255.0.gate=193.106.88.1 dhcp.net.option.193.106.88.0:255.255.255.0.subnetMask=255.255.255.0 dhcp.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=600 dhcp.option.renewalTime=180 dhcp.option.rebindingTime=420 |
| Примечание | |||||
|---|---|---|---|---|---|
По умолчанию сервер InetAccess не отвечает на RENEW-запросы (чтобы заставить DHCP-клиент перейти в стадию REBIND), но это работает далеко не всегда и далеко не во всех схемах. Чтобы включить обработку RENEW-запросов, в конфигурации корневого устройства (обычно это Access+Accounting) нужно указать (требуется перезапуск InetAccess):
|
Существует множество реализаций 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 |
Возможные проблемы при получении/продлении адреса
На DISCOVER биллинг не отправляет OFFER
Запрос не доходит до биллинга или биллинг не находит сервис договора.
На OFFER от биллинга клиент не присылает REQUEST
Ответ от биллинга не доходит до клиента или клиенту не нравится содержимое пакета. В последнем случае нужно проверить опции serverIdentifier, gate, subnetMask, leaseTime.
На REQUEST от клиента биллинг отвечает NAK, в логах
| Блок кода | ||
|---|---|---|
| ||
Unknown packet (linked offer not found). Discard packet. |
В случае, если это получение адреса (SELECTING state), то возможно, что клиент в REQUEST посылает xid, отличный от того, что он посылал в DISCOVER. Для поддержки таких роутеров в конфигурации корневого устройства (Access+Accounting) нужно указать параметр dhcp.xid=0 (см. выше).
В случае, если это продление адреса (RENEWING или REBINDING), это означает, что биллинг не нашел сессию на данном сервисе с таким MAC-адресом. Возможно, что connection.close.timeout меньше чем leaseTime.
Через время leaseTime у клиента происходит переполучение адреса c DISCOVER-пакетом (SELECTING state)
Скорее всего клиент не поддерживает (из-за ошибки в реализации DHCP-клиента) нормальный REBINDING, а сразу переходит в SELECTING, и в биллинге отключена поддержка RENEW-запросов (dhcp.renew=1) или serverIdentifier указан как 0.0.0.0 или RENEW-пакеты не доходят до биллинга. Нужно настроить поддержку RENEW-запросов - скорее всего DHCP-клиент через RENEWING state (никогда не переходя в REBINDING) будет работать нормально.