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

BRAS soft для Linux (шейпер, файрволл, CG-NAT) Еще один софт для нарезки скорости клиентам

Разрабатываем аналог Linux ISG (http://forum.nag.ru/forum/index.php?showtopic=53156).

Это не форк, архитектура и код написаны с нуля. Сейчас готовимся к первому паблик-релизу и хотели бы независимых оценок нашего продукта :)

Прошу подсказать, что бы вы хотели видеть в продукте, или если что-то сделано не так. Ну и ругайте, конечно!

Ссылки на документацию и демо не добавляю, если будет интерес пришлю в личку (или с позволения модератора отредактирую пост позже)

 

Что умеем:


  •  
  • Режим L2 (.1q/q-in-q бридж) и L3 (рутер), можно L2/L3 одновременно
  • Не требует правил в iptables/ebtables
  • Поддержка IPv4, IPv6 и Q-in-Q сессий
  • встроенные Ipset-like хеш-листы ACL для IPv4/IPv6
  • HTTP-редирект с помощью SQUID и собственного модуля TPROXY
  • Cвязь с софтом по TCP (в том числе и удаленная, c ACL для разрешенных IP)
  • Вся конфигурация загружается в ядро (можно загружать как в iptables-restore),
  • Radius accounting & authorisation (через user-space прокси)
  • Статическая авторизация сессий
  • MAC фильтр для каждой сессии (разрешенные MAC-адреса клиента)
  • Квоты трафика (можно например сменить тариф/зарезку когда квоту “съели”)
  • сброс/обновление сессии (CoA)
  • Поддержка Slave-сессий (общаяя сессия для нескольких IP)
  • Принцип микро-файрволлов – (клиентский трафик проходит минимум проверок)
  • Поддержка плугинов – можно дописать свои проверки и действия с пакетами
  • большинство комманд активируются только после commit
  • есть много каунтеров, из которых можно построить красивые графики
  • есть stateless-DPI (пока только для DNS и HTTP), с поддержкой hostname ACL

 

Еще как особая плюшка – софт умеет делать “Carrier Grade” SNAT для IPv4 (не использует conntrack, собственная реализация).

каждый серый IP – имеет свой фиксированный блок ip/port трансляций

лимит одновременных трансляций для каждой сессии

работает в L2 и L3 режимах

статические порты – можно пробрасывать входящие соединения

 

Главное, мы сильно упростили настройку. У нас понятие сессий не связано с “сервисами” как в lISG. Если грубо, то у нас – тариф и статус. Т.е. тариф определяет зарезки, а статус – должник клиент или нет. Например (статус в нашей терминологии Profile, тариф - Policer):

 

topology interface l2 internet eth1 ip
topology interface l2 subscriber eth2 ip

profile create 1 name Enabled
profile add 1 action ACCEPT

profile create 2 name Debitor
profile add 2 action DROP
profile commit

policer create 1
policer add 1 action POLICE_TOTAL download 20480 upload 2048
policer add 1 match proto 17
policer add 1 action POLICE download 10240 upload 1024
policer commit

# <IP> <Profile> <Policer>
map add 10.11.12.0/24 1 1
map add 10.11.12.1 2 1

 

Этого конфига достаточно, чтобы создать помордные зарезки 1M up/10M down для всех клиентов из 10.11.12.0/24, при этом 10.11.12.1 – должник и будет блокирован. При этом еще и общая зарезка на всех клиентов на UDP траффик – 2M up/20M down.

 

Тизер по перформансу:

при 630kpps, 4.5Gbit/s (1min average), 1% CPU на всех ядрах, 17Mb памяти и 12.5K сессий

железо – Intel i7-3770K, Intel x450 10Gbit/s

конфиг – как в примере выше, только количество IP побольше и только одна помордная зарезка на 1Mbit up/10Mbit down

трафик – живые клиенты

Какой потолок – не знаем, не нащупали пока :)

 

UPD: получили бенчмарки на i7-4770 CPU @ 3.40GHz + Intel x520-DA2 на реальном трафике и наконец знаем где потолок на таком железе - 1.9Mpps и 14.5Gbit/s (по данным софта, а мы считаем длину пакета из заголовка IP). С учетом тэгов - чуть больше 15Gbit/s. На этом трафике кончается эффективность кэша и CPU начинает подползать с 60%

 

UPD2: готовится к релизу версия 15.8 - в которой добавили QinQ терминацию, IP-Unnumbered, DHCP-сервер/релей (в том числе в связке с Radius).

 

 

Предвидя некоторые вопросы:


  •  
  • Исходный код – закрыт, но есть возможность дописывать свои плагины
  • Продукт платный, но плата за лицензию одноразовая (за каждый BRAS, но не дорого :)
  • Есть опциональный платный суппорт
  • делаем решения на базе Dell-серверов и Hardware appliance
  • ядро не патчили, так что можем скомпилировать под кастомное ядро
  • только 64-bit системы, linux >= 3.9
  • есть демо - работает сутки, потом нужен рестарт чтобы играться дальше
  • интеграция с биллингом – пока не занимались, расчитываем на Radius :)
  • Сайт еще делаем, но документация есть, если есть интерес добавлю тут ссылку

Edited by arni

Share this post


Link to post
Share on other sites

Звучит приятно. Но какой смысл тестировать закрытый код? По-моему, обычно за это платят.

Share this post


Link to post
Share on other sites

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

А в плане денег - главное чтобы продукт был интересен. Остальное уже пусть Sales делают :)

Share this post


Link to post
Share on other sites

Ну собственно без возможности фактически потестировать продукт, сложно сказать что в нем не так. А так готов поучаствовать в тестировании.

Share this post


Link to post
Share on other sites

Как я понимаю - решение заточено под IPOE? Так же как я понимаю, надеюсь ручками терминировать QinQ сабы не придется?

Как происходит авторизация, по любому пакету или dhcp disc?

Очень бы хотелось, чтобы ФС была ридонли, и на запись открывалась только после commit&save и уйти наконец от HDD в линуксорутерах.

Так же логи, логи отправлять на syslog сервер включая CGNAТ tranlation, а не писать их на системный диск.

---

Конечно все замечательно, а чего документация только на буржуйском? Реально - задолбало уже это.

 

Так же желательно режим shell, как на джунипере start shell с возможность ее автозагрузки и подключение по telnet/ssh

Edited by SyJet

Share this post


Link to post
Share on other sites

Интересная вещь, но синтаксис просто ужасен, правда если оно и правда работает, то не критично. shell однозначно нужен, никто в здравом уме не будет постоянно писать uspe-client чего-то_там

 

ну и да, cgnat без логирования по syslog и желательно по netflow становится малополезным в контексте СОРМа

Share this post


Link to post
Share on other sites

Как я понимаю - решение заточено под IPOE? Так же как я понимаю, надеюсь ручками терминировать QinQ сабы не придется?

Как происходит авторизация, по любому пакету или dhcp disc?

Очень бы хотелось, чтобы ФС была ридонли, и на запись открывалась только после commit&save и уйти наконец от HDD в линуксорутерах.

Так же логи, логи отправлять на syslog сервер включая CGNAТ tranlation, а не писать их на системный диск.

---

Конечно все замечательно, а чего документация только на буржуйском? Реально - задолбало уже это.

 

Так же желательно режим shell, как на джунипере start shell с возможность ее автозагрузки и подключение по telnet/ssh

 

Да, заточено под IPoE.

Терминирование QinQ (я так понимаю, IP-unnumbered) - добавил в хотелки, пока в софте не реализовано.

Авторизация - по любому пакету, в том числе входящему

 

Запись конфига - это уже как саму систему настроите. Хоть diskless :) с конфигом работаем как с iptables-save/iptables-restore, соответственно можно сделать как угодно)

Логи - на радиусе + dmesg (софт весь в ядре, логи можем писать только через dmesg), так что всего лишь настройка syslog-ng

CGNAT трансляции тоже отправляются на radius-accounting. В доках список атрибутов отсылаемых вместе с аккаунтингом был.

Режим shell a la Juniper - уже в wishlist'e, сделаем

Share this post


Link to post
Share on other sites

Запись конфига - это уже как саму систему настроите. Хоть diskless :) с конфигом работаем как с iptables-save/iptables-restore, соответственно можно сделать как угодно)

Логи - на радиусе + dmesg (софт весь в ядре, логи можем писать только через dmesg), так что всего лишь настройка syslog-ng

CGNAT трансляции тоже отправляются на radius-accounting. В доках список атрибутов отсылаемых вместе с аккаунтингом был.

Режим shell a la Juniper - уже в wishlist'e, сделаем

 

ну вот начинается - смонтируйте всё сами как вам надо, настройте syslog-ng и т.д. - опять получается полусамопальные решения в стиле linux+pppoe-server/linux+accel-pppd/linux+LISG

 

если уж хотите брать за это деньги, то дайте готовый продукт в виде образа флешки и виртуалки в формате .ova для тестов, в котором только править конфиг и выполнять show-команды, как это делает cisco, juniper и подобные, а не думать как сделать diskless систему, какое ядро поставить и т.д.

Share this post


Link to post
Share on other sites

Интересная вещь, но синтаксис просто ужасен, правда если оно и правда работает, то не критично. shell однозначно нужен, никто в здравом уме не будет постоянно писать uspe-client чего-то_там

 

ну и да, cgnat без логирования по syslog и желательно по netflow становится малополезным в контексте СОРМа

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

Полноценный шелл сделаем, наработки уже есть - работаем над cisco-like враппером (clish), должно облегчить работу.

Share this post


Link to post
Share on other sites

ну вот начинается - смонтируйте всё сами как вам надо, настройте syslog-ng и т.д. - опять получается полусамопальные решения в стиле linux+pppoe-server/linux+accel-pppd/linux+LISG

 

если уж хотите брать за это деньги, то дайте готовый продукт в виде образа флешки и виртуалки в формате .ova для тестов, в котором только править конфиг и выполнять show-команды, как это делает cisco, juniper и подобные, а не думать как сделать diskless систему, какое ядро поставить и т.д.

 

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

Но на счет демо учтем на будущее ;)

Share this post


Link to post
Share on other sites

Да, заточено под IPoE.

Терминирование QinQ (я так понимаю, IP-unnumbered) - добавил в хотелки, пока в софте не реализовано.

Хм, странно, а для чего тогда вообще ваше изделие, разве что для НАТА? А шейпить (с некоторыми ньюансами) и другими вещами можно. Если сабы нужно руками прописывать - то легче к примеру не шеститоннике q-in-q приземлить и через dhcp адреса раздать. В этом accell тут всех порвал, имхо едиснственная альтернатива bare metal раутеров. В итоге шейпящий бридж получается.

Запись конфига - это уже как саму систему настроите. Хоть diskless :) с конфигом работаем как с iptables-save/iptables-restore, соответственно можно сделать как угодно)

И опять вы не правы, если делаете продукт - то делайте законченное решение. Тут на форуме постоянно идет поиск спецов кто BRAS настроит на ACCELL, потому как далеко не у всех уровень знаний достаточен (включая меня).

По остальному, есть тут форумчанин Nitro - он один из разрабов дистрибутива LEAF - возьмите за основу его, там уже все готово, только установку простую продумайте.

---

ИМХО, основная проблема в позиционирование, кто должен обслуживать BRAS + уровень доступа - linux администратор или сетевой инженер? Если все же сетевик - то он должен работать в shell и не иметь доступа к внутренностям ОС.

---

Представил, нужны деньги на администратора linux, для того, чтобы заплатить деньги за софт для linux, а потом еще к и сетевика к этому BRASу приставить.

По мне - сделайте нормальный, законченый продукт (по аналогии с vyatta) - с удовольствием лично я куплю продукт и суппорт на 6 месяцев - если конечно цена будет, не как за железный bras

Edited by SyJet

Share this post


Link to post
Share on other sites

ну вот начинается - смонтируйте всё сами как вам надо, настройте syslog-ng и т.д. - опять получается полусамопальные решения в стиле linux+pppoe-server/linux+accel-pppd/linux+LISG

 

если уж хотите брать за это деньги, то дайте готовый продукт в виде образа флешки и виртуалки в формате .ova для тестов, в котором только править конфиг и выполнять show-команды, как это делает cisco, juniper и подобные, а не думать как сделать diskless систему, какое ядро поставить и т.д.

 

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

Но на счет демо учтем на будущее ;)

 

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

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

Share this post


Link to post
Share on other sites

s.lobanov, SyJet - Полностью согласен с вами, над готовым дистром тоже работаем. Думаем выпустить позже, когда добавим уже все must-have фичи, вроде DHCP и IP-unnumbered.

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

Share this post


Link to post
Share on other sites

а локальный прокси обязательно? хотелось бы L4 редирект, как в lISG. CG nat как нельзя кстати. Где можно посмотреть расценки на софт?

Share this post


Link to post
Share on other sites

+1 тоже недосмотрел, зачем там прокси? Редиректа вполне достаточно, нечего сквиду с апачами делать на брасах

Share this post


Link to post
Share on other sites

а локальный прокси обязательно? хотелось бы L4 редирект, как в lISG. CG nat как нельзя кстати. Где можно посмотреть расценки на софт?

ядерный L4 редирект делаем, пока не работает.

Расценки - 395 EUR за лицензию, при покупке больше 5 лицензий дешевле. Над сайтом пока еще работаем, так что красивую табличку сравнения цен/количества не смогу показать. Но если что пишите в личку, перешлю в sales.

 

+1 тоже недосмотрел, зачем там прокси? Редиректа вполне достаточно, нечего сквиду с апачами делать на брасах

 

Апачей не надо, просто сквидом редиректом кидайте на отдельный сервер :)

Прокся нужна иногда офисным клиентам - хитрые фильтры и т.п. Но согласен, что такие вещи лучше вынести отдельно - делаем ядерный HTTP редирект.

Share this post


Link to post
Share on other sites

+1 тоже недосмотрел, зачем там прокси? Редиректа вполне достаточно, нечего сквиду с апачами делать на брасах

 

Ну кстати вон J наоборот хочет сделать редирект на RE , и многие ждут этого ...

Share this post


Link to post
Share on other sites

Решили на данный момент сосредоточится на разработке IP-unnumbeded интерфейсов.

Планируем автоматическое создание интерфеса при появлении первого пакета от клиента в нужном q-in-q влане. Привязывать q-in-q интерфейс к существующему IP интерфейсу будем статически. В плане конфига думаем примерно так :

 

topology interface l3 subscriber eth1 qinq

map add 10.1 unnumbered br0 peer 10.2.3.1 rp-filter
map add 10.555 unnumbered br1 peer 10.4.5.55

 

Соответственно, можно будет повесить определенные опции на q-in-q интерфейс. DHCP пакеты будет обрабатывать юзерспейс релей.

 

После этого добавим опцию, чтобы блокировать любой трафик, кроме DHCP и будем ставить peer-адрес на интерфейс из DHCP-ответа от сервера :

map add 10.1 unnumbered br0 

 

 

Мы ничего не упустили? или что-то еще стоит добавить?

Edited by arni

Share this post


Link to post
Share on other sites

Интерфейс будет подыматься по DHCP пакету ? , учли что первый пакет может быть с адреса 0.0.0.0

Share this post


Link to post
Share on other sites

Интерфейс будет подыматься по DHCP пакету ? , учли что первый пакет может быть с адреса 0.0.0.0

я специально указал, что на первом этапе интерфейс создается при появлении первого пакета в нужном влане. Если это DHCP - будем кидать на local_input и по идее userspace DHCP-relay должен будет его получить

создание по DHCP/ DHCP-relay / фильтр / парсинг DHCP ответа / trusted DHCP servers - на втором этапе

Share this post


Link to post
Share on other sites

понял, ждем тогда хотя бы релей

Share this post


Link to post
Share on other sites

Хотим посоветоваться. Нашли несколько вариантов реализации ip-unnumbered и родился такой вопрос : Нужен ли на каждый активный QinQ влан отдельный интерфейс?

Не хотим плодить кучу интерфейсов или постоянно обновлять маршруты. Единственный плюс в них видим только для сбора статистики по SNMP, но на сколько оно надо если статистика по сессиям у нас уже есть?

Edited by arni

Share this post


Link to post
Share on other sites

Хотим посоветоваться. Нашли несколько вариантов реализации ip-unnumbered и родился такой вопрос : Нужен ли на каждый активный QinQ влан отдельный интерфейс?

Не хотим плодить кучу интерфейсов или постоянно обновлять маршруты. Единственный плюс в них видим только для сбора статистики по SNMP, но на сколько оно надо если статистика по сессиям у нас уже есть?

А как будет дружить это все с квагой-бЁрдом если не будет интерфейсов? Не будет ли глюков?

Edited by SyJet

Share this post


Link to post
Share on other sites

интерфейсы не нужны, достаточно маршрута типа customer_ip dev NYOH, где нёх это некий виртуальный интерфейс, который передаёт трафик в ядро и как-то там обрабатывается. вопрос в том насколько глубоко хочет автор топика залезать в dataplane

 

или постоянно обновлять маршруты.

 

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

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