wsimons

Решил проблему. Все достаточно логично оказалось. Удалил маршрут 0.0.0.0 через gw провайдера Добавил маршрут 192.168.0.0/16 gw провайдера (локалка провайдера) Ну и два nat masquerade правила, один с аут интерфейсом смотрящим в лолалку провайдера, и второе с аутинтерфейсом pptp.

Решил тут заморочится сРоутерОС 4.11, Настроен dhcp client, dhcp server, pptp client. интерфейсы - inet0 (смотрит в провайдера), local0 (смотрит в мою сеть), vpn (vpn клиент) В Firewall/Nat добавлено правило srcnat - out interface - inet0 - masquerade При такой схеме вижу локалку провайдера, но не вижу интернет. Если в аут интерфейс заменить inet0 на vpn - не видит вообще ничего. Но пингуется адрес который получает роутер по пптп. Есть ощущение, что что-то надо в роуты добавить. Но не уверен.

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

Мне понравилась кинга одна, автор: М. Лукас, "Подробное руководство по FreeBSD", а так, конечно, форумы, друзья:) На ноуте уживутся конечно, это как бут манагер настроете.

По поводу amd64 кстати, CPU ваш естественно должен поддерживать amd64:) А то вдруг старенький зеон какой-нибудь. Да там один диск вам понадобится, порты и все, что нужно возьмете из интернетов:) На 7.3 кажется на двух дисках порты как раз, я не помню, обычно просто использую 1 диск только.

Через spamblock вполне прохолит мониторинг интерфейсов клиентов NG* Но в конфиге спамблока можно указать лишь один интерфейс, а их там ой как много, пока каждого промониторишь - уже выйдет FreeBSD 10.3:)

Да, можно amd64.

Ну так и делаю, видны лишь клиенты с внешними ипами, а те, кто через нат сидят -нет. Вариант с блоком 25 порта вообще не вариант, 1) это дикость и придется прописывать в Ipfw правила для доступа на mail.ru и иже с ними 2) Для теста пробовал блочить и опять-же блочатся прекрасно клиенты с внешним ипом, все кто через NAT спокойно обходят и deny ip from any to any src-port 25:) Скорее всего можно вычленить нужный трафик через нетграф. Но увы, сложно для меня очень. Вот пример вывода скрипта спамблоковского, сначала пишет что дескать "Import done. Total 0, readed 0, added 0, deleted 0 blocks." Затем если подождать выдает вот что: Стертый ип это и есть внешний адрес этого впн сервера.

FreeBSD 7.3 Release. mpd5, ngnat. Клиенты подключаются посредством pptp. Часть с внешними ip, чась нет (за натом) Использую spamblock, но в чем проблема, с внешними ипами все просто, а вот с внутренними не получается. Естественно вижу в адресе источника трафика не адрес выдаваемый клиенту, а внешний адрес сервера. Наверное можно сделать что-то через netgraph, но мало себе представляю как.

Лог радиуса перед падением: Fri Jun 25 11:43:57 2010 : Info: WARNING: Child is hung for request 127706. Fri Jun 25 11:43:57 2010 : Error: Discarding duplicate request from client localhost port 51910 - ID: 203 due to unfinished request 127752 Fri Jun 25 11:43:57 2010 : Info: WARNING: Child is hung for request 127676. Fri Jun 25 11:43:57 2010 : Info: WARNING: Child is hung for request 127703. Fri Jun 25 11:43:57 2010 : Error: Discarding duplicate request from client localhost port 55793 - ID: 237 due to unfinished request 127753 Fri Jun 25 11:43:58 2010 : Error: Discarding duplicate request from client localhost port 50065 - ID: 58 due to unfinished request 127754

ДНС локальный, к радиусу по ипу. По поводу логов пока ответить не могу. Надо глянуть.

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

А оптимизировать эти правила не пробовали ?via ng* in - жрет намного больше чем via inet0 out Для каких целей fwd используете ? Неужели route add отменили ? ;) натить сразу 10/8 в один адрес - круто. Помогает поднять несколько нат и натить каждую /24 в свой белый адрес. 00630 netgraph 23 ip from any to any in via inet0 - тоже красиво. Сквозь это правило проходит ВЕСЬ входящий трафик. Что мешает поменять на 00630 netgraph 23 ip from any to me in via inet0 ? Спасибо за советы. Будем пробывать :)

Это явно в момент минимальной загрузки. Еще не помешает статистика vmstat -z | fgrep NetGraph и vmstat -m | fgrep netgraph На 7.3 стоит попробовать ipfw nat. У ng_netflow уменьшить таймауты, раза в 3. Да это минимальная загрузка vmstat -z | fgrep NetGraph NetGraph items: 72, 4140, 77, 688, 7424225660, 0 NetGraph data items: 72, 540, 1, 539, 18526492846, 6884988 vmstat -m | fgrep netgraph netgraph_msg 0 0K - 15395909 64,128,256,512,1024,2048,4096 netgraph_node 1347 337K - 101560 256 netgraph_hook 3230 404K - 188458 128 netgraph 1056 3417K - 62764 16,32,64,256,512,1024,4096 netgraph_bpf 1608 201K - 66704 128 netgraph_iface 156 20K - 4778 128 netgraph_ksock 157 20K - 14885 128 netgraph_parse 0 0K - 16 16,64 netgraph_ppp 156 1872K - 4778 netgraph_sock 4 1K - 29956 128 netgraph_path 0 0K - 7860441 16,32 netgraph_mppc 0 0K - 1 1024 попробуем на одной ipfw nat результаты отпишу.

используется ng_nat, трафик заворачиваем через ipfwна нетграфе крутится только нат и подсчет трафика, ограничение через mpd ng_car 00230 netgraph 5 ip from ххх.ххх.ххх.0/23 to any via ng* in 00330 fwd ххх.ххх.ххх.ххх ip from ххх.ххх.ххх.0/23 to not ххх.ххх.ххх.0/23 00430 netgraph 1 ip from 10.0.0.0/8 to any via ng* in 00530 fwd ххх.ххх.ххх.ххх ip from ххх.ххх.ххх.ххх to not ххх.ххх.ххх.0/23 00630 netgraph 23 ip from any to any in via inet0 00730 allow ip from any to any /usr/sbin/ngctl -f- <<-SEQ mkpeer ipfw: netflow 1 iface0 name ipfw:1 netflow mkpeer netflow: split out0 in name netflow:out0 split1 mkpeer netflow: ksocket export inet/dgram/udp msg netflow:export connect inet/$ngnat_export connect split1: netflow: out iface1 connect ipfw: netflow: 4 out1 mkpeer split1: nat mixed out name split1:mixed nat1 connect ipfw: nat1: 23 in connect ipfw: netflow: 5 iface2 connect ipfw: netflow: 6 out2 msg nat1: setaliasaddr $ngnat_aliasaddr msg netflow: setdlt { iface=0 dlt=12 } msg netflow: setifindex { iface=0 index=1000 } msg netflow: setdlt { iface=1 dlt=12 } msg netflow: setifindex { iface=1 index=1001 } msg netflow: setdlt { iface=2 dlt=12 } msg netflow: setifindex { iface=2 index=1002 } SEQ There are 15 total types: Type name Number of living nodes --------- ---------------------- mppc 0 socket 5 iface 122 car 210 bpf 105 vjc 0 tee 122 tcpmss 122 split 1 netflow 1 pptpgre 122 ppp 122 nat 1 ksocket 123 ipfw 1 Ну слава богу что я не один такой, только вот там о 1500-2000 сессиях пишут, а у нас такое бывает даже при 50-100, а бывает больше 400 и ничего страшного не происходит.

UTP мне непонятно вы хотите показать как у вас все замечательно, _longhorn_ вы рассказываете как работает процесс swi1. А я хочу узнать почему загружается ng_queue на одном ядре на 100%, когда на остальных ядрах нет превышения 5%. И это на двух одинаковых машинах. Кстати на одной родные дрова em и polling, на другой яндек дрова. Если не знаете что ответить не надо заниматся флудом. Если я себе поставлю машину 2015г выпуска, то у меня вопрос отпадет сам по себе. Но мне непонятно, почему здесь на форуме пишут, что у них по 400 пользователей на серваке при этом 700Kpps и более, 600-700Мбит занятого канала. Просто какая то сказка. Или интернет стали раздавать без ограничений? Ну как не стремился раздать побольше, но при колличестве хомяков в 1400 больше 300 Мбит канал не поднимался. При всем этом никто не жалуется, что скорость зажимается. Проблему конечно решаем, но неправильно, точнее не решение проблеммы. Вместо того, чтобы всех держала 1 машина, держит 4.

Насчет яндексов у Вас вообще, как я понимаю, свой взгляд на Мир. У всех они работают прекрасно, а Вам не угодили. Если у других все хорошо стоит поискать проблему у себя. На счет яндекс дров у меня понимание такое же как и у всех. Только не стоит говорить за всех, что они везде работают прекрасно. Советую вам на форумах почитать как они работают у многих. У вас нат на нем работает? Думаю что нет. Иначе показания бы ng_queue были бы далеко не 0%.Ну мне до сих пор никто здесь не объяснил, что я делаю не так, что этот процесс грузит время от времени одно ядро на 100%, остальные все свободные. Точнее предложения были, но они проблему не решили.

Он работает со всеми ядрами, но не параллельно, а по очереди. Так очредность - это что одно ядро?В freebsd почти все процессы так и работают и не только в freebsd кстати с яндекс дровами этот процесс работает точно так же. яндекс дрова его не распараллеливает. конечно же там принцип другой по передаче прерываний, но он не решает проблем с ng, а вот поллинг эти проблемы решает превосходно, распределяя нагрузку ядер равномерно. У вас, простите, в голове каша. Яндексовые дрова параллелятся по нескольким процам, и занимаются обработкой прерываний от сетевушки, передавая пакеты в сетевой стек. swi:net - это внутренний обработчик пакетов чуть более высокого уровня, который работает при net.isr.direct=0. С яндексовскими дровами это дело не дружит. Причем на семерке - swi:net - один процесс, в восьмерке оно уже тоже распараллелено. Именно это я и описываю. Только вот яндекс дрова некоректно распределяют нагрузку в SMPНо несколькими постами выше было описано (не мной), что поллинг работает на одном ядре. Вот это я опровергаю, а не то что как работает данный процесс.

Он работает со всеми ядрами, но не параллельно, а по очереди. Так очредность - это что одно ядро?В freebsd почти все процессы так и работают и не только в freebsd кстати с яндекс дровами этот процесс работает точно так же. яндекс дрова его не распараллеливает. конечно же там принцип другой по передаче прерываний, но он не решает проблем с ng, а вот поллинг эти проблемы решает превосходно, распределяя нагрузку ядер равномерно.

Я смотрю, и вижу, что у вас вся сетевая подсистема работает на одном ядре. А что видите Вы? Не путайте процесс с работой SMP.Я вот вижу совсем другое Вы видете один процесс, но не видете, что он работает со всеми ядрами, а не с одним. 15 root 1 -44 - 0K 16K CPU2 2 27.5H 42.24% swi1: net 15 root 1 -44 - 0K 16K CPU3 3 27.5H 46.39% swi1: net 15 root 1 -44 - 0K 16K CPU0 0 27.5H 47.56% swi1: net и т.д. кстати сейчас нагрузка на этом сервере: более 400 клиентов, более 35kpps на одной сетевухе в каждую сторону и более 200Мбит так же в каждую сторону. на яндекс дровах без полинга больше 20kpps не наблюдали и тем более сейчас еще раз повторюсь нет проблем с повышением пинга более чем в 5мс и падения pps

Какая разница как включается поллинг? Хоть через сисктл, хоть через ифконфиг, всеравно он использует только одно ядро. Если планируете нагружать этот комп, я бы посоветовал задуматься уже сейчас, чтобы не кусать локти потом. Так в том то и дело два одинаковых сервака если вы читали выше с яндекс дровами грузил одно ядро при нагрузке до 100%и кусали локти именно тогда, когда канал падал раз в 10 и пинги выростали до 200-600мс. с полингом и родными дровами при нагрузке все ядра распределяются равномерно и никаких тормозов нет уже 4-й день. И не понятно откуда вы берете что поллинг работает с одним ядром? Вы хоть смотрите top -PS ?

Могу только посоветовать по-больше читать, на этом форуме все уже давно разжевано. Значит еще раз разжую.Этот процесс отвечает за прерывания сетевух. Поллинг принимает эти прерывания и когда освобождается одно из ядер, передает этот процесс ядру Если вы заметите, то этот процесс передает не одному ядру, а тому которое на данный момен свободное. По поводу других жеваний, вижу только одно: попробывал не пошло, буду ждать когда другие попробуют. Полинг работае в SMP уже с 5 версии, до этого он через sysctl запускался, теперь через ifconfig. Просто информацию надо читать посвежей. Если я не прав, поправьте.

15 root 1 -44 - 0K 16K WAIT 2 264:09 28.86% swi1: net А вы хоть в курсе за что отвечает этот процесс и где этот процесс показывает, что полинг работает на одном ядре?

Вопрос стоял не о прерываниях, а о некоректной работе полинга на SMP.обоснуйте именно это. С дровами от яндекса прерываний конечно на много меньше, только результат плачевный с загрузкой одного ядра до 100% ng_queue. Складывается впечатление, чо яндекс дрова слишком перехваливают. В яндексе я думаю не писали эти дрова для ISP в цепочке ng + nat, а для своих веб серверов, которые ничего не натят и не ограничивают. При работе с полингом таких проблем нет. В итоге работает одно ядро. Поздравляю. Укажите на одно ядро. че то не очень этого вижу.

Ну дык мы разговаривали и о поллинге а не о прерываниях, в итоге-то работает:)