kisa

TheRouter переименован в BisonRouter. Вся подробная информация о компании на сайте https://bisonrouter.com The project is now Bison Router! Please visit our website https://bisonrouter.com for more information.

Контакты, указанные на сайте, актуальные. Напишите пожалуйста на почту info at bisonrouter.com

Да, к сожалению, пока не получилось найти причину проблемы в вашем случае. С другим железом, juniper например, LACP работает без проблем.

Добавлена поддержка статических DNAT44 правил в движок Deterministic NAT. https://github.com/alexk99/the_router/blob/master/conf_options2.md#deterministic-dnat44

Этот пример pppoe + nat сервера. Поэтому используются x710 серия, чтобы работал аппаратный RSS для PPPoE. двух портовые intel x710 карты с 40g интерфейсам из которых собран LACP LAG. Небольшие потери бывают в любом софтовом решении. Но именно на этом сервере они практически нулевые. Если вы обратите внимание, то на втором графике видно метрику missed. Это счетчик переполнения входящих очередей NIC.

Привет :) Реализован новый движок CGNAT - поддержка EIM режима - Deterministic режим выбора адресов и портов (https://tools.ietf.org/html/rfc7422) - ограничения кол-ва трансляций - NEL статистика netflow v9 и IPFIX - производительность до 10 Mpps (80Gbit/s) https://github.com/alexk99/the_router/blob/master/cgnat.md Уже в продакшене

не совсем так про шейпер. увеличивает задержку не шейпер с очередью, а постоянно заполненная очередь. бывают ситуации, когда очередь постоянно заполнена, даже если кратковременный берст уже закончился, и входящий поток в очередь не больше рарешенного установленными лимитами исходящего. это очень хорошо расписано здесь https://queue.acm.org/detail.cfm?id=2209336 чтобы избегать ситуаций постоянно заполненных очередей есть алгоритмы RED, codel.

Добавлено лимитирование кол-ва NAT трансляций. https://github.com/alexk99/the_router/blob/master/conf_options2.md#npf-connection-limit-filter-add

Добавлен policer, поддерживающий разные скорости в зависимости от src/dst пакета. Для выбора нужного policer используется классификация с помощью нового механизма prefix map и нового набора radius атрибутов. https://github.com/alexk99/the_router/blob/master/conf_options2.md#therouter_shaper_ingress_params https://github.com/alexk99/the_router/blob/master/conf_options2.md#prefix-map

Завершено боевое тестирование IPv6 PPPoE браса у одного из индийских операторов. Maximum 1670 users, half of them are IPv6 Впечатления индийских коллег: The biggest advantage of TR is salvaged servers can be turned in to at least 10K+ of users supported BRAS. On the other hand the license fee is so minimal which should be affordable to anyone. Moreover its license based on throughput not number of users which is an added advantage. You can have a 25K users supported BRAS with minimal investment. The TR tech team is very much understandable and capable to deploy any scenario which I proposed and implemented in days which is amazing. Below are the other advantages 1. Fully RFC compliant. 2. Better and efficient provision of IPv6 for PPPoE 3. Persist both IPv4 and IPv6 even after server restarts 4. Default IP address pool for IPv4 and IPv6 which enable easy transition for BRAS 5. Blacklisting of nuisance subscriber 6. Sophisticated Tocken Bucket QoS helping smooth browsing experience for customer even on lower bitrate. Одно из внедрений у бразильских коллег PPPoE BRAS без NAT XL710 for 40GbE QSFP+ (rev 02) Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz

Добавлена поддержка IPv6 для PPPoE. Реализация поддерживает rfc3162 - RADIUS and IPv6 rfc4818 - RADIUS Delegated-IPv6-Prefix Attribute rfc5072 - IP Version 6 over PPP rfc6911 - RADIUS Attributes for IPv6 Access Networks rfc8415 - Dynamic Host Configuration Protocol for IPv6 (DHCPv6) TR-187 IPv6 for PPP Broadband Access Новые конфигурационные опции https://github.com/alexk99/the_router/blob/master/conf_options.md#pppoe-ipv6 Пример конфига https://github.com/alexk99/the_router/blob/master/pppoe_ipv6/example1.txt

Примеры конфигов для IPoE VRRP влан на группу абонентов https://github.com/alexk99/the_router/blob/master/bras/bras_ipoe_vrrp.md

Новая фича - IPoE Subscriber VRRP - active-active BRAS кластер. Допустим, нужно запустить два BRAS в режиме active-active для 100 вланов, в каждом из которых есть группа абонентов. Тогда создадим две VRRP группы на обоих серверах. Выставим приоритет одной группы выше на сервере 1, приоритет второй группы выше на сервере 2. Сервер 1 становится мастером для группы 1, бэкапом для группы 2. Сервер 2 - наоборот, мастером для группы 2, бэкапом для группы 1. конфиг: subsc vrrp init dev v3 sysctl set subsc_vrrp_master_down_timeout 10000 subsc vrrp create group 10 prio 5 neighbor 192.168.1.112 subsc vrrp group 10 primary ip 192.168.5.10 subsc vrrp group 10 add vif port 0 svid 0 cvid 5 subsc vrrp group 10 enable Теперь разделим 100 интерфейсов пополам, половину добавляем в группу 1, другую добавляем в группу 2. либо с помощью одиночных команд subsc vrrp group 10 add vif port 0 svid 0 cvid 5 либо с помощью range команд subsc vrrp group 10 add vif range svid 10 20 cvid 200 300 name ipoe_v Cабскрайберы начнут работать с primary ip 192.168.5.10 вместо ip адреса интерфейса. Группа вешает его на все интерфейсы, которые добавлены в группу. Сама создает local маршрут для этого ip. Primary ip адрес связан c VRRP virtual router MAC вида 00:00:5E:00:01:XX где xx - номер vrrp группы. Primary адрес сразу добавляется и на master и на бэкап интерфейсы, но только master отвечает на arp запросы об этом адресе. Тоже самое с созданием новых сабов, только master создает сабы, только мастер выполняет relay dhcp запросов, прилетающих на интерфейсы, контролируемые группой. Бэкап получает от мастера обновления состояния сабов и ведет offline db. Как только бэкап замечает, что мастер отвалился, т.е. как только истекает время subsc_vrrp_master_down_timeout (ms), бэкап становится мастером. Берет offline db и переводит всех сабов в onlline - создает arp, создает маршрут до саба, т.е. делает все, что делал бы при обычном подключении саба. Можно переключить бэкап в состояние master в любой момент, повысив его приоритет. В итоге, первая половина вланов работает через первый сервер, вторая через второй. И в любой момент каждый сервер, может взять на себя нагрузку соседа. Как только группа становится мастером она отправляет gratuitous arp запросы о primary ip на все интерфейсы группы. Чтобы свитчи увидели, что топология поменялась и адрес переехал на новый порт.

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