[СКАТ 8.3+]
В СКАТ основными ключами в DHCP выступают ClientId (opt61) или, если не указан, MAC-адрес клиента.
Но помимо них существуют и другие ключи, однозначно идентифицирующие клиента, например, Opt82 или QinQ. Часто именно эти ключи выступают идентификаторами абонента в биллинге.

Рассмотрим такой сценарий: имеется QinQ-сеть, абонент в биллинге однозначно идентифицируется по QinQ. Абоненту выдан IP-адрес 10.20.30.40 через DHCP, создана аккаунтинг-сессия A.

Далее абонент меняет свой MAC-адрес (например, меняет свой домашний Wi-Fi роутер на новый). Новый роутер посылает DHCP-запрос на лизинг IP-адреса, биллинг выдает ему тот же адрес 10.20.30.40, так как QinQ-теги (идентификатор абонента в биллинге) не поменялись. СКАТ создает новую аккаунтинг-сессию B.

В результате получаем, что у абонента некоторое время существуют две аккаунтинг-сессии A и B. Это может быть недопустимо для некоторых биллинговых систем (например, для ЛанБиллинга), которые разрешают существование только одной аккаунтинг-сессии для абонента. Более того, биллинг может не выдать абоненту IP-адрес, пока существующая сессия A не остановлена. Получается, что новое оборудование клиента не получит IP-адрес, пока есть активная сессия A.

Для контроля таких ситуаций в СКАТ DHCP Proxy добавлена опция контроля вторичных ключей bras_dhcp_check_secondary_keys. По умолчанию она отключена (=0). Если её включить (bras_dhcp_check_secondary_keys=1), СКАТ будет контролировать вторичные ключи абонента - opt82, QinQ: если по вторичному ключу найдена активная аккаунтинг-сессия, она будет закрыта отсылкой accounting stop перед тем, как СКАТ пошлет запрос выдачи IP-адреса на Радиус.