Интересная поддержка NetFLow в OpenBSD

круть

Ъ

когда мне это понадобилось в линуксе - я был очень удивлен тому что его нет в iptables на равне с -j LOG

В linux netflow занимает унылое положение.

ПОдробнее - http://www.opennet.ru/opennews/art.shtml?num=17815

[linuxstyle] Так оно и не нужно. [/linuxstyle]

BSD R.I.P.

+1 :-)

>BSD R.I.P.

Хрена! IOS-капец. В цыцки будут БСД заливать :-)))

Закончились устройства, которые можно было бы добавить в OpenBSD, и они принялись за псевдоустройства? Похвально.

> когда мне это понадобилось в линуксе - я был очень удивлен тому что его нет в iptables на равне с -j LOG

iptables -j ULOG + fprobe-ulog

>Хрена! IOS-капец. В цыцки будут БСД заливать :-))

В циски теперь QNX заливают (вариацию на тему). А не ваше говноBSD.

> А не ваше говноBSD.

Оно не наше ни разу ;-)

Чем ng_netflow не устраивает?

Реквестирую пруф линк, ибо недавно из анабиоза.

>Чем ng_netflow не устраивает?

Может потому что его нет в OBSD?

Интересная новость :)

http://en.wikipedia.org/wiki/IOS-XR

>>Чем ng_netflow не устраивает? > Может потому что его нет в OBSD?

Ок, поменяем формулировку. Чем не устраивает FreeBSD + ng_netflow? =)

Ты че, ребята засмеют. FreeBSD сейчас слишком популярна и попсова.

>Ок, поменяем формулировку. Чем не устраивает FreeBSD + ng_netflow? =)

так можно докатится до формулировки: чем вас циска не устраивает или чем вас linux не устраивает. Или вы считаете что на FreeBSD мир заканчивается?

> когда мне это понадобилось в линуксе - я был очень удивлен тому что его нет в iptables на равне с -j LOG

Вообще, это можно тривиально реализовать на уровне ulogd. А вот в ядре такая штука точно не нужна.

Щет! Глаз "замылился". Прочитал как "Интересная поддержка NetOverFlow в OpenBSD"...

>В циски теперь QNX заливают (вариацию на тему). А не ваше говноBSD.

К сожалению оно не наше, я был бы рад жить на доходах от тех.поддержки *BSD;)

> так можно докатится до формулировки: чем вас циска не устраивает или чем вас linux не устраивает. Или вы считаете что на FreeBSD мир заканчивается?

нет, формулировка проста: OpenBSD не нужна, благо все её "прелести" имеются в других ОС, а прелестей других ОС она сама лишена.

Да вам ничего не надо, и все рип. А как в linux считать трафик нормально? Чтобы табличка:

дата-источник-получатель-количество_байт

Схемы с pcap и ULOG не предлагать.

ipcad+ulog. 300Мбит и не теряет. чем ulog не нравится ?

>чем ulog не нравится ?

1. Нагрузкой на процессор. Может ipcad ничего и не теряет, но игрушки начинают дёргатся.

2. Одна и таже работа делается дважды, одина раз в netfilter/conntrack второй раз в ipcad

3. Не нужное копирование данных из ядра в программу. (что также увеличивает нагрузку)

>3. Не нужное копирование данных из ядра в программу. (что также увеличивает нагрузку)

ipt-netflow - Netflow exporting module for Linux kernel
http://sourceforge.net/projects/ipt-netflow/
устраняет копирование лишних данных
можно собирать данные как из любой цепочки iptables из таблицы filter
так и в промиск режиме из таблицы raw
спокойно пережевала 700 Mбит

>ipt-netflow - Netflow exporting module for Linux kernel устраняет копирование лишних данных

Это да.

>можно собирать данные как из любой цепочки iptables из таблицы filter.

И опять получается двойная работа, так как трафик на flows делится и в conntrack и в этом модуле.

>так и в промиск режиме из таблицы raw

А у таблицы raw есть один недостаток (который основная фишка). Весь обрабатываемый ею трафик пролетает мимо conntrack и netfilter. То есть об одновременном учёте и statefull фильтрации можно забыть.

Подозреваю что это и есть причины, по которым этот модуль до сих пор не в netfilter / PoM

>нет, формулировка проста: OpenBSD не нужна, благо все её "прелести" имеются в других ОС, а прелестей других ОС она сама лишена.

Не вдаваясь в ваши глубокие знания OpenBSD и FreeBSD, например, чего есть аналогичного как вы выразились "прелестям" PF и ALTQ из OpenBSD(не будет их тут не будет и во FreeBSD). Этого вам хватит? А может не всем нужны все "прелести" одновременно и сразу в одном месте. Или фанатик применяет исключительно одну ОС во всех случаях?

Похоже, эта ОС реально развивается. Не то что ублюдочная и унылая говнофря.

>Похоже, эта ОС реально развивается. Не то что ублюдочная и унылая говнофря.
>Quasar

Аха - похоже опять жену с фряшником застукал ,)
Тебе бы надо Q вверхногами - чтоб было сразу понятно про рога ,)

>В цыцки будут БСД заливать :-)))

Обезьянам будет, на что мастурбировать?

LOR "В Linux появилась поддержка feature X" - Вааааау! Вендекапец, Лялих - рулиз.

"В {Open|Net|Free}BSD появилась поддержка Y" - RIP, ацтой!

"В {offtopic} сделали Z" - не надо, и ваще - это происки Билла!

Тошно читать вас, уроды. И именно поэтому Линукс будет всегда системой для гиков и красноглазых фанатиков и никогда не станет массовой ОС: ведь вы только и умеете что завидовать чужим успечам и сраться на форумах.

Товарищи, я так понимаю, что данная фича войдет в следующий релиз этой ОС который намечен на 1 ноября? Так оно?

нет не будет:

Although this won't be included with OpenBSD 4.4

ну ровно по тому, что 4.4 срезали 8 августа....

>Лялих

К логопеду, быдло!

в 4.4 не будет, поздно Хеннинг закоммитил, в карренте уже есть, неплохо так работает.

Насчет нужности такого дела в ядре были разговоры, но товарищи обещают добавить вскорости некий интересный функционал и особую интеграцию с пф, какие можно эффективно реализовать только в кернелспейс. Подробностей, увы, не знаю...

А про отсутствие "вкусностей", присущих только Опену, это явно от неосведомленности, хоть почитал бы... там много такого, что было перенято другими, и много такого, что неплохо было бы перенять

> И опять получается двойная работа, так как трафик на flows делится и в conntrack и в этом модуле.

-j NOTRACK

> А у таблицы raw есть один недостаток (который основная фишка). Весь
обрабатываемый ею трафик пролетает мимо conntrack и netfilter. То есть об одновременном учёте и statefull фильтрации можно забыть.

учите матчасть

raw — просматривается до передачи пакета системе определения состояний. Используется редко, например для маркировки пакетов, которые НЕ должны обрабатываться системой определения состояний. Для этого в правиле указывается действие NOTRACK. Содержит цепочки PREROUTING и OUTPUT.

http://ru.wikipedia.org/wiki/Netfilter

>Тебе бы надо Q вверхногами - чтоб было сразу понятно про рога ,)

+

>вы только и умеете что завидовать чужим успечам и сраться на форумах.

++

>1. Нагрузкой на процессор. Может ipcad ничего и не теряет, но игрушки начинают дёргатся.

задержка/потеря пакетов прявляется в случае -j QUEUE , т.к. ждет обработки. при -j ULOG при большой загрузке пакеты просто не успевают обработаться ipcadом, т.е. есть потеря учета, но потерь ip пакетов пока не видели.

>учите матчасть Читай внимательнее. Я знаю что есть raw и NOTRACK и написал про это.

Делая NOTRACK - отказываешься от conntrack. Да, теперь работа по разделению трафика на flows не дублируется (в считалке и в conntrack). Но без conntrack не работают ни nat и statefull правила!! (что разумеется не приемлимо).

Считалка трафика должна работать вместе с conntrack, а не вместо.