BiTel

Сегодня к нам приходили представители EcoNAT (http://rdp.ru/)
Предлагают свою разработку, аппаратно-программный комплекс для NAT, URL фильтрации и шейпинга.
Если кому интересно можете высказать свое мнение об этом.
Может у кого то есть вопросы?

а причем тут биллинг?

хотят сделать интеграцию с этой железкой из коробки.
(на самом деле они кроме разработки софта для железа, еще и сами провайдеры и используют эту железку в связке с BGBilling)

лично по мне не вижу смысла, надо на ipv6 лезть. Кто не успел занатится уже железка не спасет
видимо будет как ЭДО, вещь может и хорошая но пока что ни кому не нужна

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

Обычно за подобными российскими разработками скрывается китайское поделие + маркетинговый булшит + желание нагреться на модном нынче тренде "импортозамещения" (влезть в какой-нибудь государственный заказ). Прежде чем что то рассуждать про это "решение", его нужно подержать в руках, а лучше попытаться пристроить для реальной задачи. Даже если они писали софт сами, то логично предположить что там банальный линукс внутри и, внезапно, набор костылей для iptables. Я, конечно, могу ошибаться, всегда есть исключения из правил.

Подобного железа на рынке достаточно много, например, тот же Allot. Ну и всегда остается старая добрая cisco 7200, которая запросто будет и натить и шейпить и фильтровать url-ы. Кстати, на счет последнего, могу опубликовать свой тулкит: серверная часть N2H2 протокола, качатель списков роскомцензуры, diff для этих списков, и немного не дописанный портал (на который собственно идут редиректы и который должен генерировать страничку с извинениями и дополнительной информацией).

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

Тема больше из плоскости "бител думает на тему расширения области применения", разработка комплексных решений не худший вариант, но у меня в таком случае есть вопрос. Почему вы не хотите навести немного лоска в GUI, дописать локализацию и не выйти на другие рынки? В той же канаде или в sea регионе не найдется толпа средних операторов, которые были бы рады вашим продуктам?

Web интерфейс? )

_________________
Цитаты великих людей
Напишите в helpdesk © stark
повторяю: => хелпдеск => доработка => профит © dimOn
свершилось... © skn
Мой код изящен, лёгок, оригинален, краток. Как прохладный весенний ветерок, как звонкий ручей! © dimOn
Вежливый разработчик © Artur
Эти баги тоже исправлены, как и те, которые еще не написаны © Artur
ну т.е. существует воркэраунд, ок © dimOn

Вообще да, на GUI было бы недурно натравить UX/UI разработчика. И еще документацию немного доработать: для продукта, ориентированного на рынок с разным техническим уровнем потребителя (где-то директор и монтажник, и сисадмин, и биллингист, а где-то на биллинг выделено несколько специально обученных сотрудников), документация все-таки должна быть помягче...

БЖБ развивается так быстро , что дока за ним не успевает. Это нормально, у других не лучше. Как говаривал в своё время автор iproute2 - хотите "просветления" - читайте "сырцы".....

_________________
"Все правые - в резерве!" (c) (translate.google.ru/#en/ru/all%20rigths%20reserved)

И FAQ обязателен

_________________
Цитаты великих людей
Напишите в helpdesk © stark
повторяю: => хелпдеск => доработка => профит © dimOn
свершилось... © skn
Мой код изящен, лёгок, оригинален, краток. Как прохладный весенний ветерок, как звонкий ручей! © dimOn
Вежливый разработчик © Artur
Эти баги тоже исправлены, как и те, которые еще не написаны © Artur
ну т.е. существует воркэраунд, ок © dimOn

если весь контент в Нотепаде верстать , то наверное таки да.
Без персонажей типа Saab95 жизнь была-бы скучна ....

_________________
"Все правые - в резерве!" (c) (translate.google.ru/#en/ru/all%20rigths%20reserved)

А какие проблемы с GUI? Мы как то пробовали менять, так сразу некоторые клиенты ворчать начинают, типа наши операторы привыкли, ни чего не трогайте, операторы в ступор впадают...

с GUI все отлично, надо bgcrm пилить

Странно.... Нет, я ни в коем случае не намекал на web-гуй, во первых. Во вторых, под "лоском" я подразумевал пофиксить баги и дописать то что не дописано. А странно, то что никто этого не поддержал.
По ходу тестов понемногу записываю себе тут "замечания", не отсылал их, но раз уж зашел разговор, вот вам на вскидку.

1) В клиенте есть возможность переключаться между серверами, "БД". Если нажать на "дверь", то тебя отлогинит от текущего сервера и вылетит приглашение залогинится обратно. Ну это уже не правильно, клиент просто должен переключится на другой сервер, если такой есть в данный момент в залогиненных. Но интересно другое, если отменить это вылетевшее окошко логина, то клиент закрывается нафик. Т.е. он вообще не в курсе дела что он подлючен к нескольким серверам.

2) При переключении между серверами (см пункт 1) теряются названия вкладок-модулей. Допустим у меня есть экземпляр модуля inet с названием "VPN", открываем закладку этого модуля - она называется "VPN", переключаемся туда-обратно между серверами и опс, вкладка называется "INET"

3) Таблички с информацией по сессиям: модуль inet - монитор или в договоре в отчетах модуля inet. Числовые данные все же надо выравнивать по правому краю. Если переключится на мегабайты/гигабайты, то данные вообще будут с десятичной точкой, и при выравнивании по левому краю разобрать что то сложновато.

4) Те же таблички (пункт 3), "запомнить расположение столбцов" нормально не работает, они постоянно сбрасывается на дефолт. Ну а так как таблица крайне нагружена, то дефолт у нее = "ничего не видно из того что нужно".

5) Привязка сервиса Inet к устройству. Теперь у нас есть устройства библиотечные и устройства в дереве. Одно библиотечное устройство может быть вставлено в дерево много раз. Круто, очень нужный, во всяком случае мне, функционал. Вот только к какому устройству привязан сервис можно узнать только через cli mysql Да, мы видим только название устройства, но их в дереве 20 штук, к какому именно привязка? Ну хотя бы при открытии списка устройств в режиме редактирования сервиса подсветить текущую привязку нужно.

6) При работе в дереве устройств (inet) после "вставить" дерево сворачивается.

Вот примерно про это я хотел сказать. Что же касается look&feel, то я как раз противник нагруженных веб интерфейсов и swing в этом плане меня более чем устраивает.

P.S. еще нашел записочки

7) Добавление опции в договоре. А что если опций сотни 2-3? Вот этот выпадающий список выбора опции слишком скудный механизм для выбора из большого кол-ва опций. Опции могут быть опциями, а могут быть группой. Я не знаю есть какой то смысл в подключении к сервису группы опций, но как минимум сразу же захотелось научиться скрывать опции, ну что бы "папка" была папкой, а не одной из опций доступной для выбора. А еще хочется определить какие опции допустимы для конкретного типа сервиса, по группам-папкам.

По пункту 4 предыдущего поста полностью согласен.
Манипуляция "растягивать" и "не показывать столбцы" всё равно заставляет изрядно поёрзать мышью, прежде чем в списках инет-сервисов договора удасться увидет id сервиса.

_________________
"Все правые - в резерве!" (c) (translate.google.ru/#en/ru/all%20rigths%20reserved)

Тема немного не об этом. Предлагаю описать о текущих проблемах в соответствующих разделах. Про некоторые пункты впервые слышу.

Коллеги, хотим немного рассказать про наши решения и снять острые вопросы:

Во первых, у нас полная интеграция с BG Биллинг из коробки.

Функциональность NAT реализована с нуля в Firmware Российской компанией (полностью Российская разработка) и не имеет никакого отношения к Linux (если не считать загрузку в определенное место памяти).

По результатам тестов в Ростелекоме - самый высокопроизводительный NAT - это EcoNAT. При этом мы 1U.
Если бы это было китайское поделие - то скорость была бы тоже на уровне Китая (разница - десятки процентов производительности не в пользу Китая).

Мы лучшие в сегменте потому что:
1) Мы более производительные
2) У нас меньшая стоимость на 1GBит данных
3) Нам не страшны DDoS атаки - мы настолько производительны, что способны обработать практически весь трафик.
Там где конкуренты виснут, мы все еще продолжаем успешно натировать. (У нас был случай - у провайдера была железка на тесте, стояла у него на части трафика, и тут случилась DDoS атака, оборудование которое провайдер использовал для NAT легло, провайдер переключил весь свой трафик на EcoNAT, и больше обратно не переключался).
4) У нас быстрая реакция на запросы пользователей.
Разработка наша и разработчики находится в Москве. Поэтому мы можем оперативно дорабатывать функциональность, что невозможно в случае Китайского поделия.
6) Помимо NAT, наше решение поддерживает функции BRAS L3 Service Gateway (ограничение скорости in/out, отключение абонентов, применение к абоненту списков фильтрации) и URL-Filter HTTP/HTTPS (поддержка черных и белых списков, фильтрации Zapret-info, сценарии по удержанию абонентов)

Повторимся: всё это в 1U, работает на скорости проводов.

Готовы ответить на все интересующие вопросы.

А вообще, приезжайте к нам в гости, в Москву, Давыдковcкая З, 1й-блок, 3й-подъезд, 2-й этаж, RDP.ru.
Вы сможете сами все посмотреть.

_________________
ООО «РДП.РУ» - российский разработчик и поставщик высокопроизводительного сетевого оборудования для ядра сети операторов связи и сервис-провайдеров.

-прям песня....



Спрашиваю:
1. - БЖБ управляет устройствами либо по радиусу либо "терминальными" протоколами, каким методом БЖБ управляет Вашим чудо-1U ?
2. - каким боком БЖБ использует сии фичи применительно к конкретному юзеру ?
3. - а это чо такое ?
4. БЖБ с помощью ACCESS-серверов управляет сервисами юзеров на устройствах , а с Accounting-серверов снимает статистику об этих сервисах с этих устройств либо по радиусу, либо по netflow. Каким из этих методов снимается статистика у Вашего решения ?
5. Как у Вас с поддержкой COPМ 3 ?

_________________
"Все правые - в резерве!" (c) (translate.google.ru/#en/ru/all%20rigths%20reserved)

Отвечу на часть вопросов. Не претендую на полную достоверность, могу ошибаться.

Они поддержали наш протокол Manad. Ну и сама железка управляется по ssh/telnet.

Если мы их правильно поняли, то netflow пока эта железка не поддерживает. Биллинг(accounting-сервер) должен обращаться к ним и считывать счетчики. Вроде бы не snmp, какой-то другой протокол. По идее это можно сделать с помощью обработчика управления устройством по аналогии с snmp.

Коллеги, дискуссия ушла чуть в сторону. Хочу поделиться опытом использования EcoNAT более года и сформулировать нашу потребность, как интегратора и оператора. Мне реально нужны Ваши советы.
Факт. Коллеги из RDP сделали по сути универсальный парсер пакетов на проходе трафика, переписали Intel DPDK и у них получилось коммутировать трафик на скорости (та аппаратная база, которая есть сейчас - 3120 ) до 120Гигабит честных, реальных, настоящих в IMIX. Мы это все тестировали и это знаем, если кому интересно - готов поделится тестами и отчетами. Это все работает на 82599/X710 интеловых чипах и Xeon. Само шасси тайваньское - ну что поделать, мы кроме Байкала ничего не умеем делать пока. На этом движке они сделали NAT, сделали URL фильтрацию под ФЗ. Это все хорошо. Мало того, магия в том, что это по сути провод виртуальный и не нужны сложные механизмы резервирования, делаем LAG на 2 коробки и при падении одной, вторая поднимается с какой-то безумной скоростью типа 8м сессий с сек, реально никто не знает с какой - не на чем протестить. В целом полный кайф - резервирование устраивает даже безумные требования по 999999 для телефонии.
Вопрос вот в чем. На этом же движке готов BRAS или точнее сервисный шлюз, так как он ничего про DHCP не знает и сессия поднимается на проходе по первому пакету IP. Прикол в том, что количество одновременных сессий такое же безумное в PUSH модели, и количество новых сессии в секунду сумасшедшее. Все же в памяти все профиля клиентов на том же устройстве, не нужен ни како

й Радиус.
И того, вопрос, как правильно проинтегрирваоть BGB с Сервисным шлюзом чтобы это можно было использовать стандартно? У нас есть заказчики реальные которые готовы эту схему использовать! Ни кому не хочется использовать для тривиальной цели BRAS дорогой Juniper покупать с его 20к сессией одновременных и 20 новых в секунду.
Поможете? Спасибо!

И еще одно замечание, EcoNAT использует для СОРМ2 сейчас SYSLOG или NetFlow v9. Про СОРМ3 слышали только, но вроде его пока никто не использует и вроде его нет пока сертифитированного как продукта=железки? Если я не прав - поправьте, по меньшей мере наши спецслужбы вроде пока нас не трогают и экспорта, того что есть достаточно всем

И того вопрос к форуму, как правильно, стандартно, красиво и хорошо интегрировать BGB? Он вроде как-то частно уже используется стандартно (насколько я слышал), чтобы можно все предлагать Заказчикам и это все будет нормально работать и поддерживаться всеми. Мы как интегратор это решение готовы предлагать стандартно, а заказчики реально есть, сейчас как раз момент (наверное) попробовать уйти от старой схемы с RADIUS PULL моделью на эту, выгоды для Оператора я описал выше.

10 из 10, господи, 10 из 10!

Уважаемые разработчики, выравнивание чисел по правому краю - это прописная истина. Об этом пишут даже в самоучителях работы на компьютере. В самоучителях, Карл!



Принято говорить: "на скорости порта"



Если позиционировать сабж как быструю натилку, а EcoNAT, в первую очередь, именно так и позиционируется, то возникает резонный вопрос: "зачем?". Если это хоть и быстрая, но всего лишь натилка, т.е. она "заворачивает" в какие-то белые адреса какие-то серые адреса, которые уже где-то "приземлили", т.е. осуществили полное взаимодействие с биллингом в части ААА (Авторизации, Аутентификации и Аккаунтинга), то взаимодействие с биллингом не нужно, т.к. оно происходит в других местах и на других железках.

Если позиционировать сабж как некий BNG, который не только натит (ой, не смотрите на NAT в названии, т.к. мы еще многое могем!), а занимается непосредственно ААА процессом ("ограничение скорости in/out, отключение абонентов, применение к абоненту списков фильтрации"(с)), то тогда достаточно просто запилить под EcoNAT, как это было сделано с другим оборудованием, активаторы сервисов и иметь стандартную, красивую и хорошую интеграцию изкаропки.

В общем ... О чем это я? Как вы яхту назовете ... Тьфу! Стоит подумать и правильном позиционировании своего агрегата

А нам эту железку сегодня в тест поставили

_________________
Цитаты великих людей
Напишите в helpdesk © stark
повторяю: => хелпдеск => доработка => профит © dimOn
свершилось... © skn
Мой код изящен, лёгок, оригинален, краток. Как прохладный весенний ветерок, как звонкий ручей! © dimOn
Вежливый разработчик © Artur
Эти баги тоже исправлены, как и те, которые еще не написаны © Artur
ну т.е. существует воркэраунд, ок © dimOn

Там есть одно решение для econat, недавно было обновление .Но до конца еще не внедрили. Пишите в hd.