ex-transfer Posted September 27, 2010 Posted September 27, 2010 (edited) Уважаемые ГУРУ! Долго бьюсь с проблемой, читал много тем с форума и инета, не могу победить свой сервачок: Стоит две сетевушки em0 (alias vlan700) и em1 (alias vlan250) На vlan700 - транспорт до всех 3750, на vlan250 - куча реальных адресов/32 маске (алиасами) - транспорт на бордер Задача сервера: шейпинг и НАТ для небольшого количества трафика (около 120 Мбит) Все клиенты терминируются на 3750, предоставляется влан-на-абонента (opt82, dhcp-snooping). На сервер долетают пакеты с серыми адресами, попадают в НАТ, и режутся altq. При включенном net.isr.direct=1 возникает # netstat -w1 -i vlan250 input (Total) output packets errs bytes packets errs bytes colls 9971 242 5081867 9385 0 5042877 0 9906 197 5141062 9237 0 5120116 0 9837 161 4993819 9042 0 4976199 0 10107 419 5337893 9334 0 5291947 0 9809 223 4874975 9165 0 4874842 0 9854 310 5190356 9036 0 5076692 0 9868 177 5270392 9192 0 5171840 0 9646 272 4920796 8871 0 4879827 0 У юзеров тормозят странички web конечно ЖУТКО. При net.isr.direct=0 Пакеты не выпадают: # netstat -w1 -i vlan250 input (Total) output packets errs bytes packets errs bytes colls 12887 0 5156078 12058 0 5408769 0 12709 0 5135044 12014 0 5260029 0 12640 0 5214073 11876 0 5294148 0 12466 0 5166291 11604 0 5114483 0 12675 0 5223386 12075 0 5583122 0 12728 0 5379418 11923 0 5396520 0 12865 0 5499945 12081 0 5491322 0 Но появляются кошмарные задержки пакетов, проходящих через шейпер, даже если пинговать собственный интнрфейс: # ping 10.11.10.49 PING 10.11.10.49 (10.11.10.49): 56 data bytes 64 bytes from 10.11.10.49: icmp_seq=0 ttl=64 time=473.065 ms 64 bytes from 10.11.10.49: icmp_seq=1 ttl=64 time=445.350 ms 64 bytes from 10.11.10.49: icmp_seq=2 ttl=64 time=465.794 ms 64 bytes from 10.11.10.49: icmp_seq=3 ttl=64 time=474.941 ms Вот кусочек конфига для трех клиентов: set skip on lo0 set block-policy return set optimization normal set limit { states 300000, frags 600000 } set limit table-entries 600000 altq on vlan700 cbq bandwidth 10240000Kb queue { inqueue } altq on vlan250 cbq bandwidth 10240000Kb queue { inqueue } queue inqueue bandwidth 100% cbq(default) {\ user1, \ user2, \ user3 \ } queue user1 bandwidth 2048Kb queue user2 bandwidth 2048Kb queue user3 bandwidth 1024Kb nat on vlan250 inet from { 172.16.16.0/23, 172.16.18.0/23 } to any -> realIP/28 source-hash pass quick from 172.16.20.4 to any queue user1 pass quick from any to 172.16.20.4 queue user1 pass quick from 172.16.20.3 to any queue user2 pass quick from any to 172.16.20.3 queue user2 pass quick from 172.16.8.40 to any queue user3 pass quick from any to 172.16.8.40 queue user3 Нагрузка на проц с net.isr.direct=0: last pid: 1288; load averages: 0.48, 0.84, 0.69 114 processes: 6 running, 87 sleeping, 21 waiting CPU 0: 3.7% user, 0.0% nice, 12.4% system, 0.0% interrupt, 83.9% idle CPU 1: 2.6% user, 0.0% nice, 3.4% system, 39.6% interrupt, 54.3% idle CPU 2: 0.0% user, 0.0% nice, 0.0% system, 98.1% interrupt, 1.9% idle CPU 3: 0.7% user, 0.0% nice, 10.5% system, 0.0% interrupt, 88.8% idle Mem: 25M Active, 12M Inact, 144M Wired, 504K Cache, 30M Buf, 1791M Free Swap: 4096M Total, 4096M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 12 root -44 - 0K 352K CPU2 2 62:50 94.92% {swi1: netisr 0} 11 root 171 ki31 0K 64K RUN 0 56:05 93.41% {idle: cpu0} 11 root 171 ki31 0K 64K CPU3 3 54:01 90.87% {idle: cpu3} 11 root 171 ki31 0K 64K CPU1 1 57:25 56.10% {idle: cpu1} 886 nobody 48 0 8016K 3680K select 0 7:45 7.81% softflowd 0 root -68 0 0K 128K - 0 10:37 5.52% {em1 taskq} 884 nobody 47 0 8016K 3608K select 1 4:21 4.88% softflowd 11 root 171 ki31 0K 64K RUN 2 11:12 2.29% {idle: cpu2} 12 root -32 - 0K 352K WAIT 1 5:57 0.10% {swi4: clock} 0 root -68 0 0K 128K - 3 17:20 0.00% {em0 taskq} 12 root -68 - 0K 352K WAIT 1 1:34 0.00% {irq258: bge0} 13 root -16 - 0K 16K - 1 0:09 0.00% yarrow 7 root 44 - 0K 16K pftm 1 0:07 0.00% pfpurge 578 root 44 0 14736K 4556K select 1 0:03 0.00% ospfd 689 root 44 0 24308K 6360K select 0 0:03 0.00% snmpd 983 root 44 0 17708K 5820K wait 1 0:02 0.00% mc 966 ex 44 0 45280K 6300K select 1 0:01 0.00% sshd 412 _pflogd 44 0 7080K 1716K bpf 3 0:01 0.00% pflogd 12 root -32 - 0K 352K WAIT 0 0:00 0.00% {swi4: clock} 3 root -8 - 0K 16K - 1 0:00 0.00% g_up 2 root -8 - 0K 16K - 0 0:00 0.00% g_event 4 root -8 - 0K 16K - 3 0:00 0.00% g_down 12 root -32 - 0K 352K WAIT 0 0:00 0.00% {swi4: clock} 18 root 44 - 0K 16K syncer 0 0:00 0.00% syncer 601 root 44 0 5864K 1500K select 1 0:00 0.00% syslogd 12 root -32 - 0K 352K WAIT 0 0:00 0.00% {swi4: clock} 21 root 44 - 0K 16K flowcl 3 0:00 0.00% flowcleaner 14 root -64 - 0K 512K - 0 0:00 0.00% {usbus4} 14 root -64 - 0K 512K - 3 0:00 0.00% {usbus7} 14 root -64 - 0K 512K - 0 0:00 0.00% {usbus3} 14 root -64 - 0K 512K - 0 0:00 0.00% {usbus0} 14 root -64 - 0K 512K - 0 0:00 0.00% {usbus5} 14 root -64 - 0K 512K - 0 0:00 0.00% {usbus6} 12 root -64 - 0K 352K WAIT 0 0:00 0.00% {irq14: ata0} 14 root -64 - 0K 512K - 0 0:00 0.00% {usbus2} Куда рыть?! Может я PF неправильно конфигурю? Edited September 27, 2010 by ex-transfer Вставить ник Quote
Giga-Byte Posted September 27, 2010 Posted September 27, 2010 перенеси всё на dummynet, и забудь про pf Вставить ник Quote
ex-transfer Posted September 27, 2010 Author Posted September 27, 2010 перенеси всё на dummynet, и забудь про pf я наоборот с dummynet'а перенес все на pf (это нелегкого стоило, т.к. написать скрипт автодобавления юзера в pf в разы сложнее чем в ipfw) параллельный вопрос: как бороться с задержками в dummynet с маленькими скоростями в pipe? Если это можно решить - перейду на ipfw. Но дело кроется не в нем, по-моему Вставить ник Quote
Deac Posted September 27, 2010 Posted September 27, 2010 А что за "маленькие скорости" в dummynet? Общие рекомендации - используй one_pass, таблицы ну и GRED наше всё. Вставить ник Quote
XeonVs Posted September 27, 2010 Posted September 27, 2010 (edited) перенеси всё на dummynet, и забудь про pf я наоборот с dummynet'а перенес все на pf (это нелегкого стоило, т.к. написать скрипт автодобавления юзера в pf в разы сложнее чем в ipfw) параллельный вопрос: как бороться с задержками в dummynet с маленькими скоростями в pipe? Если это можно решить - перейду на ipfw. Но дело кроется не в нем, по-моему PF использует глобальные блокировки и фактически получается однопоточным.Насколько маленькие скорости в pipe? Как тут правильно посоветовали gred и подбор размера очереди под требуемую скорость. Вот не плохая мурзилка http://osboy.blog.ru/33351283.html по данному вопросу для начала. Edited September 27, 2010 by XeonVs Вставить ник Quote
photon Posted September 27, 2010 Posted September 27, 2010 (edited) GRED -- далеко не самое главное. Обладатели Cisco SCE вообще полисинг делают, и юзеры не жалуются. Важно, чтобы для классификации трафика использовались хэши на основе пользовательских IP-адресов. В ipfw это реализуется динамическими пайпами или правилом вида pipe tablearg. Примеры легко найти на данном форуме. В противном случае, каждый пакет будет пробегать тысячи правил, и процессорное время будет расходоваться так же неоптимально, как в pf/ALTQ. Кроме того, в ipfw меньше проблем с гигантскими блокировками, чем в pf. Edited September 27, 2010 by photon Вставить ник Quote
ex-transfer Posted September 28, 2010 Author Posted September 28, 2010 (edited) А что за "маленькие скорости" в dummynet?Общие рекомендации - используй one_pass, таблицы ну и GRED наше всё. "Маленькие" - это до 1024 кбита, (слава аллаху, что сейчас тарифы с такими скоростями уже не существуют, но вот пример такого тарифа, у него задержки были около 400мс): ipfw add 228 pipe 228 ip from any to 172.16.5.2 in via vlan190 ipfw add 229 pipe 229 ip from 172.16.5.2 to any in via vlan700 ipfw pipe 228 config bw 128Kbit/s queue 100 ipfw pipe 229 config bw 128Kbit/s queue 100 ONE_PASS - я так понимаю, опция в ядре должна быть? Можно рабочий пример для GRED например для скорости 2Мбита? И нужны ли тонкие настройки в самой ФРЕ? Я имею в виду тонкий тюнинг сетевой подсистемы для IPFW ? p.s. вообще спасибо всем за комменты и советы. Начинаю заново "знакомиться" с IPFW Edited September 28, 2010 by ex-transfer Вставить ник Quote
XeonVs Posted September 28, 2010 Posted September 28, 2010 (edited) А что за "маленькие скорости" в dummynet?Общие рекомендации - используй one_pass, таблицы ну и GRED наше всё. "Маленькие" - это до 1024 кбита, (слава аллаху, что сейчас тарифы с такими скоростями уже не существуют, но вот пример такого тарифа, у него задержки были около 400мс): ipfw add 228 pipe 228 ip from any to 172.16.5.2 in via vlan190 ipfw add 229 pipe 229 ip from 172.16.5.2 to any in via vlan700 ipfw pipe 228 config bw 128Kbit/s queue 100 ipfw pipe 229 config bw 128Kbit/s queue 100 ONE_PASS - я так понимаю, опция в ядре должна быть? Можно рабочий пример для GRED например для скорости 2Мбита? И нужны ли тонкие настройки в самой ФРЕ? Я имею в виду тонкий тюнинг сетевой подсистемы для IPFW ? p.s. вообще спасибо всем за комменты и советы. Начинаю заново "знакомиться" с IPFW one-pass sysctl переменная net.inet.ip.fw.one_pass Правильно что большие задержки, очередь-то здоровая. для 128к и 100мсек. будет примерно так: queue 8 gred 0.002/1/2/0.1 как-то так: ipfw table 10 flush ipfw table 10 add 172.16.5.2/32 28 ipfw table 10 add 172.16.5.3/32 29 ..... ..... ipfw table 11 flush ipfw table 11 add 172.16.5.2/32 228 ipfw table 11 add 172.16.5.3/32 229 .... .... ipfw pipe 28 config queue 32 bw 1Mbit/s mask dst-ip 0xffffffff gred 0.002/8/16/0.1 ipfw pipe 228 config queue 32 bw 1Mbit/s mask src-ip 0xffffffff gred 0.002/8/16/0.1 ipfw pipe 29 config queue 68 bw 2Mbit/s mask dst-ip 0xffffffff gred 0.002/17/34/0.1 ipfw pipe 229 config queue 68 bw 2Mbit/s mask src-ip 0xffffffff gred 0.002/17/34/0.1 ipfw add 705 pipe tablearg ip from any to "table(10)" out xmit vlan0 ipfw add 705 pipe tablearg ip from "table(11)" to any in recv vlan0 Edited September 30, 2010 by XeonVs Вставить ник Quote
ex-transfer Posted September 28, 2010 Author Posted September 28, 2010 XeonVs Огромное спасибо за примерчик! Уже начитался про ipfw table, пора приниматься за практическое применение. Ядро пересобрал с поддержкой dummynet. На pf наверное оставлю только НАТ, ipfw - только шейперство. ПОсмотрим на результаты... Сегодня-завтра-отпишусь Вставить ник Quote
XeonVs Posted September 28, 2010 Posted September 28, 2010 (edited) XeonVs Огромное спасибо за примерчик! Уже начитался про ipfw table, пора приниматься за практическое применение. Ядро пересобрал с поддержкой dummynet. На pf наверное оставлю только НАТ, ipfw - только шейперство. ПОсмотрим на результаты... Сегодня-завтра-отпишусь лучше вообще убрать(разделить функционал по разным машинкам) pf, если не нужны его специфичные фичи. ipfw nat справится. Edited September 28, 2010 by XeonVs Вставить ник Quote
ex-transfer Posted September 28, 2010 Author Posted September 28, 2010 XeonVs Огромное спасибо за примерчик! Уже начитался про ipfw table, пора приниматься за практическое применение. Ядро пересобрал с поддержкой dummynet. На pf наверное оставлю только НАТ, ipfw - только шейперство. ПОсмотрим на результаты... Сегодня-завтра-отпишусь лучше вообще убрать(разделить функционал по разным машинкам) pf, если не нужны его специфичные фичи. ipfw nat справится. Я тоже так думаю, сервачок под выделенный НАТ уже в пути ))Юзеров-то у нас всего ~2000 Вставить ник Quote
ex-transfer Posted September 28, 2010 Author Posted September 28, 2010 XeonVs непонятно, зачем Вы в конфиге заполняете таблицы с различными скоростями для юзеров в рамке одной таблицы? ipfw table 10 add 172.16.5.2/32 28 ipfw table 10 add 172.16.5.3/32 29 Последнее число, как я понял из man'а - это указатель к какой pipe привязать? Вставить ник Quote
Deac Posted September 28, 2010 Posted September 28, 2010 (edited) Ну это просто пример асимметричного шэйпинга 1/2Mbps Последнее число - пресловутый tablearg, оч. полезная вещь, и не только в pipe/queue Edited September 28, 2010 by Deac Вставить ник Quote
Ilya Evseev Posted September 28, 2010 Posted September 28, 2010 Я тоже так думаю, сервачок под выделенный НАТ уже в пути ))Юзеров-то у нас всего ~2000 На такое количество клиентов и 100mbps должно хватить одного сервера ipfw+dummynet+netflow+pfnat.Второй сервер здесь может быть нужен только на тот случай, если первый сломается. Вставить ник Quote
ex-transfer Posted September 29, 2010 Author Posted September 29, 2010 Я тоже так думаю, сервачок под выделенный НАТ уже в пути ))Юзеров-то у нас всего ~2000 На такое количество клиентов и 100mbps должно хватить одного сервера ipfw+dummynet+netflow+pfnat.Второй сервер здесь может быть нужен только на тот случай, если первый сломается. Оттестировал! Пока ни потерь, ни тормозов в web.Во: shapper# netstat -w1 -i vlan250 input (Total) output packets errs bytes packets errs bytes colls 9732 0 6562222 9512 0 6788224 0 10069 0 6829139 9872 0 7066174 0 10139 0 6874054 9609 0 7108733 0 10681 0 7467601 10785 0 7717429 0 9715 0 6521394 9613 0 6771326 0 9750 0 6626889 9690 0 6842818 0 10779 0 7062299 10567 0 7291172 0 10229 0 7091838 9824 0 7313028 0 10097 0 7003873 9935 0 7216538 0 10401 0 6977869 10325 0 7234084 0 Скорости режутся практически идеально. Нагрузка на процы менее 15% !!! last pid: 39061; load averages: 0.08, 0.17, 0.15 up 0+23:34:47 17:02:21 138 processes: 5 running, 107 sleeping, 26 waiting CPU 0: 2.6% user, 0.0% nice, 5.3% system, 14.9% interrupt, 77.2% idle CPU 1: 2.6% user, 0.0% nice, 5.3% system, 0.9% interrupt, 91.2% idle CPU 2: 2.6% user, 0.0% nice, 1.8% system, 1.8% interrupt, 93.9% idle CPU 3: 0.0% user, 0.0% nice, 4.4% system, 0.0% interrupt, 95.6% idle Mem: 39M Active, 201M Inact, 330M Wired, 296K Cache, 213M Buf, 1403M Free Swap: 4096M Total, 4096M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 171 ki31 0K 64K CPU1 1 20.7H 97.85% {idle: cpu1} 11 root 171 ki31 0K 64K CPU3 3 19.4H 95.36% {idle: cpu3} 11 root 171 ki31 0K 64K CPU2 2 19.7H 87.35% {idle: cpu2} 11 root 171 ki31 0K 64K RUN 0 18.4H 86.13% {idle: cpu0} 12 root -44 - 0K 416K WAIT 1 455:00 6.69% {swi1: netisr 0} 0 root 45 0 0K 176K WAIT 2 52:43 1.66% {em1_rx_0} 905 nobody 46 0 8016K 3684K select 1 94:07 1.51% softflowd 903 nobody 45 0 8016K 3648K select 0 84:54 1.51% softflowd 0 root 45 0 0K 176K WAIT 1 49:03 1.17% {em0_rx_1} 0 root 45 0 0K 176K WAIT 3 49:31 0.93% {em0_rx_0} 0 root 45 0 0K 176K WAIT 1 52:28 0.78% {em1_rx_1} 12 root -32 - 0K 416K WAIT 2 21:12 0.10% {swi4: clock} 0 root -68 0 0K 176K - 2 41:29 0.00% {dummynet} 12 root -68 - 0K 416K WAIT 0 13:11 0.00% {irq258: bge0} 12 root 16 - 0K 416K WAIT 2 5:18 0.00% {swi16: em0_tx} 12 root 16 - 0K 416K WAIT 1 4:49 0.00% {swi16: em1_tx} Тестю дальше, на нагрузке поболее.... Вставить ник Quote
Deac Posted September 29, 2010 Posted September 29, 2010 Толи ещё будет, у Луиджи там "планов громадьё", пока правда больше ломает чем строит. :) Вставить ник Quote
andriko Posted September 29, 2010 Posted September 29, 2010 Толи ещё будет, у Луиджи там "планов громадьё", пока правда больше ломает чем строит. :)кста :)http://docs.freebsd.org/cgi/getmsg.cgi?fet...ent/svn-src-all Вставить ник Quote
st_re Posted September 29, 2010 Posted September 29, 2010 ipfw table 10 flush ipfw pipe 28 config queue 32 bw 1Mbit/s mask dst-ip 0xffffffff gred 0.002/8/16/0.1 ipfw pipe 228 config queue 32 bw 1Mbit/s mask dst-ip 0xffffffff gred 0.002/8/16/0.1 ipfw pipe 29 config queue 68 bw 2Mbit/s mask dst-ip 0xffffffff gred 0.002/17/34/0.1 ipfw pipe 229 config queue 68 bw 2Mbit/s mask dst-ip 0xffffffff gred 0.002/17/34/0.1 ipfw add 705 pipe tablearg ip from any to "table(10)" out xmit vlan0 ipfw add 705 pipe tablearg ip from "table(11)" to any in recv vlan0 Только для труб 228 и 229 dst сменить на src .... :) А то шейпиться будет не скорость от клиента, а скорость _к_ www.microsoft.com Вставить ник Quote
ex-transfer Posted September 30, 2010 Author Posted September 30, 2010 ГУРУ, вопрос может и глубый, но как вы пропускаете в инет ТОЛЬКО юзеров из таблиц, а остальных рубите? У меня не выходит каменный цветок. Ткните кусочком конфига Вставить ник Quote
Deac Posted September 30, 2010 Posted September 30, 2010 Не использовать IPFIREWALL_DEFAULT_TO_ACCEPT Вставить ник Quote
ex-transfer Posted September 30, 2010 Author Posted September 30, 2010 Не использовать IPFIREWALL_DEFAULT_TO_ACCEPT уже убрал ) хана халявщикам! Вставить ник Quote
blackjack Posted September 30, 2010 Posted September 30, 2010 последним правилом прописать deny from any to any Вставить ник Quote
denis_vid Posted September 30, 2010 Posted September 30, 2010 Не использовать IPFIREWALL_DEFAULT_TO_ACCEPTЭто очень и очень глупо. Особенно если сервер где то там куда надо добираться.Лучше one pass 1 и правила 65533 65534 запрещающие все что не попало выше в клиентских сетях Вставить ник Quote
Deac Posted October 1, 2010 Posted October 1, 2010 Ознакомься что делает вышеуказанная опция. Детская болезнь боязни собственной неумелости, этим надо просто переболеть. Все контролируемые мной сервера более или менее удалены, некоторые больше чем на 100км. Есть общепринятые правила внесения изменений в файервол, читай маны, доки, материала достаточно и обязательно обкатывай всё на стенде. Если уж чувствуешь свою неготовость - имей "удалённые руки". Вставить ник Quote
denis_vid Posted October 1, 2010 Posted October 1, 2010 (edited) Ознакомься что делает вышеуказанная опция.Детская болезнь боязни собственной неумелости, этим надо просто переболеть. Все контролируемые мной сервера более или менее удалены, некоторые больше чем на 100км. Есть общепринятые правила внесения изменений в файервол, читай маны, доки, материала достаточно и обязательно обкатывай всё на стенде. Если уж чувствуешь свою неготовость - имей "удалённые руки". Указанная функция включает правило по умолчанию 65535 deny from any to anyПо остальному если ты такой идеальный что никогда не катаешься за 100 км потому что "ой все пропало" я тебе завидую А у меня например биллинг управляет правилами ipfw и ежедневно необходимо добавлять изменять общие правила а иногда и обновлять систему. А после обновления может оказаться что синтаксис в rc.firewall самую чуточку изменился а net.inet.ip.fw.enable 1 У меня лично валидола бы не хватило так работать с сервером за 100 км. Edited October 1, 2010 by denis_vid Вставить ник Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.