>> Для начала посмотрите на дату ссылки. С тех пор все значительно упростилось.
> Ну тогда давайте без пустого теоретизирования. Расскажите или напишите статью, как собирать Netflow с сетевого интерфейса с помощью Netgraph более простым способом, чем описано в данной статье.

Далеко ходить не будем
http://www.slashtmp.ru/2009/05/06/tag-ng_netflow/
http://www.slashtmp.ru/htmlart/unix/pres-ngnetflow.xml#23
http://www.slashtmp.ru/htmlart/unix/pres-ngnetflow.xml#24

>> Хотите простую утилитку для этого - напишите. Просто большинству удобнее написать простенький shell-скрипт, чем дописывать никому не нужный функцианал в ifconfig.
> Большинству удобнее вообще никаких скриптов не писать, а прочитать руководство и настроить. В маршрутизаторах Juniper при наличии той же FreeBSD почему-то не нужно на каждый чих писать скрипты, достаточно ввести несколько команд и сохранить конфигурацию. Разработчикам, видимо, лень один раз написать пару десятков строк на C, чтобы все остальные потом не писали сотни строк на shell. Простеньким предлагаемый shell-скрипт будет для одного интерфейса. А если нужно считать не весь трафик, а только с определенных IP (из таблицы в ipfw или pf)? И снимать трафик не с одного интерфейса, а с трех. Это будет далеко не простенький шелл-скрипт, нужно перелопатить всю топологию нод и связей. Вот тут Netgraph и покажет свою избыточную сложность. При этом в OpenBSD или Linux задача сведется к изменениям в правилах файрвола.

Собсно кто мешает использовать ng_ipfw+ng_netflow

>> GEOM и Netgraph - хороший фреймворк для написания подсистем ядра и не более того.
> Netgraph неудобен для решения простых задач из-за того, что функционал слишком размазан по отдельным нодам. При этом необходимо все время конфигурировать связи между нодами, хотя в абсолютном большинстве практических применений связи будут одними и теми же. Яркие примеры -- mpd и тот же сбор Netflow. Городить в ядре гибкость и создавать лишний overhead ради решения одной-двух нестандартных задач -- это неверный подход.

Еще раз отмечу, netgraph - это фреймворк. К сожалению он пока еще не  велик, ибо большая часть написана для того же mpd.

> Никто же не жалуется что большинство систем *BSD написано с использованием инфраструктуры сокетов. Сокеты тоже хороший фреймворк.
> Хороший-то хороший, но сокеты были введены в связи с отсутствием поддержки сети в Unix. Как показано в Plan 9, они избыточны, и можно все свести к чтению-записи файлов.

Возможно. Можно ведь и перевести все на ioctl как в линуксе. Но в обозримом будущем никто не будет этим заниматься. Но, ИМХО, интерфейс сокетов значительно удобнее интерфейса VFS.