Skylord Опубликовано 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... Ну, у себя я этого как-то не замечаю - даже наоборот. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
t0ly Опубликовано 5 марта, 2009 · Жалоба ipfw nat умеет натить сетку через пул адрессов? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Skylord Опубликовано 5 марта, 2009 · Жалоба ipfw nat умеет натить сетку через пул адрессов?Мммм.... Насколько я помню, просто написав блок адресов в конфиге - нет, нельзя. Он же тупо повторяет функционал libalias, а тот такого не умеет. Собственно, само по себе оно не проблема - сделать-то можно. Пакеты в nat загоняются обычными правилами файрволла. Никто не мешает сделать правила, скажем, с разным prob, чтобы они случайным образом загоняли пакеты в разные nat'ы с разными адресами - вот и будет балансировка с пулом адресов. :-)Такого удобства, как с pf, в котором можно одной строчкой делать много всего разного, в ipfw вообще ожидать не стоит. Уже ведь много раз обсуждалось - что в файрволлов совершенно разная идеология и подход. ipfw рассчитан на мелкие атомарные действия, а pf - на описание работы более общего характера. Если сравнивать с языками программирования, то ipfw - это асм, а pf - язык высокого уровня. :-) Само по себе это неплохо, но в моем конкретном случае overhead у pf оказался слишком большой... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
t0ly Опубликовано 5 марта, 2009 · Жалоба это был риторический вопрос скорее :) вообще prob в ipfw это совсем нето что требуется. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
IvanI Опубликовано 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\) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Skylord Опубликовано 5 марта, 2009 · Жалоба это был риторический вопрос скорее :)вообще prob в ipfw это совсем нето что требуется. Гм. Что ж в этом вопросе риторического? Типичная задача... Я у себя тоже пул адресов делать буду... Откровенно говоря, в данный конкретный момент конфигурация ipfw nat у меня уже отчасти сложнее, чем получилось бы с prob'ами. У меня три разных nat'а и пакеты в них запихиваются где-то 20-ю правилами - разные пакеты и в зависимости от условий. Чтобы сделать пул адресов потребуется добавить еще НАТов для разных адресов и соответственно размножить правила, запихивающие их туда - сделать это можно буквально за 20 минут...Так чем конкретно не устраивает предложенный вариант? Задачу он выполняет, а что делается не одной строчкой - дык, это архитектура файрволла такая. Результат от этого хуже не будет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Skylord Опубликовано 5 марта, 2009 (изменено) · Жалоба Это был пиар ng_nat'а? ;-) А почему так скупо и без комментариев? ;-)Сразу скажу - я ничего не имею против ng_nat и сам его использую на паре vpn-серверов - работает нормально. :-) Правда, когда я его ставил, он еще редиректы делать не умел... Вопрос в том - есть ли у него реальные преимущества перед ipfw nat? И тот, и другой сделаны на libalias... С дилетантской точки зрения можно ожидать от ng_nat лишних накладных расходов за счет усложения пути пакета - ipfw->ng_ipfw->ng_nat. А как на самом деле? Тестировал ли это кто-нибудь? Изменено 5 марта, 2009 пользователем Skylord Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mikevlz Опубликовано 5 марта, 2009 · Жалоба ng_nat можно повесить на интерфейс. Тогда никакого заворота кишок у Ipfw в принципе не будет. Будет kernel <-> ng_iface <->ng_nat<->interface Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
IvanI Опубликовано 5 марта, 2009 · Жалоба ng_nat можно повесить на интерфейс. 1 да а как пулы повесиш? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...