[disappointed]

Умник

Хм, у меня 02 очень много, а 00 ну процента 1-2 от них.

[DemYaN]

Под это правило попадут все SYN-пакеты. DROP конечно это жестоко. Можно -j CONNMARK.

 

-A FORWARD -p udp -m state --state NEW -m string --hex-string "|ffffab0204000100|" --algo bm --to 50 -j DROP

и что по ресурсам будет дешевле - смириться с возросшей нагрузкой от больших pps или получить рост нагрузки из-за разбора пакета по string ?

 

[disappointed]

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

 

-A p2p -m udp -p udp -m string --hex-string "|7F FF FF FF AB|" --algo kmp --from 40 --to 44 -m statictic --mode random --probability 0.90 -j DROP

Изменено 23 февраля, 2010 пользователем disappointed

[Умник]

DemYaN, если я все правильно понимаю, то до -m string дойдут только новые UDP пакеты (conntrack видел только одно направление). Проверки на тип протокола и на state в conntrack-е очень нересурсоемкие.

 

[blackjack]

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

Изменено 23 февраля, 2010 пользователем blackjack

[AlKov]

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

 

-A p2p -m udp -p udp -m string --hex-string "|7F FF FF FF AB|" --algo kmp --from 40 --to 44 -m statictic --mode random --probability 0.90 -j DROP

Это всё, конечно, неплохо, но... Как объяснить сиё хомячкам??

 

P.S. Для интересу прописал пример у себя на рутере, при ~70/16 Мбит на аплинке, правило за ~30 сек. застрелило порядка 7 000 пакетов. Причем, по приблизительным оценкам, в данный момент торрент по udp у меня гоняют еще совсем чуть-чуть..

[Kostya.G]

так в том и дело что попап выскочил 25.01 а прирост ППС во второй половине февраля...

http://m.habrahabr.ru/post/82951/

 

Получается, что все-таки 3 февраля.

И вот, 25 явнваря, была выпущена тестовая сборка RC5 (17920), а сегодня, спустя неделю, по причине отсутствия проблем с последним билдом — он перешёл в статус финальной версии.

А мне только сейчас программа предложила обновится. :)

[disappointed]

AlKov

Это всё, конечно, неплохо, но... Как объяснить сиё хомячкам??

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

[witch]

у нас загрузка не выросла...

(высокая загрузка на прошлой неделе это 2 подвисших iperf)

[Умник]

Как объяснить сиё хомячкам??

Вы думаете хомячок будет спрашивать: "Почему у меня не работает uTP?"? Сомневаюсь. В любом случае трафик он не потеряет. По умолчанию в последней версии uTorrent включен как TCP, так и UDP. Так что если не получится соединиться по UDP, трафик побежит по TCP.

 

проги для глухонемых

Простите, что это за проги?

[AlKov]

AlKov

Это всё, конечно, неплохо, но... Как объяснить сиё хомячкам??

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

Гм.. Хотелось бы верить, что так оно и будет. ;) Я все же предполагаю, что поднимется избитая тема про падение скорости. Надо проверять..

Кстати, по причине того, что мы еще "не очень большие" (макс. 550 онлайн и 80Мбит), до вчерашнего дня ни разу не озадачивался кол-вом pps. Мониторинг по pps прицепил только вчера... Поэтому не знаю, а сколько будет "его "много"? Отсюда такой вопрос - 12/8 kpps (in/out) при ~65/16M (in/out) - это как, много, или вообще мелочь?

[ingress]

Простите, что это за проги?

банк-клиенты xD

[make.kernel]

Отсюда такой вопрос - 12/8 kpps (in/out) при ~65/16M (in/out) - это как, много, или вообще мелочь?

Это вообще-то мелочь. Смущать должна разница в 30% между входящим и исходящим ппс. У нас наоборот получилось - входящий ппс остался примерно как и был, исходящий подрос на 20% за неделю, до этого разница была 1-2% - плотненько графики держались, сейчас разъехались. Полок на аплинках нет но cpu idle бордера просел на 10%.

[blackjack]

вчера две девочки приходили в офис.

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

[DIAMONEY]

Короче сделал для теста фокус покус, ограничили UDP порты с 1024 по 65535, скоростью в 256 килобит, и загрузка канала и скорость и пакеты в секунду упала в пополам. В версии uTorrente 1.8.2 скорость закачки не изменилась, в версии 2,0 долгое время не выжимается скорость после "холодного старта" минут через 5 доходит до скорости тарифного пакета (2 мегабита), то есть мимо фильтра а соответственно это пакеты TCP. Если отключить галочку в версии 2.0 "вкл. управление скоростью" - собственно uTP, то скорость сразу доходит до тарифного лимита(2 мегабита), опять же мимо фильтра udp 256 килобит, а соответственно тоже пакеты TCP :)

Вечером при полной нагрузке думаю будет интересне понаблюдать за результатом.

Дальше появились вопросы, для игр 256 килобит будет думаю достаточно, для скайпа-голоса тоже достаточно, а вот какие проги UDP будут требовать полосу более 256 килобит?

Изменено 23 февраля, 2010 пользователем DIAMONEY

[Умник]

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

В 2 раза по Мбит/с? Много что-то. По логике загрузка у вас после установки ограничения должна была вернуться в состояние, когда еще не выпустили uTorrent с uTP включенным.

[goletsa]

А примеры классификации такого трафика для FreeBSD ктонить может набросать? А то тут как я смотрю в основном iptables :(

 

[blackjack]

класификации по каким признакам?

[DIAMONEY]

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

В 2 раза по Мбит/с? Много что-то. По логике загрузка у вас после установки ограничения должна была вернуться в состояние, когда еще не выпустили uTorrent с uTP включенным.

Согласен, я просто рубанул всех кто качал по протоколу uTP, и загрузка упала мгновенно, дальше начала потихоньку расти, пока сильно не выросла, а вот ближе к вечеру все должны вернуться к работе по TCP и увеличить загрузку канала. Это будет уже результат.

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

Изменено 23 февраля, 2010 пользователем DIAMONEY

[AlKov]

AlKov

Это всё, конечно, неплохо, но... Как объяснить сиё хомячкам??

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

Кстати, а Skype эта хитрая конструкция тоже будет "частично дропать"? Если "да", то здесь может получиться "небольшой скандальчик".. :(

Если за работой торрента постоянно наблюдают лишь считанные единицы, и сия уловка для большинства "торретноводов" может безболезненно прокатить, то Skype тут никак не спрячешь..

[Умник]

AlKov, нет. Точнее да, но вероятность, что в голосовом пакете окажутся байты "7F FF FF FF AB", да и еще в нужном месте крайне мала.

 

[zulu_radist]

А примеры классификации такого трафика для FreeBSD ктонить может набросать? А то тут как я смотрю в основном iptables :(

Присоединяюсь, еще на Мтик бы правило

[disappointed]

Кстати, а Skype эта хитрая конструкция тоже будет "частично дропать"?

5 байт в указанном смещении, это вероятность совпадения 1 к 2^40 (1 099 511 627 776)

[AlKov]

AlKov, нет. Точнее да, но вероятность, что в голосовом пакете окажутся байты "7F FF FF FF AB", да и еще в нужном месте крайне мала.

К сожалению, я довольно слабо разбираюсь в характерных особенностях протоколов, поэтому спрошу еще раз - указанная последовательность байтов с указанным смещением в пакете - это явный признак uTP? Судя по Вашему ответу - "нет". Тогда вопрос №2 - это было вычислено эмпирически, или все же есть какое-то "научное" обоснование?

Кстати, за последние пару недель уже выслушал пару жалоб от пользователей Skype, пока отбрёхиваюсь "проблемами у РТК и иже с ними". :) Не хотелось бы совсем обос...ться, добавив еще и свою ложку "дёгтя"... "Скайповоды" в-основном народ серъезный и вполне адекватный, в отличие от торрентщиков, так-что оченно бы не хотелось...

 

P.S. Естественно, ничего не мешает все это быстренько проверить, но вот беда - сам скайпом не пользуюсь и "проверенного клиента", которому можно было бы "шепнуть на ушко" нет..

Может быть кто-нибудь уже проанализировал ситуацию и имеет результаты?

 

P.P.S.

5 байт в указанном смещении, это вероятность совпадения 1 к 2^40 (1 099 511 627 776)

Хорошо, конечно, но.. Всёж голая теория, хочется странного - случаев из практики.. ;)

Изменено 23 февраля, 2010 пользователем AlKov

[disappointed]

Хорошо, конечно, но.. Всёж голая теория, хочется странного - случаев из практики.. ;)

Эта сигнатура находится в payload пакета.

Если даже на 1 099 511 627 776 пакетов один ложно дропнется то думаю голосовому кодеку скайпа от этого плохо не станет. т.к. в условиях глобальной сети вероятность естественного недохода пакета во много сотен/тысяч раз выше чем 1 к 2^40, и всё работает замечательно (ну или почти :) )

Изменено 23 февраля, 2010 пользователем disappointed