27.06.11 @ 18:15 Vadim Goncharov wrote:
22.06.11 @ 18:53 Oleg Cherevko wrote:
На данный момент ng_netflow, в силу его внутреннего устройства, до
этого идеала далеко. У него проблемы с broadcast- и multicast-трафиком,
с пакетами, отсеяными firewall'ом, с ipfw fwd, с локальным трафиком и,
С fwd можно справляться, навешивая ноду непосредственно на ng_ether, а
не через файрвол, и включая соответствующие флаги в конфигурации узла,
чтобы не считало дважды тот же трафик.
возможно, еще с чем-то, до чего я пока не добрался. Справедливости ради
следует сказать, что все вышеперечисленное обычно не является
определяющим в общем объеме трафика, так что ng_netflow для основного
трафика на машине без особых изысков в конфигурации -- вполне рабочий
инструмент. Но мне хочется перевести его из фазы "make it work" в фазу
"make it right", (ну а затем и в "make it fast", если понадобится).
Боюст, это опять потребует архитектурных изменений :)
Здесь я о том, что в архитектуре Cisco IOS, насколько мне известно,
netflow генерируется в одном месте, том же, которое занимается
непосредственно форвардингом, т.е. это просто экспорт состояния самого
движка, как если бы это были ipfw dynamic rules или pf states (хотя и это
- неточная аналогия). Во FreeBSD же ng_netflow "прилеплен сбоку" стека.
Не знаю, насколько это архитектурная особенность :) т.е. насколько
повредит сделать тег постоянным. Можно попробовать (эффекты, если что,
вылезут в других частях системы), если хочется, то вот решение:
исправить в /usr/src/sys/netgraph/netflow/ng_netflow.с и заменить строчку
mtag = m_tag_alloc(MTAG_NETFLOW, MTAG_NETFLOW_CALLED,
на
mtag = m_tag_alloc(MTAG_NETFLOW, MTAG_NETFLOW_CALLED |
MTAG_PERSISTENT,
Ну и как обычно, send-pr с соответствующим полем fix, особенно если
ничего не сломается.
Я тут подумал повнимательнее, в общем, сломать оно может разве что сам
netflow - а именно, если mbuf где-то реюзаются для других целей, то узлы
netflow с флагами *ONCE начнут этот трафик игнорировать, т.е. терять в
подсчетах. На стабильность системы никак повлиять не должно.
--
WBR, Vadim Goncharov
