[NiTr0]

А в линухе и выбирать то не из чего :)

Сплошная не полноценность, никто под него ничего не пишет, только старьё переписывают да костылей добавляют :)

Да ну? С бздей не попутали? С дровами пичаль, никакого подобия RPS (софтовой балансировки нагрузки от сетевух по ядрам) тоже не наблюдается, дрова для видео - портируются из линя и пока разве что на альфу тянут, бородатый natd процветает...

 

Пора тебе обновить документацию :)

http://www.freebsd.org/doc/en/books/handbook/advanced-networking.html почитайте 31.9. Или это неправильная документация? :)

[Ivan_83]

С дровами пичаль, никакого подобия RPS (софтовой балансировки нагрузки от сетевух по ядрам) тоже не наблюдается

Конечно нету, у нас оно ISR называется :)

 

дрова для видео - портируются из линя и пока разве что на альфу тянут

Мы в дексктоп пока и не лезем, а на консоль хватает.

В линухе тоже дрова так себе, в винде всё круче.

 

бородатый natd процветает...

Он уже давно отцвёл :)

 

http://www.freebsd.o...networking.html почитайте 31.9. Или это неправильная документация? :)

Там же написано - для DSL.

Вот когда упрёшься на дсл в натд, тогда перечитаешь доку на ipfw и сам допрёшь как сделать лучше.

[NiTr0]

Конечно нету, у нас оно ISR называется :)

Который вызывает краши в системах с активным созданием-удалением ифейсов?

 

Мы в дексктоп пока и не лезем, а на консоль хватает.

И в терминацию IPoE не лезете, и в сегмент корпоративных СУБД не лезете, и в эмбеддед не лезете... Сфера использования все сужается однако...

 

Он уже давно отцвёл :)

Где отцвел? В хэндбуке других альтернатив не наблюдается вообще.

 

Там же написано - для DSL.

Вот когда упрёшься на дсл в натд, тогда перечитаешь доку на ipfw и сам допрёшь как сделать лучше.

Нет, там написано:

on high-speed consumer lines such as cable or DSL

И да, это вообще-то хэндбук. Руководство по-нашему. Странно, когда в руководстве поминается древний, как говно мамонта юзерспейсовый natd. Логического объяснения я этому не вижу - ну разве что ограничить порог вхождения, дабы основная масса, сделавшая все по хэндбуку, сказала "ну и тормоз ваша бздя" и свалила на линь, не мешая свитератым бсдшникам дальше считать себя элитой...

[adsh]

И в пул адресов без проблем занатится, без горки правил на каждый адрес пула?

В pf nat это делается очень красиво:

 

http://www.openbsd.org/faq/pf/pools.html

 

/NAT Address Pool

 

Что касается ipfw nat см.:

 

http://forum.nag.ru/forum/index.php?showtopic=52869&view=findpost&p=454289'>http://forum.nag.ru/forum/index.php?showtopic=52869&view=findpost&p=454289

 

http://forum.nag.ru/forum/index.php?showtopic=52869&view=findpost&p=482292'>http://forum.nag.ru/forum/index.php?showtopic=52869&view=findpost&p=482292

 

Ну и полный топик: http://forum.nag.ru/forum/index.php?showtopic=52869

 

http://www.freebsd.org/doc/en/books/handbook/advanced-networking.html почитайте 31.9. Или это неправильная документация? :)

Этот раздел действительно не обновляли давно. Но в манах современные примеры есть. И в сети примеров полно.

[NiTr0]

В pf nat это делается очень красиво

А в комбо связке pf + ipfw для пптп/фтп/прочего? Или запросы от одного клиента с разных внешних ип - это ок?

[adsh]

А в комбо связке pf + ipfw для пптп/фтп/прочего? Или запросы от одного клиента с разных внешних ип - это ок?

По сути ipfw nat нужен лишь для GRE. Делается это как-то так:

 

http://www.propheta.ru/2009/11/pptp-gre-pf.html

 

В этом варианте рассогласования между управляющим соединением и туннелем нет, ибо их НАТит ipfw nat.

 

В pf nat есть ещё два варианта распределения адресов:

 

http://forum.nag.ru/forum/index.php?showtopic=52869&view=findpost&p=614823

[Ivan_83]

Который вызывает краши в системах с активным созданием-удалением ифейсов?

Это дела минувших дней.

 

И в терминацию IPoE не лезете

Кто бы проспонсировал допил mpd5 до такого функционала, там и пилить то немного.

 

Где отцвел? В хэндбуке других альтернатив не наблюдается вообще.

И да, это вообще-то хэндбук. Руководство по-нашему. Странно, когда в руководстве поминается древний, как говно мамонта юзерспейсовый natd. Логического объяснения я этому не вижу - ну разве что ограничить порог вхождения, дабы основная масса, сделавшая все по хэндбуку, сказала "ну и тормоз ваша бздя" и свалила на линь, не мешая свитератым бсдшникам дальше считать себя элитой...

Там ссылки есть на ман, в мане natd(8) ссылается на ман ipfw, читающий да увидит.

А кастомеру с дсл явно и natd хватит, много нынче кастомеров на гиге?

Админ же дочитает маны и заюзает ipfw.

Людей на документацию лишних нет, всё скромно.

[NiTr0]

Это дела минувших дней.

Всего лишь прошлой ветки...

 

Кто бы проспонсировал допил mpd5 до такого функционала, там и пилить то немного.

Ждите, может кто-то и спонсирует... Из идейных соображений.

 

Там ссылки есть на ман, в мане natd(8) ссылается на ман ipfw, читающий да увидит.

А нафига неофиту разбираться, на что в мане ссылаются, если самое главное руководство рекомендует natd?

 

Людей на документацию лишних нет, всё скромно.

Ну я же и говорю - платформа в стагнации, не интересная никому кроме горки олдскульных бсдшников...

[Ivan_83]

А нафига неофиту разбираться, на что в мане ссылаются, если самое главное руководство рекомендует natd?

Значит пусть ставит натд, в чём проблема?

Это не микротик и не винда чтобы комиксы по настройкам делать для даунов.

 

Ну я же и говорю - платформа в стагнации, не интересная никому кроме горки олдскульных бсдшников...

Платформа вылизанная до блеска, с чётким порядком и идеологией развития.

Это не линукс с базарной разработкой костылей разных видов и не венда меняющая скины чаще начинки.

Мне фря очень нравится тем что она очень бережно относится к настройкам и коду при обновлении, что нет ебической кучи не пойми каких дистров не пойми кем и для чего слепленных, в каждом из них всё по своему и максимально не похоже на другие, что не приходится переустанавливать и настраивать всё с нуля при любом чихе как с вендой.

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

[snvoronkov]

Конечно нету, у нас оно ISR называется :)

Который вызывает краши в системах с активным созданием-удалением ифейсов?

 

Не, ну это уже перебор.

 

Вот работает у меня три PPPoE терминатора на фре. uptime - 290 - 340 дней.

 

У меня, наверное, кака-то другая фря? Неправильная?

[NiTr0]

Это не микротик и не винда чтобы комиксы по настройкам делать для даунов.

Рекомендации официального руководства по настройке - комиксы для даунов? :)

Объясните, если самый главный мануал рекомендует natd - почему админ должен экспериментировать с другими вариантами? Ну чисто логически?

 

Платформа вылизанная до блеска, с чётким порядком и идеологией развития.

Угу, падение в связке isr+mpd в 8.х - признак блеска :)

Или отсутствие проверки в хваленом mpd, достаточно ли ресурсов для постройки хитросплетения нод нетграфа. Итог - если ресурсов недостаточно, часть нод создается, часть нет, клиент вылетает с ошибкой а останки нод продолжают висеть, порой приводя к невозможности повторного коннекта...

 

Не, ну это уже перебор.

 

Вот работает у меня три PPPoE терминатора на фре. uptime - 290 - 340 дней.

ISR отключен?

Грабли-то известные по интернетах, бсдшники часто плакались. А причина простая: пакет помещается в очередь на отправку, ждет пока воркер его обработает. В процессе ожидания интерфейс удаляется (клиент завершил работу). Доходит очередь до пакета - а отправлять его некуда, привет паника...

[snvoronkov]

ISR отключен?

Грабли-то известные по интернетах, бсдшники часто плакались. А причина простая: пакет помещается в очередь на отправку, ждет пока воркер его обработает. В процессе ожидания интерфейс удаляется (клиент завершил работу). Доходит очередь до пакета - а отправлять его некуда, привет паника...

 

Микс какой-то жесткий у Вас...

 

Вот тут все хорошо описано: http://dadv.livejournal.com/138951.html

[Aliech]

ISR отключен?

Грабли-то известные по интернетах, бсдшники часто плакались. А причина простая: пакет помещается в очередь на отправку, ждет пока воркер его обработает. В процессе ожидания интерфейс удаляется (клиент завершил работу). Доходит очередь до пакета - а отправлять его некуда, привет паника...

 

Микс какой-то жесткий у Вас...

 

Вот тут все хорошо описано: http://dadv.livejournal.com/138951.html

 

По ссылке описаны костыли и грабли. Это явно не признак "годной" платформы...

[Ivan_83]

Рекомендации официального руководства по настройке - комиксы для даунов? :)

Это уже передёргивание.

Рекомендации официального руководства начать с natd.

 

Объясните, если самый главный мануал рекомендует natd - почему админ должен экспериментировать с другими вариантами? Ну чисто логически?

Никто не заставляет, natd работает.

Хочешь натить промышленно, буть любезен прочитать чуть больше и немного больше разобраться в вопросе.

У нас комиксов нет.

 

Угу, падение в связке isr+mpd в 8.х - признак блеска :)

Это решается.

 

Или отсутствие проверки в хваленом mpd, достаточно ли ресурсов для постройки хитросплетения нод нетграфа. Итог - если ресурсов недостаточно, часть нод создается, часть нет, клиент вылетает с ошибкой а останки нод продолжают висеть, порой приводя к невозможности повторного коннекта...

Мелочи, вроде пофиксили уже. И докинуть памяти не так сложно и дорого.

В линуксах ядрёный ппп вообще на днях появился, школьнеги еле осилили его в ядро втащить :)

 

По ссылке описаны костыли и грабли. Это явно не признак "годной" платформы...

Ссылка 11 года, найдите ещё старее чтобы круче придраться :)

[NiTr0]

Рекомендации официального руководства начать с natd.

Ну и в чем его преимущество, если его лет 10 назад прикопать стоило? Или 10 лет назад в бзде не было альтернативы natd еще?

 

Никто не заставляет, natd работает.

Хочешь натить промышленно, буть любезен прочитать чуть больше и немного больше разобраться в вопросе

100 мбит на каком-то п3 или аликсе пронатит? Аликсы к слову у буржуев в моде...

 

Это решается.

Отключением isr?

 

Мелочи, вроде пофиксили уже. И докинуть памяти не так сложно и дорого.

Лечим все болезни касторкой?

 

В линуксах ядрёный ппп вообще на днях появился, школьнеги еле осилили его в ядро втащить :)

Отвечу вашими словами: ненужен был никому - вот и не было в ядре. Понадобился одному человеку - он и запилил ядреный пптп. Более 7 лет назад.

Когда там у бзди mpd образовался?

 

Ссылка 11 года, найдите ещё старее чтобы круче придраться :)

Если все 18 лет до 2011 года бсд строилась на костылях и подпорках в совокупности с магическим тюнингом, фиксящим дефекты дизайна касторкой тупым добавлением памяти/увеличением буфферов в надежде "само рассосется" - с чего бы ситуации радикально поменяться за 2 года?

[^rage^]

Кстати, наплодить несколько неполноценных подсистем ядра, вместо того, чтобы реализовать все необходимые функции в какой-то одной

А Вы не думаете, что это и есть т. н. unix way - собирать нужную функциональность из множества отдельных узко специфических программ вместо попытки лепить всё в один универсальный кривой комбайн.

зевая... ну покажите пример использования тэгов pf из netgraph(ну или наоборот). ну или совместное использование тэгов pf и ipfw. т.е. в pf тэг на пакетик повесили, в ipfw по этому тэгу сделали какой-то action.

 

пример покажите. потому что по ссылке, мягко говоря, не то.

Пример чего? Вот хороший практический пример из жизни:

 

https://calomel.org/pf_hfsc.html

 

См. "Can I use Pf's HFSC with my ISP's implementation of SpeedBoost or PowerBoost" ?

 

Эти провайдеры зажимают полосу как раз после выкачивания ххх Мб.

это частный случай. давайте продолжим идею: после 1Мб скорость урезается в 2 раза, после 10мб - в 4 раза.

если интересно, где такое может быть полезно - разного рода мобильный инет, где радиоресурс дорог и качальщиков надо как-то урезать.

 

полноценный разбор сложных протоколов есть в libalias. и мне интересно, как вы эту конструкцию скрестите с altq(вы же утверждали что всё можно, не так ли?).

ipfw add altq <имя очереди> <условие срабатывания>

для SIP можете пример привести?

 

Та же самая фигня с ... FTP.

 

Что не так с FTP? У меня прекрасно работает задание приоритетов для ftp, как в активном, так и в пассивном режиме, да ещё и с заданием отдельного приоритета для ACK пакетов этого трафика. А контрольное соединение попадает в отдельную приоритетную очередь. Для этого удобно использовать тегирование:

 

anchor "ftp-proxy/*"

 

pass in quick inet proto tcp to !(self) port ftp divert-to 127.0.0.1 port 8021

 

match on $ext_if inet proto tcp tagged ftp_data queue (www ack)

match out on $ext_if inet proto tcp to port (ftp ssh telnet) queue (pri ack)

 

/usr/sbin/ftp-proxy -T ftp_data

 

(кто не в курсе - программа ftp-proxy просто ковыряет контрольное соединение и, ни в коей мере, не пропускает через себя реальный ftp_date трафик)

я снова спрошу про SIP/H.323 и добавлю к вопросу PPTP.

 

А как с распределением нагрузки по ядрам? pf nat уже научился ее балансировать?

Уже есть многопоточный пф.

 

оно в CURRENT. ну т.е. есть бравые камикадзе, что ставят каррент в продакшн, но всё-таки его пока официально нет, а MFC в 9ку вроде как не было на эту тему.

[adsh]

А нафига неофиту разбираться, на что в мане ссылаются, если самое главное руководство рекомендует natd?

Неофит полезет в инет и быстро найдёт там расово правильное решение:

 

http://lmgtfy.com/?q=%D1%8F%D0%B4%D0%B5%D1%80%D0%BD%D1%8B%D0%B9+nat+freebsd+%D0%BF%D1%80%D0%B8%D0%BC%D0%B5%D1%80%D1%8B

 

Объясните, если самый главный мануал рекомендует natd - почему админ должен экспериментировать с другими вариантами? Ну чисто логически?

 

Неправильная постановка вопроса. Документация устарела, а не единственная рекомендация.

 

Мне фря очень нравится тем что она очень бережно относится к настройкам и коду при обновлении, что нет ебической кучи не пойми каких дистров не пойми кем и для чего слепленных, в каждом из них всё по своему и максимально не похоже на другие

 

Не зная Ивана - подпишусь под всем сказанным. FreeBSD - это классический UNIX с логически понятной и стандартизированной структурой. Ещё мне нравится OpenBSD - это ещё более классическая и упорядоченная ОС для отдельных задач, с упором на безопасность.

 

ну покажите пример использования тэгов pf из netgraph(ну или наоборот). ну или совместное использование тэгов pf и ipfw. т.е. в pf тэг на пакетик повесили, в ipfw по этому тэгу сделали какой-то action.

 

Вы же знаете, что теги действуют в пределах одного файерволла, зачем глупые вопросы?

 

это частный случай. давайте продолжим идею: после 1Мб скорость урезается в 2 раза, после 10мб - в 4 раза.

Я же уже говорил - одна очередь внутри другой, количество вложений вроде как явно не ограничено.

 

для SIP можете пример привести? я снова спрошу про SIP/H.323 и добавлю к вопросу PPTP.

Голосовым трафиком я не занимался - здесь ничего не могу сказать, а врать не хочу.

 

Что касается PPTP - выше приведен пример совместного использования pf и ipfw nat для PPTP. Можно всё НАТить ipfw nat.

[^rage^]

ну покажите пример использования тэгов pf из netgraph(ну или наоборот). ну или совместное использование тэгов pf и ipfw. т.е. в pf тэг на пакетик повесили, в ipfw по этому тэгу сделали какой-то action.

Вы же знаете, что теги действуют в пределах одного файерволла, зачем глупые вопросы?

вообще-то, ответ неверный. если вы считаете, что "в пределах одного фаерволла", то покажите пример использования тэгов pf из netgraph.

если чо, ipfw + ng_tag работают.

 

это частный случай. давайте продолжим идею: после 1Мб скорость урезается в 2 раза, после 10мб - в 4 раза.

Я же уже говорил - одна очередь внутри другой, количество вложений вроде как явно не ограничено.

а перемещать между очередями при достижении порога чем будете?

 

Что касается PPTP - выше приведен пример совместного использования pf и ipfw nat для PPTP. Можно всё НАТить ipfw nat.

оок. как узнать, к какому управляющему соединению(которое бегает по tcp.port==1723) относится запись в state table для ipfw?

ну и вообще, как получить state table ipfw nat/ng_nat?

(я уж молчу о манипуляциях со state table, вроде удаления/добавления записей).

[adsh]

если вы считаете, что "в пределах одного фаерволла", то покажите пример использования тэгов pf из netgraph.

pf !netgraph

 

а перемещать между очередями при достижении порога чем будете?

 

Есть очередь х со скоростью 100К. При прохождении 10 с скорость в ней автоматом зажимается до 20К. Помещаем в неё очередь у, у которой скорость автоматом зажимается через 5 с до 50к. Через 5 с общая скорость станет 50 к, через 10 - 20 к.

 

См. ещё вот такое: http://forum.lissyara.su/viewtopic.php?f=4&t=22145&start=0

 

оок. как узнать, к какому управляющему соединению(которое бегает по tcp.port==1723) относится запись в state table для ipfw?

 

Навскидку - ни как. Но, например, по trafshow сразу видно одинаковый адрес, к которому идёт туннель и TCP на 1723.

Изменено 29 июля, 2013 пользователем adsh

[andryas]

С завидной периодичностю на Наге возникает линуксрач.

Господа Линуксоиды, скажите пожалуйста, почему Вас так беспокоит Фряха? Откуда столько ненависти к другим платформам?

Я, например, очень редко использую линукс, ну так сложилось исторически, что практически любая задача у меня решается на FreeBSD, она мне ближе, понятнее.

Но несмотря на это я почему-то не прыгаю по линуксовским темам поливая оный поносом. Если Фря не нравится (не умеете?) - не юзайте. Но к чему все эти срачи?

[srg555]

потроллить бородатых фряхоадминов с ЧСВ over9000 всегда доставляет удовольствие

[^rage^]

если вы считаете, что "в пределах одного фаерволла", то покажите пример использования тэгов pf из netgraph.

pf !netgraph

я как бы в курсе, тем более вы утверждаете очевидное(как и ipfw !=netgraph).

но вы выше утверждали про интеграцию всего и вся, unix-way во freebsd итп штуки.

на деле - мы имеем сложную систему костылей и подпорок из разных подсистем, которые не особо между собой и дружат.

 

 

а перемещать между очередями при достижении порога чем будете?

Есть очередь х со скоростью 100К. При прохождении 10 с скорость в ней автоматом зажимается до 20К. Помещаем в неё очередь у, у которой скорость автоматом зажимается через 5 с до 50к. Через 5 с общая скорость станет 50 к, через 10 - 20 к.

вы про секунды, а я вам про мегабайты.

 

См. ещё вот такое: http://forum.lissyara.su/viewtopic.php?f=4&t=22145&start=0

 

 

оок. как узнать, к какому управляющему соединению(которое бегает по tcp.port==1723) относится запись в state table для ipfw?

во-первых, в приличных местах за ссылки на лисяру бьют канделябром. во-вторых, там про dummynet, а мы с вами вроде как про altq и hfsc говорили.

 

Навскидку - ни как. Но, например, по trafshow сразу видно одинаковый адрес, к которому идёт туннель и TCP на 1723.

trafshow - это через bpf и в юзерспейсе.

т.е медленно и пакетики могут теряться.

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

 

например, есть какой-то механизм нотификации в рамках kernel/userspace о появлении новой записи в state table?

[^rage^]

Господа Линуксоиды, скажите пожалуйста, почему Вас так беспокоит Фряха?

не беспокоит :) более того, в текущем проекте у меня больше фряхи, чем линуксов.

 

Откуда столько ненависти к другим платформам?

лично у меня её нет :) но вот смотрите, какая штука: сейчас linux - это целая индустрия. на него работают много талантливых программистов на full time.

потому и от GIANT LOCK'а там избавились раньше, хотя начали позже(потому что Ingo Molnar из redhat и снова на full time).

и RPS/XPS благодаря Tom Herbert, который так же на full time в Google. Я уж молчу о более продвинутых вещах, вроде возможности реконструкции сокетов(для того чтобы можно было "заморозить" процесс, сдампить в файл и потом восстановить целиком, вместе со всеми коннектами), которую сделал Pavel Emelyanov из parallels.

 

И когда появляются люди, которые говорят про академичность, университетские корни, дивные возможности и unix-way возникает, мягко говоря, недоумение.

 

Если Фря не нравится (не умеете?) - не юзайте. Но к чему все эти срачи?

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

Изменено 29 июля, 2013 пользователем ^rage^

[Ivan_83]

Ну и в чем его преимущество, если его лет 10 назад прикопать стоило?

Зачем ему приемущество?

Оно работает и всё, так же как хз сколько лет назад.

 

Или 10 лет назад в бзде не было альтернативы natd еще?

Хз, я на ней меньше.

 

100 мбит на каком-то п3 или аликсе пронатит? Аликсы к слову у буржуев в моде...

ХЗ, вероятно пронатить на 3ком или интелах.

 

Отключением isr?

Можно и так.

Кроме ISR есть ещё почти тоже самое только в нетграфе, насколько оно используется при работе mpd5 - не скажу, зависит от графа целиком, ибо отдельная нода может сама задействовать механизм очередей.

 

Лечим все болезни касторкой?

Конечно, ещё цианидом )

 

Отвечу вашими словами: ненужен был никому - вот и не было в ядре. Понадобился одному человеку - он и запилил ядреный пптп. Более 7 лет назад. Когда там у бзди mpd образовался?

То то линуксойды тут страдали и ставили фрю :)

 

Если все 18 лет до 2011 года бсд строилась на костылях и подпорках в совокупности с магическим тюнингом, фиксящим дефекты дизайна касторкой тупым добавлением памяти/увеличением буфферов в надежде "само рассосется" - с чего бы ситуации радикально поменяться за 2 года?

Раньше был мпд4 и статические интерфейсы.

Что было до него - я хз.

 

зевая... ну покажите пример использования тэгов pf из netgraph(ну или наоборот). ну или совместное использование тэгов pf и ipfw. т.е. в pf тэг на пакетик повесили, в ipfw по этому тэгу сделали какой-то action.

но вы выше утверждали про интеграцию всего и вся, unix-way во freebsd итп штуки.

на деле - мы имеем сложную систему костылей и подпорок из разных подсистем, которые не особо между собой и дружат.

cat /var/log/messages | grep warning | grep kernel

это юникс вей?

Почему тогда последовательная обработка пакетов в разных подсистемах это не юникс вей?

И нахера им надо дружить, когда свой функционал они и так выполняют?

 

потроллить бородатых фряхоадминов с ЧСВ over9000 всегда доставляет удовольствие

Мне только свитера нравятся, и то с замочком :)

[snvoronkov]

Не, ну это уже перебор.

 

Вот работает у меня три PPPoE терминатора на фре. uptime - 290 - 340 дней.

ISR отключен?

 

Да, забыл вчера написать. Оно на 7-ке работает. С патчем на ядро на предмет параллельного netisr. (Интересующиеся могут погуглить, но уже неактуально в связи с окончанием официальной поддержки 7-ой ветки).

 

На 8-9-ой версиях из-за дебильноватистого распараллеливания обработки на базе flow, да еще и странного параллелизма if_em/if_igb на конкретных мамах я получаю обработку всего почти в один поток для PPPoE.

Из пяти прерываний, занимаемых igb, почти всегда отрабатывает только одно. Да еще и только после примерно 20-процентного заполнения пакетной очереди.

 

Так-что, следующий шаг для аппаратной платформы, по всей видимости, будет на debian/accel-pptp.

 

А жаль. За годы оно там прижилось.