Разобрались. Да, дело было в том, что идентификатор был указан неверный.
Есть другой вопрос, он скорее больше риторический. Но все же.
На вики есть статья, про подключение по IPoE с опцией 82, где в качестве dhcp-relay используется ISG. Ссылку в конце скину, называется "Cisco ISG c авторизацией по порту коммутатора", думаю, все видели статью. Так вот, у автора в примере только один интерфейс, который обслуживает абонентов, и он же одновременно является связующим интерфейсом с BG (в конфигурации устройства ISG в BG указан адрес этого интерфейса). Теперь предположим, что мы хотим, используя один БРАС, обслуживать несколько групп абонентов, в разных VLAN-ах, при этом по прежнему хотим аутентифицировать их по логину, который формируется из связки RemoteID+Circuit-ID (собственно, в статье данный пример и разобран). Т.е. в радиус-запросе мы должны эти данные получить, а получаем мы их только если ISG является реелеем и инициирует сессию по dhcp-пакету.
Если мы заводим еще один интерфейс, то как только с него приходит dhcp-запрос на BG, BG нам отвечает, что устройство с указанным адресом не найдено. Оно и понятно - в конфиге то прописан адрес другого интерфейса. Ок, есть способ это обойти. Cisco ASR (да и не только они, а 7200 тоже скорее всего) умеют инкапсулировать значения опции 82 в свои. Т.е., мы дополняем конфиг ISG (на устройстве, не в BG) такими строчками:
ip dhcp relay information policy encapsulate
и затем, на интерфейсе (интерфейсах) мы можем указать, с какого интерфейса мы хотим "релеить" запросы:
ip dhcp relay source-interface loopback0
При таком раскладе, запрос полученный на любой интерфейс, будет отправлен с адресом источника интерфейса lo0, что нам собственно и нужно. Однако, посмотрим на поля опции82:
Agent information{82}=
sub{9}={000000091A0A18000000005212010600040F2A010D020800060023EA650D80}
sub{2}={020A000091FFFDEE00000F2A}
sub{-106}={91FFFDEE}
То, что раньше у нас приходило в саб-опциях 1 и 2, теперь приходит в опции 9! Ладно, раз мы можем отрезать 2 байта от опции 2 для получения RemoteID, что нам мешает разобрать опцию 9? У нас это выглядит вот так:
В конфе ISG:
hcp.deviceSearchMode=0
dhcp.option82.removeHeader=2
dhcp.option82.agentRemoteId.code=9
dhcp.option82.agentRemoteId.position=23
dhcp.option82.agentRemoteId.length=6
В конфе коммутатора доступа:
#FOR ISG RELAY ENCAP:
dhcp.option82.interfaceId.code=9
dhcp.option82.interfaceId.position=18
dhcp.option82.interfaceId.length=1
Работает. Клиент получает адрес, затем аутентифицируется в системе и получает услугу. Но, когда клиент выключает устройство, т.е. отправляет dhcp-release, мы видим:
Agent information{82}=
sub{1}={00040F2A010D}
sub{2}={00060023EA650D80}
и соответственно: Device not found for address:
Так как, если я правильно понимаю, dhcp-release идет уже юникастом на dhcp-сервер (т.е. на BG), и никакой опции 9 в пакете уже нет. Собственно говоря вопрос - как правильно разруливать данную ситуацию? Нам бы желательно, что бы при получении dhcp-release, мы могли отправить на ISG сигнал о завершении сессии, потому что пока получается, что клиента уже нет, а сессия по прежнему висит.
Статья:
http://wiki.bitel.ru/index.php/Cisco_ISG_c_%D0%B0%D0%B2%D1%82%D0%BE%D1%80%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D0%B5%D0%B9_%D0%BF%D0%BE_%D0%BF%D0%BE%D1%80%D1%82%D1%83_%D0%BA%D0%BE%D0%BC%D0%BC%D1%83%D1%82%D0%B0%D1%82%D0%BE%D1%80%D0%B0