supermultik

Прошел почти месц с момента как закрыл порт 6881 полет нормальный, проблема не повторялась.

У меня тоже были подозрения на торенты. Когда снифирил входящий трафик было очень много соединений на этот порт как раз. Сейчас попробовал закрыть, посмотрим как пойдет. А что за сборка библиотеки libalias?

Вот в очередной раз ситуация повторилась root@firewall-2:/usr/home/Multik # netstat -mb 8573/263437/272010 mbufs in use (current/cache/total) 8451/262659/271110/524288 mbuf clusters in use (current/cache/total/max) 8451/262648 mbuf+clusters out of packet secondary zone in use (current/cache) 0/104/104/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 19110K/591593K/610704K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines NetGraph data items: 72, 262160, 674, 261486,62733990280,39958556, 36 но на этот раз все не умерло а через некоторое время очухалось. распределение нагрузки по ядрам вроде нормальное last pid: 48472; load averages: 2.65, 2.34, 2.16 up 11+23:34:07 22:03:19 130 processes: 6 running, 97 sleeping, 27 waiting CPU 0: 0.0% user, 0.0% nice, 13.8% system, 37.9% interrupt, 48.3% idle CPU 1: 0.0% user, 0.0% nice, 27.6% system, 17.2% interrupt, 55.2% idle CPU 2: 0.0% user, 0.0% nice, 27.6% system, 17.2% interrupt, 55.2% idle CPU 3: 0.0% user, 0.0% nice, 31.0% system, 17.2% interrupt, 51.7% idle Mem: 784M Active, 312M Inact, 1765M Wired, 973M Buf, 5028M Free Swap: 10G Total, 10G Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 155 ki31 0K 64K CPU3 3 224.2H 58.89% idle{idle: cpu3} 11 root 155 ki31 0K 64K RUN 1 224.5H 58.25% idle{idle: cpu1} 11 root 155 ki31 0K 64K RUN 2 224.4H 54.79% idle{idle: cpu2} 11 root 155 ki31 0K 64K CPU0 0 216.8H 51.17% idle{idle: cpu0} 12 root -72 - 0K 432K WAIT 2 39.5H 25.59% intr{swi1: netisr 0} 13 root -16 - 0K 64K sleep 1 21.3H 23.39% ng_queue{ng_queue2} 13 root -16 - 0K 64K sleep 3 22.2H 22.56% ng_queue{ng_queue1} 13 root -16 - 0K 64K sleep 2 21.3H 22.36% ng_queue{ng_queue3} 13 root -16 - 0K 64K CPU2 2 21.7H 21.97% ng_queue{ng_queue0} 12 root -92 - 0K 432K WAIT 3 19.0H 13.28% intr{irq259: igb0:que} 12 root -92 - 0K 432K WAIT 1 18.9H 12.79% intr{irq257: igb0:que} 12 root -92 - 0K 432K WAIT 0 19.7H 10.79% intr{irq256: igb0:que} 12 root -92 - 0K 432K WAIT 2 19.0H 10.50% intr{irq258: igb0:que} 12 root -92 - 0K 432K WAIT 0 890:13 7.76% intr{irq261: igb1:que} 12 root -92 - 0K 432K WAIT 1 422:17 3.17% intr{irq262: igb1:que} 12 root -92 - 0K 432K WAIT 2 423:43 2.78% intr{irq263: igb1:que} 12 root -92 - 0K 432K WAIT 3 427:36 2.20% intr{irq264: igb1:que} 12 root -60 - 0K 432K WAIT 0 286:15 0.88% intr{swi4: clock} 4342 bind 20 0 814M 764M uwait 2 15:02 0.29% named{named} 4342 bind 20 0 814M 764M uwait 3 15:00 0.29% named{named} 4342 bind 20 0 814M 764M uwait 3 14:58 0.29% named{named} 4342 bind 20 0 814M 764M uwait 2 15:01 0.20% named{named}

собственно вот начинается процесс умирания всего поднялся пинг от пользователей чере нат начало расти заполнение буфера NetGraph data items: 72, 262160, 2448, 4106,2757945007, 0, 0 NetGraph data items: 72, 262160, 2529, 4025,2760913074, 0, 0 но пока ошибок еще нет и про отсутствие памяти не пишет root@firewall-2:/usr/home/Multik # netstat -m 9541/6209/15750 mbufs in use (current/cache/total) 9533/5321/14854/524288 mbuf clusters in use (current/cache/total/max) 9533/5315 mbuf+clusters out of packet secondary zone in use (current/cache) 0/77/77/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 21557K/12502K/34059K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines динамика такая root@firewall-2:/usr/home/Multik # netstat -m 10701/5049/15750 mbufs in use (current/cache/total) 10693/4161/14854/524288 mbuf clusters in use (current/cache/total/max) 10693/4155 mbuf+clusters out of packet secondary zone in use (current/cache) 0/77/77/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 24225K/9892K/34117K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines Переключил пользователей на другого провайдера, без перезагрузки сервера, просто нат завернул на другой ИП все нормализовалось.

я уже крутил эти параметры немного net.graph.maxdgram=724248 net.graph.recvspace=724248 kern.ipc.maxsockbuf=23175936 никакого эффекта не дает. netstat -m вышлю как проблема повторится

Добрый день. Имеются сходные симптомы ng_queue грузит ядро на 100% ping: sendto: Cannot allocate memory NetGraph data items fails Накрутка net.graph.maxdata=262144 net.graph.maxalloc=262144 ничего не дает в каой то момент все равно происходит переполнение. NetGraph data items: 72, 262160, 262147, 13,52086227,1246688, 0 root@firewall-2:/usr/home/Multik # top -HS last pid: 18557; load averages: 1.55, 1.41, 1.55 up 23+14:57:53 22:05:50 139 processes: 6 running, 106 sleeping, 27 waiting CPU: 0.4% user, 0.0% nice, 23.2% system, 8.0% interrupt, 68.5% idle Mem: 918M Active, 437M Inact, 817M Wired, 827M Buf, 5717M Free Swap: 10G Total, 10G Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 13 root -16 - 0K 64K CPU3 3 49.5H 100.00% ng_queue{ng_qu 11 root 155 ki31 0K 64K RUN 3 431.2H 75.39% idle{idle: cpu3 11 root 155 ki31 0K 64K CPU2 2 431.1H 73.19% idle{idle: cpu2 11 root 155 ki31 0K 64K RUN 0 433.4H 68.36% idle{idle: cpu0 11 root 155 ki31 0K 64K CPU1 1 431.5H 67.09% idle{idle: cpu1 12 root -92 - 0K 432K WAIT 0 34.4H 3.86% intr{irq261: ig 12 root -92 - 0K 432K WAIT 3 39.1H 3.47% intr{irq259: ig 12 root -92 - 0K 432K WAIT 0 39.3H 3.27% intr{irq256: ig 12 root -92 - 0K 432K WAIT 1 39.4H 2.69% intr{irq257: ig 12 root -92 - 0K 432K WAIT 2 39.1H 2.29% intr{irq258: ig 12 root -92 - 0K 432K WAIT 2 34.2H 2.20% intr{irq263: ig 12 root -92 - 0K 432K WAIT 3 33.7H 1.76% intr{irq264: ig 12 root -92 - 0K 432K WAIT 1 34.1H 1.17% intr{irq262: ig 13 root -16 - 0K 64K sleep 0 49.0H 0.78% ng_queue{ng_que 13 root -16 - 0K 64K sleep 1 48.7H 0.68% ng_queue{ng_que 13 root -16 - 0K 64K sleep 2 49.9H 0.49% ng_queue{ng_que Присем данная проблема возникает на 2х машинах на одной 9.0 на второй 9.2 обе машины обновлялись с 8.2 и там была эта же проблема. К разным машинкам подключены 2а разных канала от 2х не зависимых провайдеров. работают как нат+шейпер От нагрузки возникновение проблемы не зависит, иногда это бывает в моменты близкие к пикам 150k pps иногда это вообще не серьезная нагрузка вида 50k pps Перезагрузка сервера помогает не на долго, минут через 10 проблема снова возникает, потом сама собой проходит.

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

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

то что я нашел основано на сигнатурах соединения, как это адаптировать ума не приложу, искать сигнатуры объявления порта для отдачи? в общем ничего такого я не нашел.

примеры видел с перекрытием полностью торрентов

В общем ясно :) . по существу вопроса никто ничего не предложит судя по всему.

Определенные раздачи закрывать конечно не наш уровень но может быть все раздачи закрыть возможно все таки?

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

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

Приветствую всех. В свете борьбы за лицензионный софт, правообладатель парамаунт выслал нашему провайдеру письмо с требованием закрыть раздачу. Провайдер спустил письмо нам с требованием устранить проблему, иначе они прикроют ИП. Кроме того столкнулся с проблемой нового протокола торентов uTP. Хочу по максимум закрыть раздачу торентов из сети но при этом не трогать возможность скачивания. Были б линуха сделал бы через IPP2P, кто сталкивался с такой задачей во FreeBSD с ipfw? Посоветуйте что нибудь.