[arni]

Кстати, шейпер по направлениям возможен?

конечно! :)

 

POLICE upload/download (помордная) и POLICE_GLOBAL upload/download (общая)

 

в одном полисере можно сделать кучу различных зарезок - какие match-правила добавите, так и будет их резать

Эффективнее всего ACL - все списки проверяются сразу и результат кэшируется, но это уже как кому нравится.

[VVSina]

Остаётся вопрос как определить направления ;)

 

Вот есть локалка и есть внешка, и оба этих направления через общий шлюз.

[arni]

Остаётся вопрос как определить направления ;)

 

Вот есть локалка и есть внешка, и оба этих направления через общий шлюз.

По префиксам например. 60 направлений хватит ? :)

[vop]

По префиксам например. 60 направлений хватит ? :)

 

60 направлений, или префиксов?

[arni]

60 направлений, или префиксов?

 

направлений конечно! вот тут детали - http://www.uplink-spe.com/docs/#acl

[Dyr]

Извините, что не читал документацию, но интересно следующее:

 

1. Шейпирование клиентов по /29 (то есть каждому клиенту выделена приватная сеть /29, одна скорость делится на все 8 адресов в ней).

 

2. Синхронизация правил и состояний (conntrack) между BRAS'ами, и механизм их резервирования (VRRP?).

 

3. Раскидывание нагрузки по BRAS в более-менее автоматическом виде (упёрлись в потолок производительности одного - поставили рядом такой же, и он взял на себя нагрузку).

 

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

 

Как с этим, есть решение/перспективы?

 

P.S. И сразу задумывайтесь о IPv6.

 

 

[arni]

1. не проблема. все сессии создаются как /32 (IPv6 как /64), НО - есть slave-сессии, которые шарят профиль/полисер и зарезки (http://www.uplink-spe.com/docs/#aaa , параметр master_ipv4).

2. conntrack не используется, у нас CG-NAT и у клиента постоянный пул внешних портов. Синхронизацию активных портов еще не сделали, но в фич-реквестах уже добавлено :)

Синхронизацию правил не особо нужно - можно все полисеры/профайлы создать на всех брасах. Плюс чтобы не бомбить радиус при поднятии сессий - можно загружать заранее маппинг IP в profile/policer. кроме NAT ничего не пострадает при переводе на резервный брас. Но в вашей конфигурации это критично, так что вам лучше ждать следующих релизов - а то лучи добра от клиентов обеспечены

3. это уже сетевыми средствами надо делать - VRRP/BGP или вланы балансировать.

4. IPv6 - уже есть, полная реализация наравне с IPv4 (maps/acl/session).

[Dyr]

Понял, буду ждать. Выглядит многообещающе.

 

По 2 - у нас CGNAT и статический есть (бинат то бишь), и динамический.

 

 

[arni]

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

[Shadance2]

По описанию у вас присутствует DPI и вроде как acl по ip.

Не понятно, можно после acl по ip-адресам назначения сделать фильтрацию URL для http пакетов?

(Это чтобы организовать список URL-ов, которые будут запрещены клиентам)

[arni]

По описанию у вас присутствует DPI и вроде как acl по ip.

Не понятно, можно после acl по ip-адресам назначения сделать фильтрацию URL для http пакетов?

(Это чтобы организовать список URL-ов, которые будут запрещены клиентам)

Да, можно - hostlist acl и обычные acl с точки зрения профиля не отличаются.

Только учитывайте, что DPI у нас пока только state-less - за коннектами не следим. Но добавлять IP адреса в acl если были запросы на определенный HTTP-хост - запросто ;)

[arni]

Залил скомпайленную под 3.19 ядро 15.2 версию софта. Добавил mod_tproxy, чтобы не надо было тащить с гитхаба и компайлить.

IP-unnumbered/DHCP relay в этой версии нет - пока еще допиливаем dhcp-relay и компонуем все вместе.

[arni]

Добавил новую версию 15.2.1 под ubuntu1504 и 3.19.0-14-generic

Исправлено несколько багов в user-space утилитах (в том числе в uspe-client dump и в acct-proxy)

uplink-spe_15.2.1_ubuntu1504-3.19.0-14-generic.tar.gz

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

[arni]

Очередной багфикс-релиз, под ubuntu1504 и 3.19.0-14-generic : www.uplink-spe.com/downloads/uplink-spe_15.2.2_ubuntu1504-3.19.0-14-generic.tar.gz

Исправили ошибку в SNAT

[arni]

Исправили пару ошибок, выложили еще один багфикс-релиз - 15.2.3

теперь outgoing интерфейс определяется для L3 трафика даже если модуль работает до iptables (в хуке PRE-ROUTING).

для заметки : если IPtables изменит destination, то USPE конечно же об этом не узнает, так как пакет уже обработан.

плюс еще исправлено несколько багов с парсингом конфига.

версии для самых свежих ядер убунты и centos :

uplink-spe_15.2.3_centos7-3.10.0-229.1.2.el7.x86_64.tar.gz

uplink-spe_15.2.3_ubuntu1504-3.19.0-15-generic.tar.gz

[arni]

Новый баг-фикс релиз софта - 15.2.4. Исправлен матчинг переименованных интерфейсов и улучшен burst для рейт-лимитеров.

 

uplink-spe_15.2.4_centos7-3.10.0-229.1.2.el7.x86_64.tar.gz

uplink-spe_15.2.4_ubuntu1504-3.19.0-15-generic.tar.gz

[Vinc]

У нас задача, собрать систему которая сможет смаршрутизировать трафик хотябы от 8K пользователей. Лучше от 16K. На нашем случае это 13/26Гб трафика.

 

Мы рассматриваем два варианта:

1) linux bras (терминация qinq, acl, полисинг, netflow, nat)

2) cisco bras (терминация qinq, acl, полисинг) + linux (только nat и netflow)

 

Второй вариант рассматриваем, чтобы избежать возможных глюков.

Какой трафик сможет проварить система собранная на 2* Xeon E5-2690V2 по вариантам 1) и 2)

Сколько времени ваш роутер стоит в продакшене? Есть ли известные баги?

[NiTr0]

Я бы как минимум разнес нагрузку на несколько брасов (n+1) с резервированием. Возможные глюки вероятны всегда, но если есть резервирование - даже полный отказ браса не особо побеспокоит юзеров, если резерва нет - это будет печально.

[Vinc]

Я бы как минимум разнес нагрузку на несколько брасов (n+1) с резервированием.

Согласен.

Речь не идет о нагрузке на один сервер всех пользователей.

Изменено 18 мая, 2015 пользователем Vinc

[TheUser]

Было бы неплохо через DKMS сделать установку для debian/ubuntu.

[arni]

У нас задача, собрать систему которая сможет смаршрутизировать трафик хотябы от 8K пользователей. Лучше от 16K. На нашем случае это 13/26Гб трафика.

 

Мы рассматриваем два варианта:

1) linux bras (терминация qinq, acl, полисинг, netflow, nat)

2) cisco bras (терминация qinq, acl, полисинг) + linux (только nat и netflow)

 

Второй вариант рассматриваем, чтобы избежать возможных глюков.

Какой трафик сможет проварить система собранная на 2* Xeon E5-2690V2 по вариантам 1) и 2)

Сколько времени ваш роутер стоит в продакшене? Есть ли известные баги?

 

Пока у нас нет результатов тестирования на подобном железе. Очень ждем тестов на свежих I7+DDR4, думаю результаты можно будет расценивать хотя бы как минимум, который будет точно работать на 2x E5 :)

Надеюсь собрать новые цифры в течении недели :)

 

Было бы неплохо через DKMS сделать установку для debian/ubuntu.

 

Думаем как сделать что-то подобное, но очень хочется сделать полноценный дистрибутив и тогда это будет не актуально :)

[TheUser]

У меня на свежеустановленном сервере неправильно аптайм показывает:

# uspe-client system info
System info: Uptime: 198 days 20:29, 8 CPUs/8 Cores, 3132MB RAM/3919MB Free, Load 1261/535/440, 0 processes

 

# uptime
10:12:13 up 24 min,  3 users,  load average: 1.07, 0.47, 0.29

 

Куда баги репортить?

[arni]

У меня на свежеустановленном сервере неправильно аптайм показывает:

# uspe-client system info
System info: Uptime: 198 days 20:29, 8 CPUs/8 Cores, 3132MB RAM/3919MB Free, Load 1261/535/440, 0 processes

 

# uptime
10:12:13 up 24 min,  3 users,  load average: 1.07, 0.47, 0.29

 

Куда баги репортить?

 

можно сюда) Баг мы этот уже знаем, в следующей версии уже поправим ;)

[MATPOC]

Сейчас очень горячая тема - Virtual CPE. Основная идея - простой CPE на стороне клиента, расширенный сервис на железе оператора. То есть клиентское CPE работает в режиме коммутатора или бриджа, проключая трафик от всех устройств клиента, сидящих на порте, в BRAS. То есть однозначно QinQ, DHCP для клиентских устройств на стороне BRAS'а.

 

CG-NAT либо с выделением фиксированного IP адреса на каждый Virtual CPE, либо плоский для всех устройств со всех портов. Для плоского CG-NAT надо каждому Virtual CPE выдавать отдельную сеть для исключения пересечения адресов. Например, 10.12.123.0/24 - 12-узел, 123 порт в сквозной адресации всех портов коммутаторов узла. Хотя, с плоским CG-NAT'ом могут быть сложности учёта для СОРМ'а.

 

Ещё одна привлекательная идея Virtual CPE - дать возможность самому клиенту определять приоритеты полосы внутри своего тарифа для различных устройств. Типа, для своего компа - 80%, для планщета жены - 15%, для телефона ребёнка - 5%.

 

На КРОС-2015 был круглый стол, посвящённый виртуальным CPE и маршрутизаторам. Рассказывали Ericsson и Juniper. У Juniper есть решения виртуальных маршрутизаторов, больше подходящие для бизнеса, а Ericsson рассказывал о виртуальных CPE на стороне провайдера. Почитать об этом можно на сайте Ericsson: http://www.ericsson.com/nsearch?query=Virtual+CPE

Изменено 4 июня, 2015 пользователем MATPOC

[arni]

Сама идея сделать CPE дешевле и тупее - однозначно хорошо. К этой теме тоже присмотримся - все-таки такие задачи решать в софте проще и сильно дешевле.

У нас тоже были идеи делать персонализированные сервисы, но пока proof-of-concept решения "в лоб" производительность просаживали слишком некрасиво (эффект CPU кэша сводился на нет). Но принципиально сложностей нет и добавить что-то подобное мы все равно планируем :)

Я думаю с появлением IP-unnumbered QinQ терминацией уже будет довольно много новых возможностей и сценариев использования нашего софта и персонализацией сервисов можно будет заняться плотнее. Например в рамках open-source расширения или наоборот более тесно интегрированного в софт функционала.

 

На сколько знаю, большие вендоры пытаются продать решения с 2-4 уровнями приоритезации? Можно пойти тем же путем или сделать что-то более гибкое и интересное - в конце концов софт ASIC-ами не ограничен. Есть ли какие-то пожелания/хотелки/мечты на эту тему?