Интеграция LANBilling c CISCO ISG (IPoE)

Компания «Сетевые Решения» благодарит Холодилова Александра Олеговича, руководителя службы эксплуатации СПД (сети передачи данных) компании «Радист» (торговая марка ТВИНТЕЛ) за предоставленный материал статьи. Статья носит ознакомительный характер и не является документацией. Начиная с версии 005, LANBilling 2.0 будет иметь свой встроенный DHCP сервер.

1. Введение

В данной статье приведен пример внедрения LANBilling для предоставления услуги доступа в интернет на базе модели IPoE и технологии Cisco ISG с идентификацией клиента по порту доступа. Данная статья не претендует на абсолютную верность, т.к. схема работы до сих пор дорабатывается. Но, тем не менее, общая концепция взаимодействия LB и ISG остается неизменной, и, надеюсь, поможет начинающим пользователям в процессе внедрения.

2. Общий принцип функционирования

Рисунок 1

1. Абонент при подключении к сети запрашивает адрес от DHCP-сервера.

2. Коммутатор доступа вставляет в DHCP-Request опцию 82, которая состоит из двух субопций – Remote-ID (идентификатор устройства, вставившего опцию, как правило, MAC-адрес или IP коммутатора) и Circuit-ID(номер модуля и номер порта на модуле, в который подключен клиент). Если не порту доступа обнаруживается DHCP-сервер, то ответы от него подавляются.

3. Далее broadcast-пакет попадает на коммутатор агрегации с настроенной функцией DHCP-Relay, откуда уже unicast-пакет пересылается на внешний DHCP-сервер. На коммутаторе агрегации делается запись в таблице DHCP-Snooping, на основе которой работает функция Dynamic ARP Inspection. Эта функция позволяет динамически создавать связку MAC+IP на основе данных DHCP-Snooping и отбрасывать трафик от клиентов, не получивших адрес от DHCP. Таким образом, уже на уровне агрегации получается верифицированный IP, по которому можно однозначно идентифицировать клиента.

4. Далее трафик попадает в ядро сети, откуда перенаправляется в BRAS c поддержкой функционала Cisco ISG.

5. На BRAS к трафику применяются политики ограничения согласно данным, полученным из биллинга. В случае, если сессия аутентифицирована, трафик заворачивается в NAT, иначе пользователю показывается страничка с информацией о блокировке.

В этой схеме биллинг занимается только аутентификацией и авторизацией пользователей, адресным пространством же занимается внешний DHCP-сервер, никак не связанный с биллингом.

Таким образом, для реализации описанной выше схемы нужно следующее:

Коммутаторы доступа с функцией DHCP-Snooping.
Коммутаторы агрегации с функционалом L3 и поддержкой DHCP-Snooping, DHCP-Relay и Dynamic ARP Inspection/IP Source Guard.
Функционал DHCP-Relay, DAI, IP Source Guard может быть вынесен на коммутаторы доступа, однако желательно все- таки оставить эти функции на коммутаторах агрегации.
На коммутаторах доступа и агрегации порты, направленные в сторону DHCP-сервера должны быть сделаны доверенными для того, чтобы ответы от DHCP-сервера пропускались коммутатором. Соответственно порты, направленные в сторону абонентов должны быть недоверенными для того, чтобы исключить появление неавторизованных DHCP-серверов.
DHCP-Snooping на коммутаторе агрегации не должен переписывать значение опции 82, вставленную коммутаторами доступа на недоверенных портах.
BRAS с поддержкой Cisco ISG (Cisco 7200/Cisco ASR10xx/Cisco ESR), настроенный на инициализацию сессии при прохождении трафика. Сервер DHCP с поддержкой опции 82 (к примеру, DHCPD).

Далее опишем процесс настройки DHCP-сервера, агента RADIUS и BRAS.

3. Настройка DHCP-сервера

В качестве DHCP-сервера используется ISC DHCPD версии 4.1.1-P1-15+ из стандартных репозиториев Debian Squeeze. К достоинствам DHCPD стоит отнести низкие требования к ресурсам – сервер, обслуживающий примерно 50-70 запросов в секунду, при размере конфига в 600 кб потребляет 11 мб памяти менее 0,1% ЦП.

Примерная конфигурация:

ddns-update-stylenone;
default-lease-time 600;
max-lease-time 600;
log-facility local7;
authoritative;

if exists agent.circuit-id
{
log (info, concat(
"Leased address ", binary-to-ascii (10, 8, ".", leased-address),
" for MAC ", binary-to-ascii(16, 8, "", substring(hardware, 1, 6)),
" at switch ", binary-to-ascii (16, 8, "", suffix( option agent.remote-id, 6)),
" on port ", binary-to-ascii (10, 8, "", suffix( option agent.circuit-id, 1)) ,
" invlan ", binary-to-ascii(10, 16, "", substring(option agent.circuit-id, 2, 2))));
}

subnet 10.0.0.0 netmask 255.0.0.0 {

class "0:e:5e:13:d8:e7-1"{
match if (binary-to-ascii (10, 8, "", suffix( option agent.circuit-id, 1)) = "1")
# and (binary-to-ascii (10, 16, "", substring ( option agent.circuit-id, 2,2)) = "vlanid");
and (binary-to-ascii (16, 8, ":", suffix ( option agent.remote-id, 6)) = "0:e:5e:13:d8:e7");
}

pool {
allow members of "0:e:5e:13:d8:e7-1";
range 10.21.255.225;
option subnet-mask 255.255.255.244;
option routers 10.21.255.254;
}
}

Из примера видно, что для связки MAC коммутатора + номер порта выделяется отдельный класс, к которому привязывается пул из одного адреса со своим набором опции. Функция «suffix» берет последние 6 байт из поля RemoteID при вычленении MAC-адреса коммутатора доступа и 1 байт при вычленении номера порта. Затем эти значения конвертируются из бинарного вида в ASCII функцией «binary-to-ascii» и сравниваются с условиями. Если условие соответствия выполняется, то выдается адрес из привязанного пула.

Хотя конфиг DHCPD и кажется несколько громоздким, тем не менее, его генерация очень легко автоматизируется. Сгенерированный конфиг же меняется только в случае замены коммутатора. Таже DHCPD позволяет включать в конфиг произвольные текстовые файлы при помощи функции include, что позволяет структурировать конфиг.

В нашем случае при установке нового коммутатора под него выделяется подсеть и на основе шаблона создается конфигурационный файл, в котором заранее описываются все порты устройства. Далее конфиг коммутатораподключается к общему конфигу DHCPD через include.

В дальнейших планах у нас интеграция DHCPD и LBInventory с целью автоматизации генерации конфига DHCP-сервера. В дальнейшем абоненту выделяется порт и его адрес остается неизменным.

Более подробно настройка и работа DHCP-Snooping описана здесь:

DHCP-snooping;
82-DHCP

4. Настройка биллинга

При создании учетной записи в качестве логина указывается IP-адрес абонента, привязанный к порту коммутатора. Именно по sourceip и производится дальнейшая идентификация пользователей.

5. Настройка агента

Для организации взаимодействия биллинга с ISG BRAS необходимо запустить агент RADIUS с некоторыми изменениями в настройках. В частности, необходимо запретить отдачу атрибута Framed-IP-Address в Access-Accept, т.к. выдачей адресов занимается внешний DHCP-сервер.

Также необходимо установить таймаут зависшей сессии небольшим (60 секунд). Необходимо это для тех случаев, когда сессия по какой-то причине не завершается корректно. Если BRAS попробует заново аутентифицировать сессию до истечения таймаута, то биллинг ответит ему отказом т.к. будет считать ее работающей.

Скриншот настроек агента приведен ниже.