Перейти к содержимому
Калькуляторы

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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\)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Это был пиар ng_nat'а? ;-) А почему так скупо и без комментариев? ;-)

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

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

Изменено пользователем Skylord

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ng_nat можно повесить на интерфейс.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.