Шейпер на pf.

[Kucher2 122]

Дано: Шлюз сети. FreeBSD 8.0, прозрачный SQUID и пока ещё только pf в качестве фаерволла.

Внешний ИФ-10.0.1.3, внутренний 192.168.0.1.

 

Сколько юзаю FreeBSD - всё время пользовался ipfw + natd.

Решил перейти на pf. Главным образом из-за того, что pf как бы меньше грузит проц, по отзывам.

 

Добился пока что прозрачного прокси:

http://local.com.ua/forum/topic/20228-pomogite-s-pf/page__pid__149630__st__0entry149630

 

На pf - Столкнулся со сложностью шейпа юзеров.

Если кто юзает pf - пожалуйста, покажите как на нём зарезать траф для юзеров в обе стороны.

Сижу вот и думаю: а стоит ли заморачиваться?

[Kto To 602]

для "в обе стороны" надо искать заплатку на пф. по дефолту он шейпит в одну сторону только

[Enferno 163]

altq вам в помощь!

[Kucher2 122]

Я просил примеры. Желательно рабочие. Пожалуйста, не надо туманных намёков.

Я уже перебрал множество вариантов, но все либо режут только в одном направлении, либо вообще не пропускают трафик.

Интересует так же мнение бывалых: на pf вообще возможно сделать полноценный шейпер или нет?

Хочется полностью уйти от ipfw, иначе не вижу смысла его менять. В принципе по функциям он меня устраивает.

[warzoni 7]

Используйте Ipfw pipe в место pf сним удобнее примеров уйма.

[Kucher2 122]

Т.е. не переходить на pf? Остаться на ipfw и natd?

[Enferno 163]

такс, я скажу только Бог в помощь разобрать это: =)

 

##################

###ALTQ Секция ###

##################

 

altq on $int_if hfsc bandwidth 90Mb queue {inet_in,admin_in,mail_in,w_in,radio_in,default_in}

 

# Входящий траффик

# <UA-IX Секция>

 

# Все звери

queue inet_in bandwidth 10Mb hfsc (upperlimit 10Mb){other_in,inet_taz_in}

queue other_in bandwidth 7Mb hfsc(realtime 7Mb upperlimit 10Mb)

queue inet_taz_in bandwidth 3Mb hfsc(realtime 3Mb upperlimit 10Mb)

 

# Все админы

queue admin_in bandwidth 40Mb hfsc (upperlimit 90Mb){xsoft_in,z1_in,servers_in,olekko_in}

queue xsoft_in bandwidth 10Mb hfsc(realtime 10Mb upperlimit 90Mb)

queue servers_in bandwidth 15Mb hfsc(realtime 15Mb upperlimit 90Mb)

 

 

 

# Дефолтная полоса

queue default_in bandwidth 5Mb hfsc(default realtime 5Mb)

# </UA-IX Секция>

 

# <Мировая секция (входящий траффик)>

 

queue w_in bandwidth 4Mb hfsc(upperlimit 4Mb){xsoft_w_in, z1_w_in, servers_w_in, other_w_in}

queue xsoft_w_in bandwidth 1Mb priority 5 hfsc(realtime 512Kb upperlimit (3Mb,4000,1536Kb))

queue servers_w_in bandwidth 1Mb priority 4 hfsc(realtime 1536Kb upperlimit (3Mb,4000,2Mb))

queue other_w_in bandwidth 1Mb priority 6 hfsc(realtime 512Kb upperlimit (4Mb,4000,1536Kb))

 

# </Мировая секция (входящий траффик)>

#<------------------------------------------------------------------------------------>#

#

altq on $ext_if hfsc bandwidth 65Mb queue {inet_out,admin_out,mail_out,w_out,default_out,radio_out}

 

# Исходящий траффик

# <UA-IX Секция>

 

# Все звери

queue inet_out bandwidth 5Mb hfsc (upperlimit 5Mb) {other_out,inet_taz_out}

queue other_out bandwidth 3Mb hfsc(realtime 3Mb upperlimit 5Mb)

queue inet_taz_out bandwidth 2Mb hfsc(realtime 2Mb upperlimit 5Mb)

 

# Все админы

queue admin_out bandwidth 40Mb hfsc (upperlimit 60Mb){xsoft_out,z1_out,servers_out,olekko_out}

queue xsoft_out bandwidth 10Mb hfsc(realtime 10Mb upperlimit 60Mb)

queue servers_out bandwidth 10Mb hfsc(realtime 10Mb upperlimit 60Mb)

 

 

# Дефолтная полоса

queue default_out bandwidth 2Mb hfsc(default realtime 2Mb)

# </UA-IX Секция>

 

# <Мировая секця (исходящий траффик)>

 

queue w_out bandwidth 12Mb hfsc(upperlimit 12Mb){xsoft_w_out, z1_w_out, servers_w_out, other_w_out}

queue xsoft_w_out bandwidth 2Mb priority 5 hfsc(realtime 1Mb upperlimit (12Mb,500,6Mb))

queue other_w_out bandwidth 1Mb priority 6 hfsc(realtime 1Mb upperlimit 2Mb)

 

# </Мировая секция (исходящий траффик)>

 

 

[Kucher2 122]

Спасибо.

[warzoni 7]

Т.е. не переходить на pf? Остаться на ipfw и natd?

 

да оставайтесь, у Ipfw функций на шейпер гибче чем у Pf, хотя-бы пример в две стороны на одном интерфейсе режет Ipfw, а pf Только входящий, для того что бы резать ввход и выход, у юзеров вам следует на двух интерфейсах устанавливать altq, используя ipfw pipe вы можете резать на одном интерфейсе не трогая другой.

[blackjack 250]

старые песни о главном

ось кілька посилань про все теж

_http://forum.lissyara.su/viewtopic.php?f=8&t=17513

_http://forum.lissyara.su/viewtopic.php?f=8&t=23956

_http://forum.lissyara.su/viewtopic.php?f=8&t=21744

_http://www.opennet.ru/search.shtml?exclude=index|%2Fman.shtml&words=pf+altq

_http://house.hcn-strela.ru/BSDCert/BSDA-course/single.html#firewall-pf

[Kucher2 122]

Так. Всем спасибо, попробую pf+ipfw щас настроить. Исключительно ради быстродействия.

[warzoni 7]

Я исползую связку pf + ipfw у меня pf, nat, проброс портов,ipfw чисто режет блочит всё нужно конкретно и индеведуально рассматривать в этом случаи нельзя решатьч то лучьше что хуже.

[Kucher2 122]

Вот и я про то же. Буду пробовать. Спасибо.

[Queeq 0]

Я тоже люблю PF, но в плане шейпинга у него, к сожалению, есть ужасный недостаток: на каждого юзера нужно вешать шейпер индивидуально. Нельзя, например, как на циске применить одну политику на всех (в этом случае PF засунет всех в одну очередь).

 

Поскольку у меня внутренних зашейпленных тачек не много - я всех определил явно. Да, на двух интерфейсах. Ну а вообще народ, насколько я знаю, нормально совмещает PF (как основной фаер) + IPFW для шейпинга. Сам не пробовал.

[Kucher2 122]

http://local.com.ua/forum/topic/20228-pomogite-s-pf/page__view__findpost__p__149597

[adeep 212]

Сколько юзаю FreeBSD - всё время пользовался ipfw + natd.

Решил перейти на pf. Главным образом из-за того, что pf как бы меньше грузит проц, по отзывам.

Кто вам сказал такую глупость?

 

переходите на ipfw + ipfw-nat

[Queeq 0]

Сколько юзаю FreeBSD - всё время пользовался ipfw + natd.

Решил перейти на pf. Главным образом из-за того, что pf как бы меньше грузит проц, по отзывам.

Кто вам сказал такую глупость?

 

переходите на ipfw + ipfw-nat

 

Вы тестировали лично?

[911 140]

Сколько юзаю FreeBSD - всё время пользовался ipfw + natd.

Решил перейти на pf. Главным образом из-за того, что pf как бы меньше грузит проц, по отзывам.

Кто вам сказал такую глупость?

 

переходите на ipfw + ipfw-nat

 

Вы тестировали лично?

насколько я знаю, он так и использует )

[Clone 8]

Я тоже люблю PF, но в плане шейпинга у него, к сожалению, есть ужасный недостаток: на каждого юзера нужно вешать шейпер индивидуально. Нельзя, например, как на циске применить одну политику на всех (в этом случае PF засунет всех в одну очередь).

 

Поскольку у меня внутренних зашейпленных тачек не много - я всех определил явно. Да, на двух интерфейсах. Ну а вообще народ, насколько я знаю, нормально совмещает PF (как основной фаер) + IPFW для шейпинга. Сам не пробовал.

 

У меня так-же, PF как фаервол и IPFW - шейпер. Работает уже много лет и вполне нормально.

[Queeq 0]

Сколько юзаю FreeBSD - всё время пользовался ipfw + natd.

Решил перейти на pf. Главным образом из-за того, что pf как бы меньше грузит проц, по отзывам.

Кто вам сказал такую глупость?

 

переходите на ipfw + ipfw-nat

 

Вы тестировали лично?

насколько я знаю, он так и использует )

 

 

 

Я немного неправильно спросил Имелось в виду тестирование производительности PF против IPFW.

 

Объясню почему спрашиваю: у меня когда-то был IPFW на 5-й фре. Работал он с natd через divert. Компик был что-то около пня 1.8. В общем на 40 Мбитах он сжирал весь проц. Потом поставили другой комп вместо него (Пень 2.4, гиговые сетевухи, фря 6.2 и PF с NAT'ом, шейпингом, anchor'ами и прочими плюшками). На полных 100 Мбитах download и около 15 Мбит upload этот комп (стоит до сих пор) показывает загрузку проца системой около 5-6%. Полагаю, что это и есть то, что жрёт PF. При этом набор правил там далеко не элементарный, плюс в нём несколько раз в правилах без keep state обрабатывается таблица украинских сетей (на момент написания - 2797 записей). Ещё около 40% съедают interrupts с двух сетевух (не тюнил за ненадобностью).

 

Не знаю, может быть вышел какой-то новый IPFW, который лучше того, что пробовал я. Но я абсолютно доволен гибкостью PF (шейпинг не в счёт) и его производительностью  при такой нагрузке.

 

 

 

 

З.Ы. Да, есть у PF ещё один недостаток: он не может использовать несколько процов/ядер. Пока что. Вроде там уже что-то шевелятся на этот счёт.

 

З.З.Ы. Забыл упомянуть, что при той нагрузке около 115 мбит количество сессий было около 5000.

Edited 2010-02-12 11:21:14 by Queeq

[911 140]

у меня когда-то был IPFW на 5-й фре. Работал он с natd через divert. Компик был что-то около пня 1.8. В общем на 40 Мбитах он сжирал весь проц.

ну мы же вроде говорим про ipfw + ipfw_nat, а не про natd

 

З.Ы. Да, есть у PF ещё один недостаток: он не может использовать несколько процов/ядер. Пока что. Вроде там уже что-то шевелятся на этот счёт.

ну это главный камень преткновения

 

З.З.Ы. Забыл упомянуть, что при той нагрузке около 115 мбит количество сессий было около 5000.

количество сессий или pps ?

[adeep 212]

Я немного неправильно спросил Имелось в виду тестирование производительности PF против IPFW.

 

Не знаю, может быть вышел какой-то новый IPFW, который лучше того, что пробовал я. Но я абсолютно доволен гибкостью PF (шейпинг не в счёт) и его производительностью  при такой нагрузке.

 

З.Ы. Да, есть у PF ещё один недостаток: он не может использовать несколько процов/ядер. Пока что. Вроде там уже что-то шевелятся на этот счёт.

 

З.З.Ы. Забыл упомянуть, что при той нагрузке около 115 мбит количество сессий было около 5000.

Не путайте natd и ipfw-nat. Я вполне полагаю что pfnat работает быстрее чем natd. Только потому что natd работает через DIVERT сокеты, которые гоняют пакеты между kernel и userland, что означает очень высокие потери на обработку пакета.

libalias более прогрессивная в плане поддержки ftp протокола чем pf, ipfw-nat реализован через

NETGRAPH, что означает очень малые затраты на обработку пакетов и соответственно более высокую скорость.

Я очень уважаю Theo, но опененок не очень скоро обзаведется нормальной многоядерностью и соответственно за ним и pf.

 

На самом деле было время когда сравнивалась в целом производительность шейп + нат + файрвол. Варианты были такие:

1)Все на pf

2) ipfw + ipfwnat + ipfw-altq

3) dummynet + ipfwnat + ipfw

 

Разница в производительности между первым и третьим вариантом была практически двукратная, ессно в пользу ipfw

К сожалению, конкретно по нату тестов не было.

 

З.Ы. забудьте времена 5й фри. это было слишком давно. Пропасть в фичастости между 5 и 7 фрей громадна

[Queeq 0]

 

З.З.Ы. Забыл упомянуть, что при той нагрузке около 115 мбит количество сессий было около 5000.

количество сессий или pps ?

 

Количество сессий. Если быть точнее - количество записей в state таблице PF.

 

 

 

 

 

 

На самом деле было время когда сравнивалась в целом производительность шейп + нат + файрвол. Варианты были такие:

1)Все на pf

2) ipfw +  ipfwnat + ipfw-altq

3) dummynet + ipfwnat + ipfw

 

Разница в производительности между первым и третьим вариантом была практически двукратная, ессно в пользу ipfw

К сожалению, конкретно по нату тестов не было.

 

 

 

Двукратная разница? А как тестировалось, можно поподробнее?

[nightfly 1,252]

Количество сессий. Если быть точнее - количество записей в state таблице PF.

Не есть много, вобще немного. Не вижу смысла связывать себя с дубовым pf на таких нагрузках. Я уже молчу о отсутствии банального smp.

 

ipfw с ядерным натом на порядок гибче и веселее в целом. Просто нужно уметь готовить.

 

Ещё около 40% съедают interrupts с двух сетевух (не тюнил за ненадобностью).

выбросьте свои rl =)

 

10-15% интеррапта на ~300 Мбит потоках считается нормой.

 

В общем на 40 Мбитах он сжирал весь проц.

омг... хотя да с реалтеками, 100% дефолтом... на смартфоне... возможно

 

 

load averages: 0.33, 0.44, 0.32

 

4 x natd - резервный канал, плюс еще пачка сервисов на борту. Что я делаю не так?