Перейти к содержимому
Калькуляторы

DPI СКАТ поделитесь опытом

Не так уж много производителей в мире делают к сетевым картам драйвера прямого доступа,

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

что разработчики ntop были более отзывчивыми и нам совместными усилиями

удалось прокачать (по крайней мере ту часть API, которую мы используем в их драйвере - нам там немного и нужно)

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

Когда netmap подтянется до этого уровня, то, почему бы и нет, выпустим версию для freebsd.

 

это линагз с пфрингом

 

Ваша теория не объясняет почему СКАТ по характеристикам превосходит не только linux, но и

"чисто аппаратные" платформы, и почему немаленькие операторы переводят шейпинг на СКАТ :)

На сайте есть список клиентов, которые одобрили размещение их логотипа и ссылки.

Если у вас есть там контакты - можете узнать из первых рук.

 

СКАТ поддерживает дисциплину HTB (иерархический token bucket как в Linux)

 

У HTB красивая концепция: нам понравилось, мы поддержали.

 

А на десктопном железе оно работает? Или, может в виртуальном окружении(гипервизор ESX)?

 

Планируем в скором времени такую версию выпустить. Пока был ориентир на достаточно крупных операторов.

Но много интереса и со стороны университетов - брать с них деньги как-то неловко, собираемся предложить

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

А бизнес-центры и домонеты пока как-то умудряются наскрести $1000 на комп.

Изменено пользователем DimaM

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ваша теория не объясняет почему СКАТ по характеристикам превосходит не только linux, но и

"чисто аппаратные" платформы, и почему немаленькие операторы переводят шейпинг на СКАТ :)

характеристики разные бывают так то. вот по цене да, чемпион. по всему остальному очень спорный вопрос. и вобщем-то затевать здесь спор об очевидных вещах неудачная маркетинговая стратегия, я щитаю. так что давайте сойдемся на том что "своя ниша" на рынке у linux+pfring-based dpi, конечно, есть. а из них победит тот кто предоставит наиболее адекватную "обвязку" этого хозяйства.
У HTB красивая концепция: нам понравилось, мы поддержали.
не надо лукавить. у линагза кроме tc+htb так то нет вариантов. не надо представлять отсутствие выбора как "ваш выбор красивой концепции". что было в коробке с линагзом, то и использовали, - и это не есть плохо, может быть даже хорошо.

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ведь любой кастомер узнает как оно на самом деле

 

в том то и дело, что кастомеров уже немало - есть кому подтвердить или опровергнуть, тут не соврешь

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

"Доступны два механизма на выбор:

1. Ограничение полосы с поддержкой burst в стиле CISCO (классический token bucket)

2. Ограничение полосы с заимствованием в стиле Linux HTB"

Из документации на выбор :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Из документации на выбор :)
из адекватных вариантов, только htb. "классический токен бакет" - бесполезная поебень жи, чо про нее думать ?
Изменено пользователем pfexec

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Из документации на выбор :)
"классический токен бакет" - бесполезная поебень жи, чо про нее думать ?

И в чём же её бесполезность?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Подумайте над virtual appliance с небольшим сроком протухания. Для первоначальных тестов будет вполне достаточно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Не так уж много производителей в мире делают к сетевым картам драйвера прямого доступа,

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

...

netmap http://info.iet.unipi.it/~luigi/netmap/ для этого не подходит?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

virtual appliance с небольшим сроком протухания. Для первоначальных тестов будет вполне достаточно.

 

Полноценная версия с ограничением скорости, например, в 100Мбит лучше подходит в качестве демо версии, IMHO.

Такой вариант позволит на стенде увидеть все плюшки СКАТ-а, ну а ограничение скорости сделает невозможным его применение у 99% операторов.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

netmap http://info.iet.unip.../~luigi/netmap/ для этого не подходит?

 

 

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

Изменено пользователем DVM-Avgoor

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Вранье (или неграмотность).

HFSC, HTB, CBQ из иерархических.

Банальный полисинг, TBF из classless.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

netmap http://info.iet.unip.../~luigi/netmap/ для этого не подходит?

Подумайте над virtual appliance с небольшим сроком протухания

Полноценная версия с ограничением скорости, например, в 100Мбит лучше подходит в качестве демо версии

 

Выше писал уже, что:

1) netmap поддерживаем, только для production он пока не годится

2) планируем бесплатную версию "для университетов", думаю там явного ограничения скорости не будет -

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Приходите на форум и биринг после него, СКАТ будет участвовать:

http://www.comnews-conferences.ru/tds2014

http://beering.ru/e-16/

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Меняем в СКАТ одним махом тариф (ограничение скорости) сразу для 30 тысяч абонентов

(в соседней ветке прочитал, что Cisco этого не переживет):

 

> time fdpi_ctrl load --policing rate_10M.cfg --file subsribers.lst

Result processing file 'subsribers.lst' : 30000/30000/0/0/0

real 0m0.344s

user 0m0.009s

sys 0m0.144s

 

Времени ушло меньше секунды, т.е. можно хоть раз в секунду переключать тарифы всем абонентам :)

 

Еще, для сравнения, подключение (или смена) тарифа для 250000 абонентов:

>time fdpi_ctrl load --policing rate_20M.cfg --file subsribers.lst

Result processing file 'subsribers.lst' : 250000/250000/0/0/0

real 0m1.539s

user 0m0.074s

sys 0m1.189s

 

Чуть дольше :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Жалко что нет ограничения входящего трафика по протоколам.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Жалко что нет ограничения входящего трафика по протоколам.

 

По факту оказалось, что мало кто пользуется ограничениями по протоколам.

Расскажите, как планируете использовать? Если use case интересный, то добавим.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Приходите на форум и биринг после него, СКАТ будет участвовать:

http://www.comnews-conferences.ru/tds2014

http://beering.ru/e-16/

Ктоб ещё напомнил на биринге отловить представителей СКАТа... :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Небольшой отчетец по тестированию:

 

1.С точки зрения DPI "абонент = IP-адрес" и никак иначе. Учтите этот момент.

 

2.Фильтрация по реестру запрещенных сайтов

Фильтрация может осуществляться как одновременно так и раздельно по:

 

- реестру связьнадзора

- своему списку

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

Стоит учитывать что:

 

- при перенаправлении на нашу страницу запрошенный пользователем URL не передается (обещали исправить это в новой версии);

- если заблокированный URL это HTTPS, то перенаправления на нашу страницу не будет в связи с особенностями работы протокола и пользователь увидит только белую страницу;

 

 

Минусы:

- при составлении своего списка нет возможности указывать шаблон. Так с точки зрения данного функционала mail.ru не одно и тоже что www.mail.ru.

- свой список для фильтрации URL`ов невозможно создать на другом сервере, т.к. используются самописные утилиты с закрытым кодом для конвертации текстового файла во внутренний формат.

 

Общий итог - работает хорошо, сразу из коробки.

 

3.Уведомление абонентов

Возможность разово отобразить абоненту свою информационную страницу.

Пользователь обращается на любой URL, выдается информационная страница, после чего более информационная страница не выдается до повторного включения.

При перенаправлении пользователя на информационную страницу передается информация о исходном URL который открывал пользователь. Соответственно можно это использовать для формирования ссылки аля "Для продолжения нажми тут".

 

Минусы:

- отсуствуют

 

4.Блокировка и замена рекламы

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

Данным функционалом можно две вещи:

- замена: например баннера на исходной странице на свой баннер

- блокирование: опять же на примере банера, на исходной странице баннер подменятся пустой.

Как это работает:

- DPI видит обращение пользовательского IP к URL, который совпадает с URL в "списке рекламы".

- DPI обращается к заданному в настройках URL`у добавляя к нему исходно запрошенный URL.

Таким образом существует возможность разработки PHP скрипта, который будет возвращать какие то данные в ответ или возвращать пустоту.

 

Минусы:

- предложить полноценную (в полном смысле слова полноценный) услугу "Блокировка рекламы" невозможно, т.к. для блокировки необходимо самостоятельно составлять список URL`ов для блокирования, а какого то централизованного обновляемого списка не существует.

- при составлении своего списка нет возможности указывать шаблон. Так с точки зрения данного функционала mail.ru не одно и тоже что www.mail.ru.

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

 

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

 

 

5.Белый список

Белый список позволяет ограничить доступные абоненту сайты и страницы и осуществляет переадресацию абонента на заданную страницу при попытке выхода за пределы этого списка.

Есть возможность составить список URL`ов, которые разрешены для посещения. Если URL не входит в список разрешенных пользователя переадресовывает на страницу указанную в конфиге.

 

Минусы:

- при перенаправлении на нашу страницу запрошенный пользователем URL не передается (обещали исправить это в новой версии) что затруднит диагностику при возникновении проблем у юзера, т.к. придется узнавать, а куда же он в итоге ломился;

- при составлении списка разрешенных URL`ов нет возможности указывать шаблон. Так с точки зрения данного функционала mail.ru не одно и тоже что www.mail.ru.

 

- И самый главный минус: Белый список един для всех абонентов. Возможности составлять персональный список для каждого абонента - отсутствует. А значит применение функции не подходит для ISP. Разве что для офисов будет хорошо.

 

6. Шейпирование по протоколам

Существуют возможности:

 

- устанавливать приоритеты для прохождения ИСХОДЯЩЕГО от пользователя трафика по протоколам и ограничивать полосу/запрещать трафик по протоколам;

- ограничивать ОБЩУЮ полосу для ВХОДЯЩЕГО к пользователю трафика;

 

Минусы:

- классификация трафика работает только для ИСХОДЯЩЕГО от пользователя трафика;

 

Штука вероятно хорошая, позволяет выставить приоритет для торрента пониже, для критичных сервисов повыше.

Из за того, что доступно управление только исходящим трафиком - нет возможности полноценно управлять входящим.

На примере торрента - как мы ни крутили приоритеты и зажимали исходящий - в итоге работает 2 варианта - торрент либо заблокирован полностью, либо работает на всю ширину полосы.

При этом сайты визуально открываются быстро, потерь по пингам тоже нет.

 

Однако на современных тарифах (20-30 мбит и выше) - и без DPI поведение у торрента похожее, "трубы" хватает, проблем нет.

 

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

 

6. Статистика по направлениям и протоколам.

-Работает, что то она там показывает, графики рисует.

 

 

Заключение

Весь заявленный на DPI функционал работает.

Для блокировки реестра на мой взгляд решение неплохое.

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

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

Например ограничить полосу для торрента для каждого клиента не выйдет.

 

Возможно использовать железку просто в качестве шейпера с расширенным функционалом.

Но с одним "но" - штатные средства для нормального дебага такого шейпера - отсутствуют.

 

Есть некоторые моменты, которые нужно отметить:

 

- каких либо задержек/падение скорости при скачивании/закачивании через DPI не замечено. Мы нагрузочным тестированием не занимались, но 200-300 мбит он молотит без проблем, без нагрузки на систему вовсе. Увеличение времени пинга тоже не замечено.

 

- при рестарте сервиса на DPI производится сброс всех настроек для IP-адресов клиентов, т.к. у сервиса нет своей внутренней БД хранения настроенных данных

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

для блокировки необходимо самостоятельно составлять список URL`ов для блокирования, а какого то централизованного обновляемого списка не существует

 

https://code.google.com/p/ruadlist/

Если бы в СКАТ была нативная поддержка этого списка (подсмотреть можно в Adblock Plus), то это было бы почти идеальное решение по обрезке рекламы.

 

 

классификация трафика работает только для ИСХОДЯЩЕГО от пользователя трафика

 

Ну и зачем такой DPI нужен, когда основная маса трафика идет в противоположном направлении?

 

 

при рестарте сервиса на DPI производится сброс всех настроек для IP-адресов клиентов, т.к. у сервиса нет своей внутренней БД хранения настроенных данных

 

У SCE есть SM, который следит за связками "юзер = тариф/скорость" и, попутно, еще и квотами заведует. В этом SCE выигрывает чуть более чем полностью.

Без полноценного управления сабскриберами использование СКАТ в качестве шейпера для меня сомнительно, т.к. тупо ограничить трубу я могу и на BRAS-е или еще где, тем же САR.

В качестве резалки списков - да, решение очень хорошее. Пока что не совсем понятен один момент - СКАТ использует для выгрузки свои атрибуты или же ему можно скормить свой ключ/запрос с подписью? Если свой ключ скормить нельзя - скрипач СКАТ не нужен, т.к. россвязьпозор считает скачивания и парит моск своими процентами.

 

 

P.S. Куда подевался Bigmazy?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

СКАТ использует для выгрузки свои атрибуты или же ему можно скормить свой ключ/запрос с подписью?

Ничего скармливать ему не нужно - работает сам.

Для успокоения россвязьнадзора есть 2 варианта:

-просто сливать список со своей подписью пару раз в сутки и ничего с ним не делать. Скрипты есть на этом форуме - рабочие.

- заключить договор с vasexperts, в котором написано что они все делают за вас.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

сливать список со своей подписью пару раз в сутки

 

Это по закону не реже 2-х раз, а в действительности сливание раз в 3 часа приводило к звонкам "у вас процент маленький", после чего я влепил слив списка раз в час но так и не достиг 100%. В погоне за 100% (просто ради прикола) хотел запустить раз в 5 минут, но их инфраструктура стоимостью в пололимпиарда рублей не умеет так быстро отдавать список.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Спасибо Негатору за отзыв, но как обычно бывает, не обошлось без неточностей:

 

1) классификация трафика работает и для исходящего, и для ВХОДЯЩЕГО трафика,

но на входящем трафике нет HTB ( точнее, пока нет :) )

2) основное применение белого списка сейчас, это организация Captive Portal при блокировке абонента по неоплате,

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

что их потом не будет больше

3) DPI при старте/рестарте подхватывает все настройки, сохраненные в нужном каталоге, принцип аналогичен /etc/rc.d/init.d

и интеграция с биллингом или сервером политик ни у кого не вызвала особых затруднений,

но поддержка встроенной БД со временем конечно же будет

 

Система развивается, устраняются недостатки, появляются новые возможности, НО:

 

мы, преимущественно, развиваемся туда, куда в первую очередь интересно нашим ПЛАТНЫМ клиентам. C'est la vie.

Среди них на данный момент, в основном, операторы среднего размера (десятки тыс. абонентов и 10G каналы).

Интересы эти, в первую очередь, направлены на повышение ARPU и QOE, снижение издержек,

и здесь нам есть что предложить (кому интересно подробнее - приходите на форум и beering).

 

После обкатки у клиентов мы переводим функциональность в тиражируемую.

Сейчас, например, готовится к выпуску версия, в которую будет включена функциональность

кэширования, защиты от DDOS атак и поддержка СОРМ-light.

 

Развитие же в обратную сторону (как бы назад, в их прошлое, где еще ощущается конкуренция с SCE)

происходит немножко медленнее, но происходит. Малые и региональные операторы не забыты и

приглашаются присоединяться к проекту. Тем более цены на наш DPI для малых операторов таковы,

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

"Все можно сделать на Linux", но, например, то же кэширование должно их заинтересовать :)

 

И тех. поддержка по цене доступна, поэтому реальных пользователей DPI в этой конфе не видать,

им есть куда всегда обратиться.

 

тупо ограничить трубу я могу и на BRAS-е или еще где

 

как оказалось не совсем так, например, один из клиентов перешел на СКАТ, так как "CISCO не справляется

с шейпингом скоростей выше 50 Мбит/c"

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Что касается остального - мы провели ряд тестов и результат перед Вами. Предлагаю посетителям данного топика сделать выводы об интересах и применяемости системы.

Кроме этого - общее впечатление осталось положительным.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

основное применение белого списка сейчас, это организация Captive Portal при блокировке абонента по неоплате,

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

 

Это ваше видение, а вот чего хочет (правильно хочет, кстати) покупатель:

 

мы рассматривали белые списки только с целью организации "Детского интернета" или похожих услуг

 

Negator прав, сетуя:

 

Белый список един для всех абонентов. Возможности составлять персональный список для каждого абонента - отсутствует. А значит применение функции не подходит для ISP. Разве что для офисов будет хорошо.

 

Т.к. просто walled garden не особо интересен.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

классификация трафика работает только для ИСХОДЯЩЕГО от пользователя трафика

 

Ну и зачем такой DPI нужен, когда основная маса трафика идет в противоположном направлении?

 

P.S. Куда подевался Bigmazy?

 

Привет! Со временем плохо совсем, но периодически читаю.

Хотел сказать спасибо Negator'у за отзыв, нам полезно знать о недостатках, которые мы естественно будем устранять в будущих версиях.

Теперь относительно тестирования, письмом отправил Negator'у пример правил для регулирования/приоритезации входящих торрентов с помощью исходящего трафика, при тестировании это не запрашивали, а в этом случае не все очевидно.

 

Наверное все таки поясню почему регулировать исходящий поток от абонента/общего трафика правильнее чем приоритезировать и ограничивать входящий, допустим есть абонентский ТП 1мбит вх/исх трафика. Если на торрентах предоставить исходящую полосу равную 1мбиту, то входящего трафика торрент мы получим 50-70мбит, а отдать абоненту нужно 1мбит, что делать с остальным трафиком? Дропать - смысла нет, торрент клиент опять запросит тот-же обьем, станет только хуже с точки зрения загрузки внешнего канала, шейпить - появятся задержки, и опять пойдут перезапросы пакетов, + при большом к-ве таких абонентов никаких буферов не хватит, то есть дропы появятся.

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

 

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

Изменено пользователем Bigmazy

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.