XeonVs Опубликовано 11 марта, 2010 · Жалоба если я использую на сервере pf, то как мне это прикрутить?Пересобрать модуль(/sys/modules/ipfw) ipfw c прописанным в /etc/make.conf CFLAGS+= -DIPFIREWALL_DEFAULT_TO_ACCEPT и потом уже штатно: kldload ipfw kldload ng_ipfw kldload .... порядок работы будет зависеть от порядка загрузки модулей фаерволов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Zohan Опубликовано 11 марта, 2010 · Жалоба если я использую на сервере pf, то как мне это прикрутить?Пересобрать модуль(/sys/modules/ipfw) ipfw c прописанным в /etc/make.conf CFLAGS+= -DIPFIREWALL_DEFAULT_TO_ACCEPT и потом уже штатно: kldload ipfw kldload ng_ipfw kldload .... порядок работы будет зависеть от порядка загрузки модулей фаерволов. можно в /usr/src/sys/modules/ipfw/Makefile? потом make && make install? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ghost Опубликовано 11 марта, 2010 · Жалоба Почитав кое-что из этой ветки задался вопросом - как отслеживать подобные тенденции вцелом? Помыслив, пришел к выводу что в первом приближении для выявления тенденции достаточно нарисовать график "средний размер пакета", т.к. статистика bps и pps имеется в наличии, то построил график за месяц (bps/8)/pps, и получил... что средний размер пакета на входе инетовского канала как был примерно 700 байт - так и остался, явного треда нет (по крайней мере на моих аплинках), есть некоторое уменьшение исходящих пакетов с 250 до 225 байт, с чем связяно - не знаю. это конечно охоже на "среднюю температуру по больнице", но ключевые тенденции должны при таком подходе проявляться, особенно при резких изменениях. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
XeonVs Опубликовано 11 марта, 2010 · Жалоба если я использую на сервере pf, то как мне это прикрутить?Пересобрать модуль(/sys/modules/ipfw) ipfw c прописанным в /etc/make.conf CFLAGS+= -DIPFIREWALL_DEFAULT_TO_ACCEPT и потом уже штатно: kldload ipfw kldload ng_ipfw kldload .... порядок работы будет зависеть от порядка загрузки модулей фаерволов. можно в /usr/src/sys/modules/ipfw/Makefile? потом make && make install? можно и так, но при cvsup потрётся.остальное верно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Zohan Опубликовано 11 марта, 2010 · Жалоба если я использую на сервере pf, то как мне это прикрутить?Пересобрать модуль(/sys/modules/ipfw) ipfw c прописанным в /etc/make.conf CFLAGS+= -DIPFIREWALL_DEFAULT_TO_ACCEPT и потом уже штатно: kldload ipfw kldload ng_ipfw kldload .... порядок работы будет зависеть от порядка загрузки модулей фаерволов. можно в /usr/src/sys/modules/ipfw/Makefile? потом make && make install? можно и так, но при cvsup потрётся.остальное верно. Хм, такой фильтр не работает Работает такой: /usr/sbin/ngctl -f- <<-SEQ mkpeer ipfw: bpf 61 ipfw_hook61 name ipfw:61 bpf_utp_filter mkpeer bpf_utp_filter: tag matched tag_utp name bpf_utp_filter:matched tag_utp_tagger SEQ ngctl msg bpf_utp_filter: setprogram { thisHook=\"ipfw_hook61\" ifNotMatch=\"ipfw_hook61\" ifMatch=\"matched\" bpf_prog_len=12 bpf_prog=[ { code=48 jt=0 jf=0 k=0 } { code=84 jt=0 jf=0 k=240 } { code=21 jt=0 jf=8 k=64 } { code=48 jt=0 jf=0 k=9 } { code=21 jt=0 jf=6 k=17 } { code=40 jt=0 jf=0 k=6 } { code=69 jt=4 jf=0 k=8191 } { code=177 jt=0 jf=0 k=0 } { code=64 jt=0 jf=0 k=20 } { code=21 jt=0 jf=1 k=2147483647 } { code=6 jt=0 jf=0 k=65535 } { code=6 jt=0 jf=0 k=0 } ] } ngctl msg bpf_utp_filter: setprogram { thisHook=\"matched\" ifMatch=\"ipfw_hook61\" bpf_prog_len=1 bpf_prog=[ { code=6 jt=0 jf=0 k=96 } ] } ngctl msg tag_utp_tagger: sethookin { thisHook=\"tag_utp\" ifNotMatch=\"tag_utp\" } ngctl msg tag_utp_tagger: sethookout { thisHook=\"tag_utp\" tag_cookie=1148380143 tag_id=61 } ipfw add netgraph 61 udp from any to any iplen 0-61 ipfw add deny udp from any to any tagged 0-61 и обязательно: sysctl net.inet.ip.fw.one_pass=0 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
emp Опубликовано 11 марта, 2010 · Жалоба Кто-нить уже начал? Я не в курсе. Вообще, во фре уже давно имеется отлтчный встроеный механизм защиты от ICMP флуда (настраивается через sysctl net.inet.icmp.icmplim), поэтому рискну предположить, что такую фичу совершенно не сложно нарисовать на уровне ядра применительно, например, к всему ip либо отдельно tcp/icmp/udp и т.д траффику не прибегая к будующим возможностям IPFW. Хотя такой способ, несмотря на скорость работы значительно уступает настраиваемым правилам по гибкости. net.inet.icmp.icmplim не влияет на транзитный трафик Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
thefree Опубликовано 12 марта, 2010 · Жалоба _http://lists.freebsd.org/pipermail/freebsd-ipfw/2003-April/000074.html Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Taras Опубликовано 12 марта, 2010 (изменено) · Жалоба Почитав кое-что из этой ветки задался вопросом - как отслеживать подобные тенденции вцелом?Помыслив, пришел к выводу что в первом приближении для выявления тенденции достаточно нарисовать график "средний размер пакета", т.к. статистика bps и pps имеется в наличии, то построил график за месяц (bps/8)/pps, и получил... что средний размер пакета на входе инетовского канала как был примерно 700 байт - так и остался, явного треда нет (по крайней мере на моих аплинках), есть некоторое уменьшение исходящих пакетов с 250 до 225 байт, с чем связяно - не знаю. это конечно охоже на "среднюю температуру по больнице", но ключевые тенденции должны при таком подходе проявляться, особенно при резких изменениях. А тут как раз заметно введение фильтации: и pps снизился и bpp вырос, при возросшем! трафике. А то что изменения произошли плавно объясняется тем, что включение фильтра не рубит уже качающиеся торренты. Изменено 12 марта, 2010 пользователем Taras Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
XeonVs Опубликовано 12 марта, 2010 · Жалоба А тут как раз заметно введение фильтации: и pps снизился и bpp вырос, при возросшем! трафике. а чем с циски снимали bpp? или это уже по готовому netflow? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Taras Опубликовано 12 марта, 2010 · Жалоба А тут как раз заметно введение фильтации: и pps снизился и bpp вырос, при возросшем! трафике.а чем с циски снимали bpp? или это уже по готовому netflow? bps/pps Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
valeps Опубликовано 16 марта, 2010 (изменено) · Жалоба Народ у меня cisco 7507 бордером, можно что нибуть для нее посоветовать, как зарезать этот долбаный uTP????? Изменено 16 марта, 2010 пользователем valeps Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
woody Опубликовано 16 марта, 2010 · Жалоба Чтоб, в конце-то концов, хомячковый роутер перестал виснуть от pps. До тех пор, пока хомяк не рубанет uTP у себя - его мыльница будет вешаться, ведь траф рубится на коммутаторах/серверах. Кстати,возник резонный вопрос: а что вообще происходит с uTorrent, когда он понимает, что через uTP установить связь не получается? Как долго он продолжает бомбежку пакетами, затыкается ли? Если затыкается, надолго ли? Возможность проверить есть, но никак не дойдут руки :) Может кто ставил эксперименты? воистину ваша правда. bt.transp.disposition=5 и жизнь вернулась Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
MaDDoG Опубликовано 17 марта, 2010 · Жалоба вчера проверил class-map type access-control match-any Torrent match start l3-start offset 40 size 5 regex "\x7F\xFF\xFF\xFF\xAB" policy-map type access-control Torrent class Torrent drop interface GigabitEthernet0/0 service-policy type access-control input Torrent помогло Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DrakoN Опубликовано 18 марта, 2010 · Жалоба Зарезал на сервере доступа: iptables -A FORWARD -p udp -m length --length 61 -m string --hex-string "|7F FF FF FF|" --algo kmp --from 40 --to 44 -j DROP В результате загрузка CPU на бордере в пике уменьшилась с 56% до 36% при том же bandwidth, и сможем ввести новые тарифные планы без боязни потерять в качестве или количестве обслуживаемых клиентов. Посмотрел заодно, откуда идёт uTP-трафик: корбилайн не режет, сибирь не режет, казахстан и прибалтика тоже. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Дегтярев Илья Опубликовано 18 марта, 2010 · Жалоба корбилайн не режет, сибирь не режетКрупняк фигней не страдает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Nic Опубликовано 18 марта, 2010 · Жалоба Дегтярев Илья, крупняк просто тормозит, да и не в курсе скорее всего... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Pretender Опубликовано 18 марта, 2010 (изменено) · Жалоба Зарезал на сервере доступа: iptables -A FORWARD -p udp -m length --length 61 -m string --hex-string "|7F FF FF FF|" --algo kmp --from 40 --to 44 -j DROP В результате загрузка CPU на бордере в пике уменьшилась с 56% до 36% при том же bandwidth, и сможем ввести новые тарифные планы без боязни потерять в качестве или количестве обслуживаемых клиентов. Посмотрел заодно, откуда идёт uTP-трафик: корбилайн не режет, сибирь не режет, казахстан и прибалтика тоже. может --algo kmp --from 40 --to _43_ коль правило порезали? Изменено 18 марта, 2010 пользователем Pretender Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DpakoH Опубликовано 18 марта, 2010 (изменено) · Жалоба может --algo kmp --from 40 --to _43_ коль правило порезали? Да хоть --to 41, это указывается промежуток начала подстроки. Изменено 18 марта, 2010 пользователем DpakoH Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
wsimons Опубликовано 18 марта, 2010 (изменено) · Жалоба Хм, такой фильтр не работаетРаботает такой: /usr/sbin/ngctl -f- <<-SEQ mkpeer ipfw: bpf 61 ipfw_hook61 name ipfw:61 bpf_utp_filter mkpeer bpf_utp_filter: tag matched tag_utp name bpf_utp_filter:matched tag_utp_tagger SEQ ngctl msg bpf_utp_filter: setprogram { thisHook=\"ipfw_hook61\" ifNotMatch=\"ipfw_hook61\" ifMatch=\"matched\" bpf_prog_len=12 bpf_prog=[ { code=48 jt=0 jf=0 k=0 } { code=84 jt=0 jf=0 k=240 } { code=21 jt=0 jf=8 k=64 } { code=48 jt=0 jf=0 k=9 } { code=21 jt=0 jf=6 k=17 } { code=40 jt=0 jf=0 k=6 } { code=69 jt=4 jf=0 k=8191 } { code=177 jt=0 jf=0 k=0 } { code=64 jt=0 jf=0 k=20 } { code=21 jt=0 jf=1 k=2147483647 } { code=6 jt=0 jf=0 k=65535 } { code=6 jt=0 jf=0 k=0 } ] } ngctl msg bpf_utp_filter: setprogram { thisHook=\"matched\" ifMatch=\"ipfw_hook61\" bpf_prog_len=1 bpf_prog=[ { code=6 jt=0 jf=0 k=96 } ] } ngctl msg tag_utp_tagger: sethookin { thisHook=\"tag_utp\" ifNotMatch=\"tag_utp\" } ngctl msg tag_utp_tagger: sethookout { thisHook=\"tag_utp\" tag_cookie=1148380143 tag_id=61 } ipfw add netgraph 61 udp from any to any iplen 0-61 ipfw add deny udp from any to any tagged 0-61 и обязательно: sysctl net.inet.ip.fw.one_pass=0 А как стату с него снять? Изменено 18 марта, 2010 пользователем wsimons Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
wsimons Опубликовано 18 марта, 2010 · Жалоба И еще вопросик, как вообще выявить тех самых клиентов, с активно работающим uTP? (на FreeBSD шлюзе). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
XeonVs Опубликовано 18 марта, 2010 (изменено) · Жалоба И еще вопросик, как вообще выявить тех самых клиентов, с активно работающим uTP? (на FreeBSD шлюзе).tcpdump -Xni vlan0 "ip[40:4]=0x7FFFFFFF and ip[44:1]=0xAB" статистика снимается примерно так: ngctl msg bpf_utp_filter: getstats \"matched\" Изменено 18 марта, 2010 пользователем XeonVs Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
wsimons Опубликовано 18 марта, 2010 · Жалоба Спасибо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Mallorn Опубликовано 23 марта, 2010 (изменено) · Жалоба Зарезал на сервере доступа: iptables -A FORWARD -p udp -m length --length 61 -m string --hex-string "|7F FF FF FF|" --algo kmp --from 40 --to 44 -j DROP В результате загрузка CPU на бордере в пике уменьшилась с 56% до 36% при том же bandwidth, и сможем ввести новые тарифные планы без боязни потерять в качестве или количестве обслуживаемых клиентов. Посмотрел заодно, откуда идёт uTP-трафик: корбилайн не режет, сибирь не режет, казахстан и прибалтика тоже. Сибирь и Казахстан не режут по причине более низких kbps на абонента и, как следствие, меньшего числа качальщиков. Сегодня проверил на своем шлюзе - порядка 10-50 pps с харакетерным "7ffffffab", хотя это не час пик был. Добавил правило "по рецепту", дропы пакетов пошли. Через сутки покажу результаты. PS.Кстати, есть подозрение, что линуховый шейпер tc пропускает мелкие пакеты, не видя их вовсе. Изменено 23 марта, 2010 пользователем Mallorn Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
A1z Опубликовано 23 марта, 2010 · Жалоба ещё в начале месяца, включая в торренте bt.transp_disposition в значение 15(оно по умолчанию, сам выставляю в 5) можно было наблюдать десяток, на сотню качальщиков, с буковками uTP. сейчас-же их совсем мало. PS.Кстати, есть подозрение, что линуховый шейпер tc пропускает мелкие пакеты, не видя их вовсе.можно подробнее? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
YuryD Опубликовано 23 марта, 2010 · Жалоба И еще вопросик, как вообще выявить тех самых клиентов, с активно работающим uTP? (на FreeBSD шлюзе).tcpdump -Xni vlan0 "ip[40:4]=0x7FFFFFFF and ip[44:1]=0xAB" статистика снимается примерно так: ngctl msg bpf_utp_filter: getstats \"matched\" Включил, режется примерно 10% от udp iplen 0-61 про приведенным сигнатурам 65200 1978856 104679041 netgraph 61 udp from any to any iplen 0-61 65300 264668 16144748 deny udp from any to any tagged 0-61 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...