...
В опции 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).
...
| Блок кода | ||
|---|---|---|
| ||
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:
...
Аналогично этому параметру, в конфигурации устройства (не обязательно корневого) можно указать (требуется нажать "Перечитать конфигурацию на серверах"):
| Блок кода | ||
|---|---|---|
| ||
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) будет работать нормально.