BiTel

Добрый день!

Подскажите пожалуйста, не могу разобраться, как-то правильно работать с DHCP опцией serverIdentifier?

Схема: SE100 в режиме DHCP прокси, авторизация IPOE. Необходимо выдавать клиентам "серые" и "белые" IP адреса в зависимости от настроек категории в сервисе привязанном к договору. И при этом в зависимости от пула, как я понимаю, нужно правильно выставлять опцию serverIdentifier, и также смотреть что идет в Relay IP и в SRC IP UDP пакета.


Работаем на 5.2

serverIdentifier вроде бы предназначен только для идентификации клиентом DHCP-сервера.
Т.е. клиент шлет DISCOVER - несколько DHCP-серверов шлют ему OFFER.
Клиент выбирает одного и шлет REQUEST с serverIdentifier выбранного DHCP-сервера (этот REQUEST может прийти к обоим DHCP-серверам, а обработать его должен только сервер с указанным serverIdentifier).

Спасибо большое за разъяснение. Я видимо не до конца понял логику работы. Где-то читал что serverIdentifier важен при RENEW state из которого некоторые DHCP-клиенты берут целевой IP-адрес DHCP-сервера для запроса на продление лизинга, который шлют юникастом. Вследствии при схеме с релеем (а в случае CLIPS на SE100 еще и проксирование DHCP запроса имеется) могут возникать проблемы.

Да, для этого по RFC serverIdentifier тоже используется.
Причем у наших клиентов по разному, видимо зависит от коммутаторов и схемы: у кого-то вроде бы RENEW вообще игнорируется, у кого-то как-то обрабатывается так, что до биллинга доходит с option82, у кого-то как-будто преобразуется в RELAY-запрос от коммутатора/циски/SE, у кого-то RENEW запросы обрабатывает биллинг.
Т.е., например, у кого-то вроде бы нормально работало только при serverIdentifier=0.0.0.0, у кого-то - только при serverIdentifier=адрес InetAccess.

У SE вроде есть режим, когда он сам делает leaseTime маленьким, обрабатывая частые RENEW сам (чтобы была возможность побыстрее отнять адрес при сбросе сессии), т.е. вышестоящему DHCP-серверу запросы приходят реже, чем на самом деле идет от клиента.

Вот у меня как раз такая ситуация сейчас - SE100 взял на себя ответ клиенту и продлил ему адрес (юникастом), а вот на InetAccess DHCP Helper CLIPS он не послал ничего. В результате InetDhcpHelperProcessor - Remove connection remove делает.

Пока не нашел как в SE100 этим манипулировать. А как билингу правильно указать, что там SE100 хлопочет за него в части продления лиз?

В случае с InetDhcpHelperProcessor - DHCP там как-бы вспомогательный. RADIUS-сессия есть - отвечает на запросы по DHCP (выдавая тот адрес, что в сессии), нет - не отвечает.
Т.е. вроде как в этом случае биллингу все рано, приходил DHCP-пакет или нет. Сессию он ведет по RADIUS.

Сорри, ошибся, проблема оказалась не в этом.

SE100 присылает Аккаунтинг-СТОП пакет с формулировкой



Собственно проблема где-то в DHCP диалоге. Внимательно еще раз посмотрел на дамп и понял, что сам DHCP клиент по какой-то причине видимо игнорирует DHCP ACK от SE100, поскольку пытается запросить адрес до последнего и в финале дает широковещательно новый запрос на выдачу адреса, после чего SE100 ему говорит NACK и оправляет на биллинг Аккаунтинг-СТОП по установленной сессии.

Пример DHCP ACK который игнорирует клиент. Сам клиент это DLINK DIR-615.

А OFFER на который роутер послал REQUEST ничем не отличается от ACK?
Биллинг здесь участвует? Если да, что в его логах c DHCP диалогом?

Отличались они тем, что не было ServerIdentifier, как только DHCP Helper стал отдавать ServerIdentifier=0.0.0.0, то продление аренды заработало корректно. Не заметил как в процессе отладки у меня в конфиге ServerIdentifier оказался закомментирован.