"Подсчет трафика с netgraph (http://www.tux.in.ua/articles/969)" - использование netgraph модулей ng_tee и ng_netflow для учета трафика во FreeBSD.URL: http://www.tux.in.ua/articles/969
Новость: http://www.opennet.ru/opennews/art.shtml?num=19181
Законный вопрос зачем в этой ситуации ng_tee?ng_tee копирует данные, да и потом еще в довесок one2many - процессорное время девать чтоли некуда.
ng_netflow отлично вещается непосредственно на интерфейс. Для учета входящего и исходящего трафика достаточно просто задействовать две пары хуков ng_netflow.
> Для учета входящего и исходящего трафика достаточно просто задействовать
> две пары хуков ng_netflow.Сам-то пробовал? А попробуй.
Но статья -- действительно, дурь полная. Видимо, man по ng_split так никто почитать и не удосужится...
Если это роутер ng_netflow c несколькими интерфейсами, то вешаем на разные интерфейсы, при это надо учесть направление движение трафика, если интерфейс один то вместо ng_tee два ng_split:mix'ы сплитов подключам к upper и lower; крюк in каждого сплита соединяется с крюком out через пары ifaceX outX ноды ng_netflow.
В конце концов есть ng_ipfw, но в любом случае ng_tee использовать не надо в тем более one2many.
> Если это роутер ng_netflow c несколькими интерфейсами, то вешаем на разные интерфейсыНет. (C)
Учёт траффика будет работать неправильно при наличии адресной трансляции.
Я бы не стал так категорично. Особено если учесть, что автор заметки не описал топологию сети, которую планируется считать.Про NAT речи не идёт, да и то все зависит от того где и что надо считать.
Пример:
роутер c "нетранзитной" AS, 3 интерфейса: два на провайдера и один смотрит на DMZ; обсчитываем DMZ.Соответвтенно на "провардерских" интерфейсах считаем в одном направлении, на "локальном" в другом. Все замечательно посчитается за исключением трафика (в одну (любую) строну) генерируемого самим этим роутером, однако что кроме BGP должен генерить внешний гейт.
Пример два:
Внешний гейт с NAT и несколькими NAS в DMZ . На внешнем гейте у нас есть NAT; задача считать клиентов NAS.Соответственно если обсчитывать пользователей NAS, то вещаем ng_netflow на интерфейс внешнего роутера смотрящего на NAS и на самих NAS, понятно что NAS'ах и роутере трафик считается в разном (встречном) направлении.
Описанное выше кстати решает проблему подсчета дважды межабонентского трафика.
Одним словом все зависит от задачи.
Мммм.... А можно примерчик для учета входящего и исходящего трафика только через ng_netflow без использования ng_tee? Чисто для общего образования - у меня у самого сделано через ng_tee (хотя, конечно, и без one2many - зачем его заюзали - вообще не понятно) и сделать только через ng_netflow сходу не соображу. И не видел нигде никогда подобных примеров... Собственно, вроде непосредственно в man'е и то через tee Было...
>Мммм.... А можно примерчик для учета входящего и исходящего трафика только через
>ng_netflow без использования ng_tee?Пример есть в мане (работает только с 6.0, во FreeBSD v5.x без ng_tee нельзя никак).
Однако, при наличии адресной трансляции учёт траффика будет неправильным.
А в чем разница между netflow и ng_netflow? Какие преимущества?
netflow это общее название протокола.
ng_netflow реализация в freebsd средствами netgraph.
Оно-то понятно. Но какая разница в том, что я, используя flow-tools(как пример) буду снимать с цисок статистику через netflow, либо то же самое, но используя flow-tools-ng и ng_netflow? Получу ли я в чем-то выигрыш за счет использования netgraph?
Речь идет о случае, когда netflow снимается не с цисок, а с роутера под FreeBSD - для этого и нужен ng_netflow.
Упс, понятно. Спасибо за ликбез.
По моему вы неправы..
ng - наверно от next generation
Это форк от flow-tools