[Bigmazy]

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

- идентифицирует и классифицирует трафик

- собирает учетную информацию

- управляет трафиком

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

Полисинг зависит от конфигурации.

Не жалуются.

 

В реальном трафике http очень мало, при выше указанных характеристиках фильтрация не заметна для процов.

Возникает 2 вопроса

Что вы считаете http?

В каких единицах этого http мало?

 

Http определяется на L7, независимо от порта и т.п.

http исх ~1.5%, http входящий ~15% от всего трафика.

[Ivan_83]

А как ваша софтина работает во время добавления/удаления урл?

На долго стопорится обработка?

[Bigmazy]

2Alex/AT: Pf_ring - да, используем.

Ага, тогда всё встаёт на места, спасибо. Железка получается чистый сквозной L2-фильтр/классификатор, без каких-либо сетевых операций над потоком выше 2 уровня, кроме собственно процесса классификации.

Поверьте, до l7, иначе большую часть полезных протоколов не определить, p2p, Skype и т.п.

 

Про 100Крублей конечно загнули, но на железке стоимостью под 200-300К осилить через PF_RING 10-20 Гбит и 2-3 Mpps с классификацией вполне реально.

Ранее показывал график, пробного запуска, бюджетной конфигурации до 100К, но мы пока с ней работаем т.к. 9.5 mpps считаем не достаточным показателем.

 

Еще один вопрос: таблицу состояний как-то поддерживаете? Или классификация потоков исключительно на базе L4 src/dst IP+port?

Вопрос не праздный: два последовательных потока TCP (SYN-ACK-SYNACK-data-FIN/RST/timeout) на одной той же комбинации IP/портов оно как-то различает?

Да.

Нет, до l7, UDP потоки торрентов объединяем.

Да, различает.

[Bigmazy]

А как ваша софтина работает во время добавления/удаления урл?

На долго стопорится обработка?

 

Не влияет на обработку это никаким образом.

[Alex/AT]

Поверьте, до l7, иначе большую часть полезных протоколов не определить, p2p, Skype и т.п.

Я немножко не о том. Инспекция вашей железкой ведется - понятное дело, до L7. Однако пропускание трафика, если я все верно понимаю, выше L2 не работает - т.е. пакет принимается, анализируется, ну и благополучно выкидывается на соседний интерфейс, если всё ОК. В разных случаях назад может послаться RST, или просто пакет дропнуться, или там маркер QoS подмениться - но никакой комплексной обработки и маршрутизации трафика не делается - он принимается и пробрасывается (или не пробрасывается, или пробрасывается с минимальными изменениями) на соседний порт.

[pers123]

 

В реальном трафике http очень мало, при выше указанных характеристиках фильтрация не заметна для процов.

Возникает 2 вопроса

Что вы считаете http?

В каких единицах этого http мало?

 

Http определяется на L7, независимо от порта и т.п.

http исх ~1.5%, http входящий ~15% от всего трафика.

Тьфу на вас! Вам же уже подсказали, что интересно

http CPS

http requests/sec

 

Судя по приведенным вами процентам при классификации вы много http-based протоколов и приложений относите в другие классы.

Flash_up/Flash_down из ваших графиков это http 200 OK content-type: video/x-flv?

В таком случае повторю свой вопрос - что система считает http или что вы считаете таковым?

Как система работает с HTTP 1.1, SPDY, Websockets?

[pers123]

Поверьте, до l7, иначе большую часть полезных протоколов не определить, p2p, Skype и т.п.

Я немножко не о том. Инспекция вашей железкой ведется - понятное дело, до L7. Однако пропускание трафика, если я все верно понимаю, выше L2 не работает - т.е. пакет принимается, анализируется, ну и благополучно выкидывается на соседний интерфейс, если всё ОК. В разных случаях назад может послаться RST, или просто пакет дропнуться, или там маркер QoS подмениться - но никакой комплексной обработки и маршрутизации трафика не делается - он принимается и пробрасывается (или не пробрасывается, или пробрасывается с минимальными изменениями) на соседний порт.

DPI в общем случае не является маршрутизатором или коммутатором, порты, как правило, сгруппированы в пары образующие каналы, internal/external interface.

Для смежного оборудования DPI - кусок кабеля, но интеллектуальный.

Уже писал где-то, что в отличие от всех пакетных устройств, с количеством портов более 2, DPI не является congestion point,

а при определенных матрицах трафика любое пакетное устройство (switch, router) будет буферизировать пакеты и дропать их достаточно бесконтрольно.

DPI не является congestion point и приоретизирует, queue-ит, shape-ит и дропает пакеты исключительно в соответствии с заданными правилами.

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

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

Изменено 16 июня, 2013 пользователем pers123

[snark]

в отличие от всех пакетных устройств, с количеством портов более 2, DPI не является congestion point

 

SCE 2020 не может переварить 4Г суммарного трафика - это вписывается в Вашу парадигму?

[pers123]

в отличие от всех пакетных устройств, с количеством портов более 2, DPI не является congestion point

 

SCE 2020 не может переварить 4Г суммарного трафика - это вписывается в Вашу парадигму?

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

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

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

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

[snark]

Если SCE не использовать по прямому назначению, т.е. как DPI железо - она возможно и пропустит заявленные производителем 4Гбит/с, но без DPI это слишком дорогая оптическая розетка.

[Дятел]

дык производитель и не обещает 2Г

[pers123]

Если SCE не использовать по прямому назначению, т.е. как DPI железо - она возможно и пропустит заявленные производителем 4Гбит/с, но без DPI это слишком дорогая оптическая розетка.

Согласно данным производителя 4Gbps это максимальный Throughput, вполне возможно,

что применямый ruleset просаживает CPU в 90-100% утилизации.

Во всяком случае у вас есть ожидания от DPI, которым SCE не удовлетворяет.

Ну так это не единственное устройство на рынке. Только для того, чтобы осознанный выбор сделать

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

На чем конкретно из ваших задач засыпается SCE и при каких условиях?

Вон Bigmazy предлагает на пару месяцев свое устройство на пробу и по его словам 4Gbps ему вполне по силам.

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

Изменено 17 июня, 2013 пользователем pers123

[snark]

На чем конкретно из ваших задач засыпается SCE и при каких условиях?

 

Если бы SCE 2020 просаживалась только у меня ... Достаточно тут поискать и найдете множество упоминаний про отсутствие заявленной производительности.

 

 

Bigmazy предлагает на пару месяцев свое устройство на пробу

 

Я с ним общался - очень приятный во всех отношениях человек, но их решение нам не подходит именно в силу своей софтовости (начальник хочет hardware only).

[Bigmazy]

Поверьте, до l7, иначе большую часть полезных протоколов не определить, p2p, Skype и т.п.

Я немножко не о том. Инспекция вашей железкой ведется - понятное дело, до L7. Однако пропускание трафика, если я все верно понимаю, выше L2 не работает - т.е. пакет принимается, анализируется, ну и благополучно выкидывается на соседний интерфейс, если всё ОК. В разных случаях назад может послаться RST, или просто пакет дропнуться, или там маркер QoS подмениться - но никакой комплексной обработки и маршрутизации трафика не делается - он принимается и пробрасывается (или не пробрасывается, или пробрасывается с минимальными изменениями) на соседний порт.

Анализ трафика не комплексная обоаботка? Не всегда можно формардить и дропать трафик, пример, перенаправление на другой хост, поддержка внешнего КЭШа, html 1.1 и т.п.

[Bigmazy]

http CPS

http requests/sec

 

Судя по приведенным вами процентам при классификации вы много http-based протоколов и приложений относите в другие классы.

Flash_up/Flash_down из ваших графиков это http 200 OK content-type: video/x-flv?

В таком случае повторю свой вопрос - что система считает http или что вы считаете таковым?

Как система работает с HTTP 1.1, SPDY, Websockets?

 

Req/sec 2 млн запр./сек (было ранее)

 

Http все, что по стандарту, минус видео потоки, то что маскируется под http и т.п. (перечислить не буду).

 

Http 1.1 - обрабатывает, соответственно например 2-й запрос на запрещенный url не пропустит.

 

Spdy - 443 ssl туннель, сейчас учитывает как https. Без ssl пока не видели использования.

 

Websockets - учитывает в http, в дальнейшем можно будет выделить в субкласс пользователю.

[nuclearcat]

Bigmazy - а как у вас обстоит дело с фрагментацией? Т.е. если половина Host: в одном пакете, а половина в другом? :)

[Bigmazy]

Bigmazy - а как у вас обстоит дело с фрагментацией? Т.е. если половина Host: в одном пакете, а половина в другом? :)

Это типовая ситуация для dpi, когда распознавание протокола или осуществление проверки не возможно с первого пакета, для этого в продукте отслеживаются потоки/сессии.

Соответсвенно все корректно отработает.

[nuclearcat]

Если это правда - тогда цифры весьма впечатляют. Очень интересно будет услышать результаты реального тестрования от форумчан.

[GateKeeper]

http://lenta.ru/news/2013/06/18/ligafilter/

[Sergey Gilfanov]

Прокси? Фактически, публичный? Чего-то я в этом образе мыслей не понимаю.

[Ivan_83]

http://lenta.ru/news.../18/ligafilter/

Нужно фильтровать все религии, нефик детям мозг засорять.

Я бы ребёнку заюзал этот сервис, но для меня актуальнее чтобы оно вычищало все вирусованные и подозрительные андройд приложения и шнягу с ютуба: первое засоряет консоль второе безвозвратно затягивает ребёнка :)

[onlime_user]

Я потестил его.

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

 

Ну для ребенка лет до 10 сойдет.

 

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

Изменено 19 июня, 2013 пользователем onlime_user

[Sergey Gilfanov]

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

Они что с https(ну, те с CONNECT) делают?

[onlime_user]

Ну https пока не фильтруют, но я думаю к конечной версии "доработают".

[Sergey Gilfanov]

Вот бы знать, как. Если блочить весь ssl, то на нормальных сервисах авторизация работать не будет. Если устраивать man-in-the-middle для ssl просто так - вопли браузеров будут.

Для избавления от воплей надо либо сертификат собственного CA в браузер поставить, либо у существующего выбить универсальный для

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