Jump to content
Калькуляторы

Небольшая реклама ipfw nat для сомневающихся...

Итак, не вдаваясь в подробности, имеем: 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... Ну, у себя я этого как-то не замечаю - даже наоборот.

 

Share this post


Link to post
Share on other sites

ipfw nat умеет натить сетку через пул адрессов?

Share this post


Link to post
Share on other sites
ipfw nat умеет натить сетку через пул адрессов?
Мммм.... Насколько я помню, просто написав блок адресов в конфиге - нет, нельзя. Он же тупо повторяет функционал libalias, а тот такого не умеет. Собственно, само по себе оно не проблема - сделать-то можно. Пакеты в nat загоняются обычными правилами файрволла. Никто не мешает сделать правила, скажем, с разным prob, чтобы они случайным образом загоняли пакеты в разные nat'ы с разными адресами - вот и будет балансировка с пулом адресов. :-)

Такого удобства, как с pf, в котором можно одной строчкой делать много всего разного, в ipfw вообще ожидать не стоит. Уже ведь много раз обсуждалось - что в файрволлов совершенно разная идеология и подход. ipfw рассчитан на мелкие атомарные действия, а pf - на описание работы более общего характера. Если сравнивать с языками программирования, то ipfw - это асм, а pf - язык высокого уровня. :-) Само по себе это неплохо, но в моем конкретном случае overhead у pf оказался слишком большой...

Share this post


Link to post
Share on other sites

это был риторический вопрос скорее :)

вообще prob в ipfw это совсем нето что требуется.

Share this post


Link to post
Share on other sites
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\)

Share this post


Link to post
Share on other sites
это был риторический вопрос скорее :)

вообще prob в ipfw это совсем нето что требуется.

Гм. Что ж в этом вопросе риторического? Типичная задача... Я у себя тоже пул адресов делать буду... Откровенно говоря, в данный конкретный момент конфигурация ipfw nat у меня уже отчасти сложнее, чем получилось бы с prob'ами. У меня три разных nat'а и пакеты в них запихиваются где-то 20-ю правилами - разные пакеты и в зависимости от условий. Чтобы сделать пул адресов потребуется добавить еще НАТов для разных адресов и соответственно размножить правила, запихивающие их туда - сделать это можно буквально за 20 минут...

Так чем конкретно не устраивает предложенный вариант? Задачу он выполняет, а что делается не одной строчкой - дык, это архитектура файрволла такая. Результат от этого хуже не будет.

Share this post


Link to post
Share on other sites
Это был пиар ng_nat'а? ;-) А почему так скупо и без комментариев? ;-)

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

Вопрос в том - есть ли у него реальные преимущества перед ipfw nat? И тот, и другой сделаны на libalias... С дилетантской точки зрения можно ожидать от ng_nat лишних накладных расходов за счет усложения пути пакета - ipfw->ng_ipfw->ng_nat. А как на самом деле? Тестировал ли это кто-нибудь?

Edited by Skylord

Share this post


Link to post
Share on other sites

ng_nat можно повесить на интерфейс. Тогда никакого заворота кишок у Ipfw в принципе не будет.

Будет kernel <-> ng_iface <->ng_nat<->interface

Share this post


Link to post
Share on other sites
ng_nat можно повесить на интерфейс.

1 да а как пулы повесиш?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this