Skylord Posted March 5, 2009 Posted March 5, 2009 Итак, не вдаваясь в подробности, имеем: bgp-бордер на freebsd 7.1 с quagga , на котором стоит до кучи НАТ и шейпер. Предыдущая схема - pf+ipfw. pf делает фильтрацию и НАТ (на котором помимо простого заворачивания еще несколько сотен редиректов адресов) ipfw режет скорость в обе стороны через dummynet Результат: где-то после 50 примерно kpps в каждую сторону все начинает тормозить. При net.isr.direct=1 загрузка (tasq сетевушек) лезет до 100%, после чего начинаются дропы, к тому же не хватает времени для работы quagga и она даже рвет периодически сессию с аплинком. При net.isr.direct=0 загрузка (swi: net) близка к 100%, все сервисы самого компа работают нормально, на чем больше pps через него пытаешься прокачать - тем ниже скорость и выше дропы. Короче, бутылочное горлышко. :-) Новая схема - ipfw Все делает ipfw - и фильтрацию, и шейпинг, и nat через новый встроенный в него ipfw NAT, который не так давно обзавелся всем функционалом libalias'а в плане редиректов и так далее (правда, для моих полуторы сотни редиректов потребовалось править ядро, то там всего-то одну переменную поменять - размер буфера увеличить... Хотя, конечно, почему это не вынесли в sysctl - непонятно.). Результат: более 75 kpps в каждую сторону, еще процентов 10-20 проца свободно (речь, конечно, идет о ЧНН). Стоит net.isr.direct=1, поэтому tasq сетевушек очень хорошо раскладываются на разные процы. В качестве дополнительного бонуса - отсутствие необходимости держать ftp-прокси и т.п., т.к. libalias делает это все сам, в отличие от pf. Ну и приятно, что теперь весь конфиг в одном файле и вообще... Чтобы убедиться, что все так ужасно, сделал профилирование ядра через hwpmc. Для схемы pf+ipfw получаем: index %time self descendents called+self name [1] 24.0 728322.00 0.00 rn_match [1] [2] 21.1 639456.00 0.00 pf_match_translation [2] [3] 7.2 219437.00 0.00 pfr_match_addr [3] [4] 5.9 179971.00 0.00 pf_match_addr [4] [5] 5.9 178394.00 0.00 pf_test_tcp [5] [6] 2.8 85714.00 0.00 ipfw_chk [6] и т.д. Короче, достаточно большую часть занимаемого ядром процессорного времени занимают всякие функции pf. Для одного ipfw получаем: index %time self descendents called+self name index [1] 31.3 447994.00 0.00 ipfw_chk [1] [2] 9.7 138090.00 0.00 _mtx_lock_sleep [2] [3] 8.4 120712.00 0.00 rn_match [3] [4] 4.7 66897.00 0.00 _FindLinkIn [4] [5] 1.4 19649.00 0.00 strncmp [5] и т.д. Не знаю, кому как, а мне почему-то это больше нравится. :-) Нет ощущения, что pf поработил мое ядро. ;-) Вот-с, такие канделябры... Так что тем, кто использует pf могу посоветовать поиграться с ipfw nat, который появился в последних версиях Бзди - можете получить определенное количество fun'а. Знаю, что многие не любят и ругают libalias... Ну, у себя я этого как-то не замечаю - даже наоборот. Вставить ник Quote
t0ly Posted March 5, 2009 Posted March 5, 2009 ipfw nat умеет натить сетку через пул адрессов? Вставить ник Quote
Skylord Posted March 5, 2009 Author Posted March 5, 2009 ipfw nat умеет натить сетку через пул адрессов?Мммм.... Насколько я помню, просто написав блок адресов в конфиге - нет, нельзя. Он же тупо повторяет функционал libalias, а тот такого не умеет. Собственно, само по себе оно не проблема - сделать-то можно. Пакеты в nat загоняются обычными правилами файрволла. Никто не мешает сделать правила, скажем, с разным prob, чтобы они случайным образом загоняли пакеты в разные nat'ы с разными адресами - вот и будет балансировка с пулом адресов. :-)Такого удобства, как с pf, в котором можно одной строчкой делать много всего разного, в ipfw вообще ожидать не стоит. Уже ведь много раз обсуждалось - что в файрволлов совершенно разная идеология и подход. ipfw рассчитан на мелкие атомарные действия, а pf - на описание работы более общего характера. Если сравнивать с языками программирования, то ipfw - это асм, а pf - язык высокого уровня. :-) Само по себе это неплохо, но в моем конкретном случае overhead у pf оказался слишком большой... Вставить ник Quote
t0ly Posted March 5, 2009 Posted March 5, 2009 это был риторический вопрос скорее :) вообще prob в ipfw это совсем нето что требуется. Вставить ник Quote
IvanI Posted March 5, 2009 Posted March 5, 2009 ngctl connect ipfw: netflow: 5 iface3 ngctl mkpeer netflow: split out3 in ngctl name netflow:out3 splitup2 ngctl connect splitup2: netflow: out iface2 ngctl connect ipfw: netflow: 7 out2 ngctl mkpeer splitup2: nat mixed out ngctl name splitup2:mixed nat2 ngctl connect ipfw: nat2: 6 in ngctl msg nat2: setaliasaddr $nat_adr2 ngctl connect ipfw: netflow: 9 iface5 ngctl mkpeer netflow: split out5 in ngctl name netflow:out5 splitup3 ngctl connect splitup3: netflow: out iface4 ngctl connect ipfw: netflow: 11 out4 ngctl mkpeer splitup3: nat mixed out ngctl name splitup3:mixed nat3 ngctl connect ipfw: nat3: 10 in ngctl msg nat3: setaliasaddr $nat_adr3 ipfw table 5 add 10.0.1.0/24 5 ipfw table 5 add 10.0.2.0/24 9 ipfw table 15 add a.a.a.161 6 ipfw table 15 add a.a.a.162 10 ipfw add 310 netgraph tablearg all from table\(5\) to any ipfw add 400 netgraph tablearg all from any to table\(15\) Вставить ник Quote
Skylord Posted March 5, 2009 Author Posted March 5, 2009 это был риторический вопрос скорее :)вообще prob в ipfw это совсем нето что требуется. Гм. Что ж в этом вопросе риторического? Типичная задача... Я у себя тоже пул адресов делать буду... Откровенно говоря, в данный конкретный момент конфигурация ipfw nat у меня уже отчасти сложнее, чем получилось бы с prob'ами. У меня три разных nat'а и пакеты в них запихиваются где-то 20-ю правилами - разные пакеты и в зависимости от условий. Чтобы сделать пул адресов потребуется добавить еще НАТов для разных адресов и соответственно размножить правила, запихивающие их туда - сделать это можно буквально за 20 минут...Так чем конкретно не устраивает предложенный вариант? Задачу он выполняет, а что делается не одной строчкой - дык, это архитектура файрволла такая. Результат от этого хуже не будет. Вставить ник Quote
Skylord Posted March 5, 2009 Author Posted March 5, 2009 (edited) Это был пиар ng_nat'а? ;-) А почему так скупо и без комментариев? ;-)Сразу скажу - я ничего не имею против ng_nat и сам его использую на паре vpn-серверов - работает нормально. :-) Правда, когда я его ставил, он еще редиректы делать не умел... Вопрос в том - есть ли у него реальные преимущества перед ipfw nat? И тот, и другой сделаны на libalias... С дилетантской точки зрения можно ожидать от ng_nat лишних накладных расходов за счет усложения пути пакета - ipfw->ng_ipfw->ng_nat. А как на самом деле? Тестировал ли это кто-нибудь? Edited March 5, 2009 by Skylord Вставить ник Quote
mikevlz Posted March 5, 2009 Posted March 5, 2009 ng_nat можно повесить на интерфейс. Тогда никакого заворота кишок у Ipfw в принципе не будет. Будет kernel <-> ng_iface <->ng_nat<->interface Вставить ник Quote
IvanI Posted March 5, 2009 Posted March 5, 2009 ng_nat можно повесить на интерфейс. 1 да а как пулы повесиш? Вставить ник Quote
.png.5d2afa2996cc6a85d0f2c09b92dd0a28.png)
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.