forum.bitel.ru :: Просмотр темы

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

лично по мне не вижу смысла, надо на ipv6 лезть. Кто не успел занатится уже железка не спасет

видимо будет как ЭДО, вещь может и хорошая но пока что ни кому не нужна

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

4. Меню вообще кривое - крестики закрытия окон внизу. © Saab95

Почему вы не хотите навести немного лоска в GUI, дописать локализацию и не выйти на другие рынки?

И еще документацию немного доработать:

Jimson писал(а):

лоска в GUI

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

Карбон 5-я версия неудобная в работе, т.к. вся на вебе. © Saab95

Карбон 5-я версия неудобная в работе, т.к. вся на вебе.

Странно.... Нет, я ни в коем случае не намекал на 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? Вот этот выпадающий список выбора опции слишком скудный механизм для выбора из большого кол-ва опций. Опции могут быть опциями, а могут быть группой. Я не знаю есть какой то смысл в подключении к сервису группы опций, но как минимум сразу же захотелось научиться скрывать опции, ну что бы "папка" была папкой, а не одной из опций доступной для выбора. А еще хочется определить какие опции допустимы для конкретного типа сервиса, по группам-папкам.

Мы лучшие в сегменте потому что:
1)Мы более ...
2)У нас меньшая ...
3)Нам не страшны ....
4)У нас быстрая ....

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

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

поддержка черных и белых списков, фильтрации Zapret-info

сценарии по удержанию абонентов

Цитата:

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

- БЖБ управляет устройствами либо по радиусу либо "терминальными" протоколами, каким методом БЖБ управляет Вашим чудо-1U ?

4. БЖБ с помощью ACCESS-серверов управляет сервисами юзеров на устройствах , а с Accounting-серверов снимает статистику об этих сервисах с этих устройств либо по радиусу, либо по netflow. Каким из этих методов снимается статистика у Вашего решения ?

Числовые данные все же надо выравнивать по правому краю. Если переключится на мегабайты/гигабайты, то данные вообще будут с десятичной точкой, и при выравнивании по левому краю разобрать что то сложновато.

всё это в 1U, работает на скорости проводов

как правильно, стандартно, красиво и хорошо интегрировать BGB?

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

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

Автор:	zavndw [ 14 окт 2015, 19:14 ]
Заголовок сообщения:	Re: EcoNAT
а причем тут биллинг?

Автор:	skn [ 14 окт 2015, 19:16 ]
Заголовок сообщения:	Re: EcoNAT
zavndw писал(а): а причем тут биллинг? хотят сделать интеграцию с этой железкой из коробки. (на самом деле они кроме разработки софта для железа, еще и сами провайдеры и используют эту железку в связке с BGBilling)

Автор:	zavndw [ 14 окт 2015, 19:26 ]
Заголовок сообщения:	Re: EcoNAT
лично по мне не вижу смысла, надо на ipv6 лезть. Кто не успел занатится уже железка не спасет видимо будет как ЭДО, вещь может и хорошая но пока что ни кому не нужна

Автор:	skn [ 14 окт 2015, 19:43 ]
Заголовок сообщения:	Re: EcoNAT
zavndw писал(а): лично по мне не вижу смысла, надо на ipv6 лезть. Кто не успел занатится уже железка не спасет видимо будет как ЭДО, вещь может и хорошая но пока что ни кому не нужна ну NAT, то не единственное, что умеет железка, еще шейпер и URL фильтр кроме того ipv6 надо, что бы был не только у вас, а еще и у всех остальных в мире, иначе пользы от него не много...

forum.bitel.ru http://forum.bitel.ru/

EcoNAT http://forum.bitel.ru/viewtopic.php?f=44&t=10987	Страница 1 из 2

Автор:	Jimson [ 14 окт 2015, 23:18 ]
Заголовок сообщения:	Re: EcoNAT
Обычно за подобными российскими разработками скрывается китайское поделие + маркетинговый булшит + желание нагреться на модном нынче тренде "импортозамещения" (влезть в какой-нибудь государственный заказ). Прежде чем что то рассуждать про это "решение", его нужно подержать в руках, а лучше попытаться пристроить для реальной задачи. Даже если они писали софт сами, то логично предположить что там банальный линукс внутри и, внезапно, набор костылей для iptables. Я, конечно, могу ошибаться, всегда есть исключения из правил. Подобного железа на рынке достаточно много, например, тот же Allot. Ну и всегда остается старая добрая cisco 7200, которая запросто будет и натить и шейпить и фильтровать url-ы. Кстати, на счет последнего, могу опубликовать свой тулкит: серверная часть N2H2 протокола, качатель списков роскомцензуры, diff для этих списков, и немного не дописанный портал (на который собственно идут редиректы и который должен генерировать страничку с извинениями и дополнительной информацией).

Автор:	skn [ 15 окт 2015, 03:01 ]
Заголовок сообщения:	Re: EcoNAT
Jimson писал(а): Обычно за подобными российскими разработками скрывается китайское поделие + маркетинговый булшит + желание нагреться на модном нынче тренде "импортозамещения" (влезть в какой-нибудь государственный заказ). Прежде чем что то рассуждать про это "решение", его нужно подержать в руках, а лучше попытаться пристроить для реальной задачи. Даже если они писали софт сами, то логично предположить что там банальный линукс внутри и, внезапно, набор костылей для iptables. Я, конечно, могу ошибаться, всегда есть исключения из правил. Со слов представителей разработчиков, железо там действительно азиатское(тайвань) и софт который они разрабатывают. Там вроде как действительно линух, но с их слов линух используется только в качестве загрузчика их специализированного кода (как я понял они не используют ни стандартные драйвера и фильтры пакетов) который реализуют всю логику чуть ли ни на уровне железа (пишут на C). По сравнению с цисками и другими решениями от других вендоров, говорят, что их решение значительно дешевле и производительней. Кстати обещают оперативно дорабатывать прошивку под требования клиентов.

Автор:	Jimson [ 15 окт 2015, 13:55 ]
Заголовок сообщения:	Re: EcoNAT
Тема больше из плоскости "бител думает на тему расширения области применения", разработка комплексных решений не худший вариант, но у меня в таком случае есть вопрос. Почему вы не хотите навести немного лоска в GUI, дописать локализацию и не выйти на другие рынки? В той же канаде или в sea регионе не найдется толпа средних операторов, которые были бы рады вашим продуктам?

Автор:	Phricker [ 15 окт 2015, 14:05 ]
Заголовок сообщения:	Re: EcoNAT
Jimson писал(а): лоска в GUI Web интерфейс? ) Цитата: 4. Меню вообще кривое - крестики закрытия окон внизу. © Saab95

Автор:	Tau [ 15 окт 2015, 14:36 ]
Заголовок сообщения:	Re: EcoNAT
Jimson писал(а): Почему вы не хотите навести немного лоска в GUI, дописать локализацию и не выйти на другие рынки? Вообще да, на GUI было бы недурно натравить UX/UI разработчика. И еще документацию немного доработать: для продукта, ориентированного на рынок с разным техническим уровнем потребителя (где-то директор и монтажник, и сисадмин, и биллингист, а где-то на биллинг выделено несколько специально обученных сотрудников), документация все-таки должна быть помягче...

Автор:	ok-2004 [ 15 окт 2015, 15:41 ]
Заголовок сообщения:	Re: EcoNAT
Цитата: И еще документацию немного доработать: БЖБ развивается так быстро , что дока за ним не успевает. Это нормально, у других не лучше. Как говаривал в своё время автор iproute2 - хотите "просветления" - читайте "сырцы".....

Автор:	Phricker [ 15 окт 2015, 15:46 ]
Заголовок сообщения:	Re: EcoNAT
Tau писал(а): ... И FAQ обязателен

Автор:	Amir [ 15 окт 2015, 15:53 ]
Заголовок сообщения:	Re: EcoNAT
Phricker писал(а): Jimson писал(а): лоска в GUI Web интерфейс? ) Цитата: Карбон 5-я версия неудобная в работе, т.к. вся на вебе. © Saab95

Автор:	ok-2004 [ 15 окт 2015, 16:00 ]
Заголовок сообщения:	Re: EcoNAT
Цитата: Карбон 5-я версия неудобная в работе, т.к. вся на вебе. если весь контент в Нотепаде верстать , то наверное таки да. Без персонажей типа Saab95 жизнь была-бы скучна ....

Автор:	skn [ 15 окт 2015, 19:56 ]
Заголовок сообщения:	Re: EcoNAT
А какие проблемы с GUI? Мы как то пробовали менять, так сразу некоторые клиенты ворчать начинают, типа наши операторы привыкли, ни чего не трогайте, операторы в ступор впадают...

Автор:	ok-2004 [ 16 окт 2015, 11:08 ]
Заголовок сообщения:	Re: EcoNAT
По пункту 4 предыдущего поста полностью согласен. Манипуляция "растягивать" и "не показывать столбцы" всё равно заставляет изрядно поёрзать мышью, прежде чем в списках инет-сервисов договора удасться увидет id сервиса.

Автор:	РДП.РУ [ 21 окт 2015, 14:59 ]
Заголовок сообщения:	Re: EcoNAT
Коллеги, хотим немного рассказать про наши решения и снять острые вопросы: Во первых, у нас полная интеграция с 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. Вы сможете сами все посмотреть.

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

Автор:	zavndw [ 15 окт 2015, 16:11 ]
Заголовок сообщения:	Re: EcoNAT
так вот карбон не надо упоминать в суе я как его слышу меня типает всего

Автор:	zavndw [ 15 окт 2015, 20:11 ]
Заголовок сообщения:	Re: EcoNAT
с GUI все отлично, надо bgcrm пилить

Автор:	Jimson [ 15 окт 2015, 22:07 ]
Заголовок сообщения:	Re: EcoNAT
Странно.... Нет, я ни в коем случае не намекал на 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? Вот этот выпадающий список выбора опции слишком скудный механизм для выбора из большого кол-ва опций. Опции могут быть опциями, а могут быть группой. Я не знаю есть какой то смысл в подключении к сервису группы опций, но как минимум сразу же захотелось научиться скрывать опции, ну что бы "папка" была папкой, а не одной из опций доступной для выбора. А еще хочется определить какие опции допустимы для конкретного типа сервиса, по группам-папкам.

Автор:	stark [ 16 окт 2015, 12:56 ]
Заголовок сообщения:	Re: EcoNAT
Jimson писал(а): Странно.... Нет, я ни в коем случае не намекал на 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? Вот этот выпадающий список выбора опции слишком скудный механизм для выбора из большого кол-ва опций. Опции могут быть опциями, а могут быть группой. Я не знаю есть какой то смысл в подключении к сервису группы опций, но как минимум сразу же захотелось научиться скрывать опции, ну что бы "папка" была папкой, а не одной из опций доступной для выбора. А еще хочется определить какие опции допустимы для конкретного типа сервиса, по группам-папкам. Тема немного не об этом. Предлагаю описать о текущих проблемах в соответствующих разделах. Про некоторые пункты впервые слышу.

Автор:	ok-2004 [ 21 окт 2015, 15:45 ]
Заголовок сообщения:	Re: EcoNAT
Цитата: Мы лучшие в сегменте потому что: 1)Мы более ... 2)У нас меньшая ... 3)Нам не страшны .... 4)У нас быстрая .... -прям песня.... Цитата: Готовы ответить на все интересующие вопросы. Спрашиваю: 1. Цитата: у нас полная интеграция с BG Биллинг из коробки. - БЖБ управляет устройствами либо по радиусу либо "терминальными" протоколами, каким методом БЖБ управляет Вашим чудо-1U ? 2. Цитата: поддержка черных и белых списков, фильтрации Zapret-info - каким боком БЖБ использует сии фичи применительно к конкретному юзеру ? 3. Цитата: сценарии по удержанию абонентов - а это чо такое ? 4. БЖБ с помощью ACCESS-серверов управляет сервисами юзеров на устройствах , а с Accounting-серверов снимает статистику об этих сервисах с этих устройств либо по радиусу, либо по netflow. Каким из этих методов снимается статистика у Вашего решения ? 5. Как у Вас с поддержкой COPМ 3 ?

Автор:	stark [ 21 окт 2015, 18:19 ]
Заголовок сообщения:	Re: EcoNAT
Отвечу на часть вопросов. Не претендую на полную достоверность, могу ошибаться. ok-2004 писал(а): 1. Цитата: у нас полная интеграция с BG Биллинг из коробки. - БЖБ управляет устройствами либо по радиусу либо "терминальными" протоколами, каким методом БЖБ управляет Вашим чудо-1U ? Они поддержали наш протокол Manad. Ну и сама железка управляется по ssh/telnet. ok-2004 писал(а): 4. БЖБ с помощью ACCESS-серверов управляет сервисами юзеров на устройствах , а с Accounting-серверов снимает статистику об этих сервисах с этих устройств либо по радиусу, либо по netflow. Каким из этих методов снимается статистика у Вашего решения ? Если мы их правильно поняли, то netflow пока эта железка не поддерживает. Биллинг(accounting-сервер) должен обращаться к ним и считывать счетчики. Вроде бы не snmp, какой-то другой протокол. По идее это можно сделать с помощью обработчика управления устройством по аналогии с snmp.

Автор:	vleonov [ 21 окт 2015, 22:42 ]
Заголовок сообщения:	Re: EcoNAT
й Радиус. И того, вопрос, как правильно проинтегрирваоть BGB с Сервисным шлюзом чтобы это можно было использовать стандартно? У нас есть заказчики реальные которые готовы эту схему использовать! Ни кому не хочется использовать для тривиальной цели BRAS дорогой Juniper покупать с его 20к сессией одновременных и 20 новых в секунду. Поможете? Спасибо!

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

Автор:	vleonov [ 21 окт 2015, 22:56 ]
Заголовок сообщения:	Re: EcoNAT
И того вопрос к форуму, как правильно, стандартно, красиво и хорошо интегрировать BGB? Он вроде как-то частно уже используется стандартно (насколько я слышал), чтобы можно все предлагать Заказчикам и это все будет нормально работать и поддерживаться всеми. Мы как интегратор это решение готовы предлагать стандартно, а заказчики реально есть, сейчас как раз момент (наверное) попробовать уйти от старой схемы с RADIUS PULL моделью на эту, выгоды для Оператора я описал выше.

Автор:	snark [ 21 ноя 2015, 21:30 ]
Заголовок сообщения:	Re: EcoNAT
Jimson писал(а): Числовые данные все же надо выравнивать по правому краю. Если переключится на мегабайты/гигабайты, то данные вообще будут с десятичной точкой, и при выравнивании по левому краю разобрать что то сложновато. 10 из 10, господи, 10 из 10! Уважаемые разработчики, выравнивание чисел по правому краю - это прописная истина. Об этом пишут даже в самоучителях работы на компьютере. В самоучителях, Карл! РДП.РУ писал(а): всё это в 1U, работает на скорости проводов Принято говорить: "на скорости порта" vleonov писал(а): как правильно, стандартно, красиво и хорошо интегрировать BGB? Если позиционировать сабж как быструю натилку, а EcoNAT, в первую очередь, именно так и позиционируется, то возникает резонный вопрос: "зачем?". Если это хоть и быстрая, но всего лишь натилка, т.е. она "заворачивает" в какие-то белые адреса какие-то серые адреса, которые уже где-то "приземлили", т.е. осуществили полное взаимодействие с биллингом в части ААА (Авторизации, Аутентификации и Аккаунтинга), то взаимодействие с биллингом не нужно, т.к. оно происходит в других местах и на других железках. Если позиционировать сабж как некий BNG, который не только натит (ой, не смотрите на NAT в названии, т.к. мы еще многое могем!), а занимается непосредственно ААА процессом ("ограничение скорости in/out, отключение абонентов, применение к абоненту списков фильтрации"(с)), то тогда достаточно просто запилить под EcoNAT, как это было сделано с другим оборудованием, активаторы сервисов и иметь стандартную, красивую и хорошую интеграцию изкаропки. В общем ... О чем это я? Как вы яхту назовете ... Тьфу! Стоит подумать и правильном позиционировании своего агрегата

Автор:	Phricker [ 02 фев 2016, 06:42 ]
Заголовок сообщения:	Re: EcoNAT
А нам эту железку сегодня в тест поставили

Автор:	stark [ 03 фев 2016, 16:00 ]
Заголовок сообщения:	Re: EcoNAT
Phricker писал(а): А нам эту железку сегодня в тест поставили Там есть одно решение для econat, недавно было обновление .Но до конца еще не внедрили. Пишите в hd.

Страница 1 из 2	Часовой пояс: UTC + 5 часов [ Летнее время ]
Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/