Jump to content
Калькуляторы

ISG в Linux

Может добавим в dictionary

VALUE Service-Type lISG-User 101

Добавить можно. А почему не хотите использовать $cfg{nas_identifier}?

Share this post


Link to post
Share on other sites

Один RADIUS сервер обрабатывает запросы от DHCP/PPTP/PPPOE/HotSpot/ISG сервисов. Алгоритмы проверок/генерации атрибутов разные. Соответственно перед тем как направить пакет в нужную очередь, нужно понять что за он.

А Nas-Identifier - атрибут не обязательный. Microsoft его, к примеру, игнорирует.

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

Edited by dolphinik

Share this post


Link to post
Share on other sites
dolphinik, просто нестандартный атрибут - это не очень хорошо. Могут возникнуть проблемы у тех, кто не имеет в своем словаре:
VALUE Service-Type lISG-User 101

.

Share this post


Link to post
Share on other sites

Всё работает.

Авторизация/Аккаунтинг/CoA/PoD.

 

Правда Service-Type lISG 101 в свои словари я добавил. Так проще.

Share this post


Link to post
Share on other sites
Работает в production - в онлайне до 4k сессий, трафик ~120 pps.

А потянет ли ваш продукт 10K сессий, завсисит ли расширяемость от софта? или только железо влияет на производительность?

Share this post


Link to post
Share on other sites
allexch, потянет и больше (а nr_buckets=8192 по умолчанию). Дело не в количестве сессий, а в количестве пакетов в секунду. Я особо серьезно не занимался тестированием, но при ~600K PPS синтетического трафика мелкими пакетами (в одну сторону), включение lISG и заворот в него этого трафика, увеличивало среднюю загрузку CPU по ядрам примерно на 3-5%.

Share this post


Link to post
Share on other sites

А планируется ли добавить возможность одной сессии на несколько IP, для случая, когда у пользователя несколько адресов? Чтобы был общий accounting и policer.

Share this post


Link to post
Share on other sites

Алексей Андриянов, можно. Но мне кажется, что это должен поддерживать и RADIUS-сервер - в каком-то виде (видимо в Access-Accept) давать lISG понять, что у новой сессии есть родитель - существующая сессия - на нее все и насчитывать. Так это Вам представляется, или иначе?

 

Share this post


Link to post
Share on other sites

Думаю проще всего будет, если радиус-сервер в access-accept будет передавать полный список IP, для которых действительна эта сессия.

 

lISG тогда будет сопоставлять эту сессию с пакетами на/с любого из указанных IP, и все будет работать по-старому.

 

Тогда радиус-сессия будет всего одна, не нужно будет вводить понятие подчиненных сессий.

Share this post


Link to post
Share on other sites

Алексей Андриянов, понял. В каком виде должен быть этот список? Какой атрибут лучше использовать для передачи?

 

Share this post


Link to post
Share on other sites

Да я на самом деле деталей не знаю, т.к. ISG и Radius у себя на сети не использую, скорость ограничиваю через tc, а трафик считаю через netflow. Просто мне очень понравилась идея ISG на Linux, прикидывал, как можно ее прикрутить к своей сети, вот и всплыл этот вопрос про несколько IP.

 

Спасибо большое за участие, но мне эта фича пока не нужна. Думал, может кому-то пригодится. Но похоже реализовать ее довольно просто, так что если соберусь ставить, то или сам допишу, или вернемся к этому разговору :)

 

Умник, то что вы делаете - это круто. Так держать!

Share this post


Link to post
Share on other sites

Очень интересная вещь.

Все работает, но не могу понять почему у меня show_all ругается

 

Incorrect packet length (112 bytes)

Recv from kernel: Interrupted system call

 

притом что show_count

 

Approved sessions count: 1

Unapproved sessions count: 0

 

Версия ядра не подходит?

У меня 2.6.31-20

 

Еще.

iptables я скомпилил 1.4.2

Но вроде уже есть поддержка 1.4.4?

 

 

 

 

 

Share this post


Link to post
Share on other sites

Да

 

x86_64 GNU/Linux

 

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

И есть ли уже возможность делить по классам трафик (Интернет на одной скорости, паритеты на другой)

Share this post


Link to post
Share on other sites

andrew_G, ядро 64-битное (uname -m)?

Отправил в личку вопрос по совместимости с модулем LANBilling для мультисервисных bras me60 и isg

Share this post


Link to post
Share on other sites
andrew_G, ядро 64-битное (uname -m)?
Отправил в личку вопрос по совместимости с модулем LANBilling для мультисервисных bras me60 и isg

Это сложный вопрос.

Мы когда запускали me60 вместо цисковской 10008, его прошивку переделывали практически по звонку в Китай)

В результате после недели работы их спеца у нас, наполнение радиуса стало похоже на то что у нас было на 10008 циске.

Для меня лично что надо в linux ISG:

 

- Шейпер, желательно по классам трафика.

- COA для изменения параметров сессии или отрубания ее вообще.

- Хотелось бы, чтобы таймаут сессии и время жизни сессии отдавались радиусом (хотя не уверен, что этого нет)

 

В результате было бы здорово получить более производительный роутер для езернет абонентов, чем можно собрать сейчас с шейпером на tc.

Есть ли такой шанс?

Edited by andrew_G

Share this post


Link to post
Share on other sites
andrew_G, ядро 64-битное (uname -m)?
Отправил в личку вопрос по совместимости с модулем LANBilling для мультисервисных bras me60 и isg

Это сложный вопрос.

Мы когда запускали me60 вместо цисковской 10008, его прошивку переделывали практически по звонку в Китай)

Согласен, что сложный. Мы как раз прошли похожий процесс у одного из операторов на нашем биллинге в средней полосе России (не с Вами ли :), и я откровенно поражен как китайцы оперативно крутят прошивки, но, тем не менее, совершенно очевидно, что с точки зрения радиус протокола, наш радиус сервер вынужден иметь специфику как одного так и другого устройства, причем не на уровне VSA, а глубже, на уровне отличающихся принципов организации мультисессии. Мой вопрос разработчикам linux isg скорее был про совместимость наших радиус интерфейсов.

Share this post


Link to post
Share on other sites
andrew_G, ядро 64-битное (uname -m)?
Отправил в личку вопрос по совместимости с модулем LANBilling для мультисервисных bras me60 и isg

Это сложный вопрос.

Мы когда запускали me60 вместо цисковской 10008, его прошивку переделывали практически по звонку в Китай)

Согласен, что сложный. Мы как раз прошли похожий процесс у одного из операторов на нашем биллинге в средней полосе России (не с Вами ли :), и я откровенно поражен как китайцы оперативно крутят прошивки, но, тем не менее, совершенно очевидно, что с точки зрения радиус протокола, наш радиус сервер вынужден иметь специфику как одного так и другого устройства, причем не на уровне VSA, а глубже, на уровне отличающихся принципов организации мультисессии. Мой вопрос разработчикам linux isg скорее был про совместимость наших радиус интерфейсов.

Я понял. Нет мы не работали вместе, потому что я из Одессы.

Пользуюсь своим биллингом, так как нужно кроме услуги Интернет еще считать и аналоговое ТВ и цифровое ТВ и домофоны. Но это уже вопрос не по теме.

Как раз этот проект мне интересен, потому что большие дорогие брасы для больших компаний ничем не заменишь уже, а недорогих брасов пропускной способностью до 1 Г я не видел.

Недорогой я имею ввиду где то 3-4 тыс баксов

Edited by andrew_G

Share this post


Link to post
Share on other sites
x86_64 GNU/Linux
Да, аккаунтинг тоже будет работать неверно, к сожалению. Причину понял, буду исправлять.

 

И еще просьба выложить пример наполнения таблиц радиуса для 1 пользователя по максимуму.
Ничего особенного:

User-Name = 123.123.123.123 (IP-адрес клиента)
User-Password = 123.123.123.123 (равен User-Name)
Class = 1024/1024 (Скорость download/upload)
Framed-IP-Address = 63.63.63.63 (IP-адрес для статического преобразования 1-to-1 NAT средствами iptables)

 

И есть ли уже возможность делить по классам трафик
Еще нет, но планирую. Чтобы не изобретать велосипед, интерфейс взаимодействия для RADIUS буду делать аналогичным упомянутому Huawei ME60 (тем более jp1111 в этом заинтересован).

 

- COA для изменения параметров сессии или отрубания ее вообще.
Есть.

 

Хотелось бы, чтобы таймаут сессии и время жизни сессии отдавались радиусом
Этого нет, но тоже сделаю - не сложно. Уточните, под таймаутом сессии подразумевается Idle timeout? А "время жизни" - это максимальная продолжительность (Session timeout)?

 

В результате было бы здорово получить более производительный роутер для езернет абонентов, чем можно собрать сейчас с шейпером на tc.

Есть ли такой шанс?

Есть конечно. :)

Share this post


Link to post
Share on other sites
В результате было бы здорово получить более производительный роутер для езернет абонентов, чем можно собрать сейчас с шейпером на tc.

Есть ли такой шанс?

Есть конечно. :)

Мне вот интересно за счет чего? Основная нагрузка на роутере или мосте от shape и NAT. Shape оптимизируется хешированием, NAT будет работать быстрее при схеме "1 в 1" за счет меньшего размера таблицы.

Как вы будете это оптимизировать? Как реализован шейпер/полисер архитектурно?

Да вот еще что, тут многие сошлись во мнении, что IPv4 не очень подходит для IPoE из за перерасхода адресов. Поддержку v6 планируете?

Share this post


Link to post
Share on other sites
Хотелось бы, чтобы таймаут сессии и время жизни сессии отдавались радиусом
Этого нет, но тоже сделаю - не сложно. Уточните, под таймаутом сессии подразумевается Idle timeout? А "время жизни" - это максимальная продолжительность (Session timeout)?

 

Huawei-Policy-Name := mir1000

Session-Timeout := 86400

Huawei-Qos-Profile-Name := ua10000

Idle-Timeout := 300

 

 

Вот то что отдается me60 у нас. Подобный функционал хотелось бы иметь.

mir 1000 - описанный на хуавее 1Мбит/c на внешку

ua10000 - соответственно на Украину, описанный там же.

Idle-Timeout - через сколько будет отваливаться сессия при неактивности абонента.

Session-Timeout - через сколько сессия будет падать в любом случае.

 

Но вообще то я считаю что не надо повторять абсолютно хуавей, потому, что сам увидел как быстро у них все меняется.

Edited by andrew_G

Share this post


Link to post
Share on other sites

Интересен функционал DHCP сервера с опцией 82, у циске c функцией ISG где старт сессии происходит по DHCP Discover message... сама циска является DHCP сервером.

Коммутатор доступа добавляет DHCP Option 82 Circuit и Remote ID в запросы DHCP

ISG аутентифицирует пользователя по комбинации Circuit и RemoteID в качестве username, пароль фиксированный

ISG сессия должна быть с DHCP инициатором...

Конец сессии по истечении времени аренды DHCP lease expiry...

DHCP с функцией Radius уже отыскал http://www.netpatch.ru/dhcp2radius.html сейчас проверим функционал и после этого надо будет думать как связать с вашим изделием ;)

 

 

 

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now