Разбор архитектуры L2 доступа с Kea DHCP, RADIUS и биллингом

[fiast555]

 

Коллеги, приветствую. Прошу конструктивной критики планируемой архитектуры для абонентского доступа:

1. L2 доступ: На коммутаторах доступа — абонентские VLAN, dhcp snooping + ip source guard, storm-control, bpduguard, lldp disable.
2. DHCP: Централизованный сервер Kea с dhcp-relay на коммутаторах. Kea интегрирован с RADIUS.
3. Управление: Микробиллинг — единая точка истины. Наполняет RADIUS (логин=MAC, пароль, статичный IP) и управляет access-list на маршрутизаторе MikroTik (через API), где также висят simple queue.
4. Логика выдачи IP:
   · Неизвестный MAC (нет в RADIUS) → получает временный IP из пула /27 на свой VLAN.
   · Известный MAC → получает "постоянный" IP из биллинга.

Главный вопрос и сомнение: Как MAC абонента впервые попадает в биллинг? После первой выдачи временного IP монтажник видит этот IP, но биллингу неоткуда узнать соответствующий MAC для автоматического занесения в карточку.

Рассматриваю варианты:

1. Настроить RADIUS Accounting на агрегации, чтобы биллинг слушал Acct-Start и сам подхватывал пару IP-MAC.
2. Обязать монтажников вручную вносить MAC с оборудования.

Интересует опыт коллег:

· Работала ли у кого связка Kea + RADIUS в подобной схеме? Особенно с разными пулами для известных/неизвестных клиентов.
· Как вы решали проблему первичного сбора MAC-адресов? Accounting или другие методы?
· Насколько эффективен MikroTik с динамическими access-list от биллинга на тысячах абонентов? Не проседает ли CPU?

Спасибо за советы!

[jffulcrum]

2 часа назад, fiast555 сказал:

Главный вопрос и сомнение: Как MAC абонента впервые попадает в биллинг? После первой выдачи временного IP монтажник видит этот IP, но биллингу неоткуда узнать соответствующий MAC для автоматического занесения в карточку.

Рассматриваю варианты:

1. Настроить RADIUS Accounting на агрегации, чтобы биллинг слушал Acct-Start и сам подхватывал пару IP-MAC.
2. Обязать монтажников вручную вносить MAC с оборудования.

Не очень хорошо замену роутера пользователем превращать в административный кошмар с обращениями в ТП и диктовкой адресов по телефону (error prone). Свою ТП тоже ставите раком при спорных ситуациях, когда надо проверить подключение, исключив роутер абонента. 

 

2 часа назад, fiast555 сказал:

Насколько эффективен MikroTik с динамическими access-list от биллинга на тысячах абонентов? Не проседает ли CPU?

Тут смотря что за роутер. В случае CHR (надеюсь) вопрос чисто в масштабировании ресурсов. На практике на двух ядрах не замечено проблем с ACL в 2500+ записей. С железками сложнее, особенно если хочется offload.

[nixx]

совершенно неконструктивная критика - любую авторизацию по макам - давить в корне.

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

 

ну и "централизованный сервер" тоже немного неправильно. dhcp/radius'ов должно быть два или больше. что будет с абонентами, когда вы "централизованный" уведете на профилактику/обновление/физический сервер сдохнет?

Edited February 3 by nixx

[Saab95]

11 часов назад, fiast555 сказал:

1. L2 доступ: На коммутаторах доступа — абонентские VLAN, dhcp snooping + ip source guard, storm-control, bpduguard, lldp disable.

Столько устаревших слов в одном предложении давно не было на этом форуме=)

 

На коммутаторе каждый абонентский порт запаковывается в уникальный влан. Вот это все - dhcp snooping + ip source guard, storm-control, bpduguard, lldp disable. - не надо.

 

Каждый коммутатор подключаете к промежуточному микротику на узловой точке агрегации. Если по схеме будут цепочки устройств, например в доме 4 коммутатора - то можно 4 на один порт микротика.

 

На микротике сразу заводите абонентские вланы, на них сразу вешаете серые IP адреса статикой без маски подсети, настраиваете выдачу 1-го адреса поштучно из локального пула и время аренды 5 минут.

 

11 часов назад, fiast555 сказал:

Главный вопрос и сомнение: Как MAC абонента впервые попадает в биллинг? После первой выдачи временного IP монтажник видит этот IP, но биллингу неоткуда узнать соответствующий MAC для автоматического занесения в карточку.

Монтажник подключит кабель абонента в коммутатор, на порт прилетит IP адрес - это и будет адрес абонента.

 

11 часов назад, fiast555 сказал:

Насколько эффективен MikroTik с динамическими access-list от биллинга на тысячах абонентов? Не проседает ли CPU?

Очень эффективен, но без слов "динамическими access-list от биллинга".

 

Должна быть схема разрешено все, что не запрещено. Ведь при подключении абонента ему выдается уникальный IP адрес. Он заводится в биллинг и он отправляет команды на установку ограничения скорости, когда у абонента закончатся деньги - биллинг отправит блокировку этого IP.

 

Количество заблокированных абонентов всегда меньше, чем активных. И при 1000 абонентах в блокировках будет 50-100-200 человек, и правил блокировок будет максимум 200. В случае же схемы - все запрещено - будет 800 записей в списке разрешенных для доступа.

 

11 часов назад, fiast555 сказал:

Спасибо за советы!

Сейчас 2026 год, строить L2 сеть уже устаревшая технология. У микротика есть CRS коммутаторы, у которых пропускная способность на роутинге 1-2 гига в сторону 10Г порта. По статистике редко с какого коммутатора доступа уходит скорость более 1 гигабита, поэтому можно сразу L3 сеть построить и авторизовать абонентов на порту доступа. По цене особо разницы не будет, что коммутатор микротика, что от того же длинка / тплинка.

[Стич]

14 часов назад, jffulcrum сказал:

Не очень хорошо замену роутера пользователем превращать в административный кошмар с обращениями в ТП и диктовкой адресов по телефону (error prone). Свою ТП тоже ставите раком при спорных ситуациях, когда надо проверить подключение, исключив роутер абонента. 

Как решаете проблему когда инженер путает порты абонентов на доступе?

[fiast555]

У нас pon cdata, коммутаторы доступа tplink 2600tq, eltex 2124, Cisco. Микротиков на доступе нет и не будет 

[TheUser]

23 часа назад, fiast555 сказал:

Наполняет RADIUS

RADIUS входит в состав биллинга или внешний?

[fiast555]

Внешний 

 

[TheUser]

В 03.02.2026 в 16:34, fiast555 сказал:

Как MAC абонента впервые попадает в биллинг

Самописный провижининг портал, который поздоровается, и в ножки покланяется, и паспортные данные спросит, а потом отработает всю логику с добавлением нужных записей в правильные таблички RADIUS-сервера/биллинга.

 

[jffulcrum]

8 часов назад, Стич сказал:

Как решаете проблему когда инженер путает порты абонентов на доступе?

Walled garden при появлении нового mac

[fiast555]

Vlan per user буду внедрять

[Saab95]

8 часов назад, fiast555 сказал:

У нас pon cdata, коммутаторы доступа tplink 2600tq, eltex 2124, Cisco. Микротиков на доступе нет и не будет 

Вот перед пон станциями и устанавливать микротик, сводить все абонентские вланы на него, там же сразу выдавать IP адреса. Железка вида RB4011 справится с трафиком около 4-5 гигов, может и больше.

 

7 часов назад, TheUser сказал:

Самописный провижининг портал, который поздоровается, и в ножки покланяется, и паспортные данные спросит, а потом отработает всю логику с добавлением нужных записей в правильные таблички RADIUS-сервера/биллинга.

На проверке попадетесь с таким порталом=) Персональные данные можно вводить только в сертифицированные системы - это биллинг, либо его веб интерфейс для абонентов. Скан паспорта тоже будете через портал загружать?

 

6 часов назад, jffulcrum сказал:

Walled garden при появлении нового mac

Это все технологии начала 2000 годов, а сейчас 2026 год наступил.

 

3 часа назад, fiast555 сказал:

Vlan per user буду внедрять

Мыслить надо широко, а смотреть - далеко.

 

Сеть для чего создаете? Что бы находиться на уровне развития 2000 года? Сейчас уже тянуть L2 в центр сети и обрабатывать его считается устаревшей технологией, и такая сеть будет ограничена только одним центральным узлом. Пропадет связь до него - у всех пропадет услуга. Подкинуть резерв где-то на периферии не выйдет.

[murano]

7 часов назад, Saab95 сказал:

На проверке попадетесь с таким порталом=) Персональные данные можно вводить только в сертифицированные системы - это биллинг, либо его веб интерфейс для абонентов. Скан паспорта тоже будете через портал загружать?

Да кто вам это сказал? Сертификация требуется только на биллинг, в котором идет тарификация помегабайтно/повременно. Вы на ворд с экселем тоже сертификат имеете, куда вводите ПД абонентов? Не вводите людей в заблуждение.

[TheUser]

9 часов назад, Saab95 сказал:

Скан паспорта тоже будете через портал загружать?

Нет, я обычно загружаю паспорт в микротик, через Winbox, с использованием передовой технологии drug and drop.

 

[Saab95]

15 часов назад, murano сказал:

Не вводите людей в заблуждение.

Если идет обработка персональных данных, то они (данные), должны быть защищены и передаваться через сеть связь в зашифрованном виде. Вряд ли самописный портал будет соответствовать таким требованиям.

 

Если посмотрите на ситуацию по ПД сейчас, то никто не использует не подтвержденные данные. Всегда требуются подтвержденные, их можно получить из портала госуслуги, от банков, от сотовых операторов и т.п. В любом случае с кем-то из них будет заключен бумажный договор, где абонента проверили на соответствие ПД.

 

По схеме оператора абонентам нужно идти в офис и подписывать договор.

[murano]

6 часов назад, Saab95 сказал:

Если идет обработка персональных данных, то они (данные), должны быть защищены и передаваться через сеть связь в зашифрованном виде. Вряд ли самописный портал будет соответствовать таким требованиям.

 

Если посмотрите на ситуацию по ПД сейчас, то никто не использует не подтвержденные данные. Всегда требуются подтвержденные, их можно получить из портала госуслуги, от банков, от сотовых операторов и т.п. В любом случае с кем-то из них будет заключен бумажный договор, где абонента проверили на соответствие ПД.

 

По схеме оператора абонентам нужно идти в офис и подписывать договор.

Вы либо на НПА конкретные ссылайтесь, либо прекращайте показывать некомпетентность. Нет требований к сертификации внутренних ИС операторов ПД. Есть требования к защите, а не к сертификации софта. Также есть требования ФСТЭК, но это уже отдельная тема, относящаяся далеко не ко всем ОПД.

[ixi]

MAC лучше заменить на vlan-per-user или option82

 

И да, рано или поздно вам попадутся абоненты, у которых дхцп не работает / не устраивает. Можно от таких отказаться заранее, но можно и предусмотреть вариант без дхцп заранее.

 

На микротике (1036) когда-то было тысяч 5 подсетей в address list, нормально работал. Единственная проблема -- обновление таких списков очень медленно.

Edited February 6 by ixi

[npokypop]

4 часа назад, ixi сказал:

На микротике (1036) когда-то было тысяч 5 подсетей в address list, нормально работал. Единственная проблема -- обновление таких списков очень медленно.

Зачем столько подсетей ? Вы на каждого выдавали \32 ?Или как схема у вас была ?

[Saab95]

7 часов назад, ixi сказал:

или option82

Опция 82 еще более устаревшая технология, чем вланы.

 

7 часов назад, ixi сказал:

Можно от таких отказаться заранее, но можно и предусмотреть вариант без дхцп заранее.

На микротике легко статику прописать при /32 на абонента.

 

2 часа назад, npokypop сказал:

Зачем столько подсетей ? Вы на каждого выдавали \32 ?Или как схема у вас была ?

У нас вообще никаких подсетей нет, адреса поштучно, список только с IP адресами должников, а их 10-20 процентов от всех абонентов, полное количество IP есть в ограничениях скорости, но их можно перенести из центра на маршрутизаторы промежуточных узлов.

 

Есть схемы, где за каждой пон станцией, на которой подключено по 1-2 тысяч абонентов, стоит CCR2004, и он нормально их шейпит. Много таких устройств забирают на себя нагрузку, а в центре вообще ничего не требуется, кроме как данные в интернет маршрутизировать.

[ixi]

В 06.02.2026 в 20:04, npokypop сказал:

Зачем столько подсетей ? Вы на каждого выдавали \32 ?Или как схема у вас была ?

Просто блокировки изначально делали на ацл, потом уже от них ушли.

 

В 06.02.2026 в 22:50, Saab95 сказал:

Опция 82 еще более устаревшая технология, чем вланы.

Это лучше чем по маку, и реализуется элементарно. Kea и смену мака нормально отработает.

 

В 06.02.2026 в 22:50, Saab95 сказал:

На микротике легко статику прописать при /32 на абонента.

Вопрос в необходимости radius accounting, для статики на микротике его уже не настроить.

 

[Saab95]

13 часов назад, ixi сказал:

Это лучше чем по маку, и реализуется элементарно. Kea и смену мака нормально отработает.

Эта технология была актуальна, когда коммутаторы могли обрабатывать ограниченное количество вланов, что бы не делать схему влан на коммутатор, придумали эту опцию 82, что бы получать номер порта абонента.

 

По той же схеме можно настроить авторизацию по Radius на коммутаторе - там тоже будет передаваться информация о порту, с которого пришел запрос. Но что-то эту технологию не вспоминает никто=)

 

13 часов назад, ixi сказал:

Вопрос в необходимости radius accounting, для статики на микротике его уже не настроить.

Нетфлоу последней версии предоставляет намного больше возможностей для сбора данных о трафике абонента.

 

Кроме всего никто не мешает через радиус делать авторизацию по DHCP, а статический адрес выдавать в ответе. На самом интерфейсе абонента будет закреплен один адрес.

[Ivan_83]

15 hours ago, Saab95 said:

По той же схеме можно настроить авторизацию по Radius на коммутаторе - там тоже будет передаваться информация о порту, с которого пришел запрос. Но что-то эту технологию не вспоминает никто=)

Потому что она не пошла в массы, осталась в некоторых энтерпрайзах, для кого в целом и задумывалась.