BiTel

Всем снова привет.
BGBilling 6.0 + ASR-1001X + C3750 (relay) + DGS-3120 (access)
Столкнулись со следующей проблемой. Если клиент подключен непосредственно в свитч агрегации, который одновременно выступает в этом случае и access, и relay-агентом, то схема с получением адреса через опцию 82 работает. Однако, не можем заставить работать схему с разделением access-уровня и уровня агрегации.

Железки настроены правильно, опции на BG прилетают верные, однако при запросе адреса получаем такую картину:



Здесь:
Client MAC: {0015F904A0C0} - это устройство клиента;
Relay IP: 10.63.9.250 - это свитч агрегации (С3750), он же релей;
sub{1}={00040F280106}
sub{2}={0006D8FEE38B5B40} - данные со свитча доступа. Данные верные. Дальше, собственно видно, что он обнаруживает устройство (14 - это С3750, релей), но не может определить агентское устройство (хотя вот это правильное значение: agentRemoteId=d8fee38b5b40).

И вот это смущает: InetDhcpDevice - Search serv on deviceId: 14; 1; interfaceId: 6 - здесь интерфейс определился верный, шестой, а вот deviceId: 14, хотя у нас access-свитч - 15.

Иерархия следующая:
Access+accounting
ASR1001 ISG
C3750
DGS-3120

А конфиге ISG:


В конфиге С3750:


В конфиге DGS-3120 либо пусто, либо аналогично С3750, пытался и так и так. Однако, эффекта не дает. В динамический код не лазил, но как я понял, есть варианты указать способ поиска AgentRemoteID либо в коде, либо в конфигурации устройств. Подскажите пожалуйста, что может быть не так?

В модуле в 3120 в поле идентификатор прописан MAC-адрес 3120 (d8fee38b5b40)?

Разобрались. Да, дело было в том, что идентификатор был указан неверный.

Есть другой вопрос, он скорее больше риторический. Но все же.
На вики есть статья, про подключение по 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

DHCP-release биллинг не обрабатывает. Т.е. сложно ему доверять. Сессии закрываются по таймауту DHCP-Request-запросов.
Однако такая же проблема может быть с DHCP-Request-RENEW-запросами.

Значения опций можно разобрать до того, как биллинг попытается их вытащить по параметрам конфига, в предобработке DHCP-запроса:
https://docs.bitel.ru/pages/viewpage.ac ... Id=1606513
Но в пакете, я так понимаю, нет нужных данных.


Этот момент мне не совсем понятен. Чем именно отличаются пакеты?

Renew, кстати, отрабатывает корректно, если поставить в корневом устройстве dhcp.renew=1 (или как то так, могу путать).

Пакеты то сами по себе не отличаются, однако в них содержится поле Relay IP:, которое будет содержать тот IP, с которого пришел пакет (это без условия инкапсуляции на ISG). Т.е. с разных интерфейсов придут пакеты с разными Relay IP, а в конфиге в BG указан только один, что и понятно. При этом, в радиус-запросе я не вижу поля, кроме Relay IP, которое бы идентифицировало именно устройство-релей.

По поводу release - ясно, спасибо за инфу.