[hiller]

Краем уха слышал, что ng_netflow можно повесить на родительский интерфейс и снимать данные о проходящем трафике в каждом из VLANов, которые есть на физическом интерфейсе.

Это вместо того, чтобы делать отдельную настройку для каждого VLANа.

 

Не подскажите, как такое делается, желательно с примером?

 

ps Сильно не пинайте, я дуб во freebsd :(

[zed_0xff]

нельзя.

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

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

ибо входящие ядро "развиланивает" :) мимо нетграфа, и они сразу попадают на интерфейсы vlanXXX.

 

варианты решения проблемы:

1) забить и считать только в одну сторону

2) развиланивать трафик внутри нетграфа через ng_vlan. как он по производительности в сравнении с решением через ifconfig - хз. не пробовал.

3) (imho оптимальный вариант) поднять в качестве коллектора отдельный тазик. причем можно уложиться в 8 т.р. и десктопное железо :) но по железу это уже каждый сам решает..

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

 

наглядный результат оптимизации ng_netflow :)

 

[Giga-Byte]

проверил в 7.0-RELEASE, в ng_netflow есть проверка на тип кадра,

тоесть можно прицеплять к физическому интерфейсу и будет нормально

 

 

[zed_0xff]

если ifIndex не важен - то можно,

а если надо сохранять в ifIndex номер влана - то надо патчить.

ну и опять же если это роутер - то трафик будет только в одну сторону считаться. проверено на 7.1

[netmonster]

использую связку ng_ipfw+ng_netflow

и два правила в ipfw

[Giga-Byte]

если ifIndex не важен - то можно,

а если надо сохранять в ifIndex номер влана - то надо патчить.

какой к черту ifIndex, небыло про него ни слова

 

ну и опять же если это роутер - то трафик будет только в одну сторону считаться. проверено на 7.1

бред, можно научить.

а начиная с 7.2, насколько я понял, работает "из каропки" © не помню кто.

 

а вообще можно сбор нетфлоу перенести на отдельную машину и завернуть туда копию порта uplink-a

Изменено 11 октября, 2009 пользователем Giga-Byte

[zed_0xff]

какой к черту ifIndex, небыло про него ни слова

поспокойнее.

 

ну и опять же если это роутер - то трафик будет только в одну сторону считаться. проверено на 7.1

бред, можно научить.

научите, люблю узнавать что-то новое.

 

а начиная с 7.2, насколько я понял, работает "из каропки" © не помню кто.

ну, то что "© не помню кто" - это конечно всё меняет!

а сами пробовали?

я вот только что попробовал, специально думаю, вдруг починили и всё ок.

ан нет - как было в одну сторону так и есть.

 

ifconfig vlan10 create
ifconfig vlan10 vlandev em0 vlan 10
ifconfig vlan10 10.10.0.2/24

ngctl mkpeer em0: tee lower left
ngctl name em0:lower tee0
ngctl conn em0: tee0: upper right

 

напускаем в em0 тэгированного трафика, либо смотрим на живом роутере. результат один и тот же:

 

смотрим "nghook -a tee0: left2right" - трафик есть.

 

смотрим "nghook -a tee0: right2left" - трафика нет!!

 

а вообще можно сбор нетфлоу перенести на отдельную машину и завернуть туда копию порта uplink-a

о чем я и писал во 2-м сообщении этой темы.

[XeonVs]

а почему так не сделать:

        mkpeer vlan3: netflow lower iface0
        name vlan3:lower netflow
        connect vlan3: netflow: upper iface1
        connect netflow: netflow: out0 out1

? будет в обе стороны.

 

и это без поддержки egrees которая в ng_netflow в 7-ST имеется.

Изменено 12 октября, 2009 пользователем XeonVs

[zed_0xff]

а почему так не сделать:

        mkpeer vlan3: netflow lower iface0
        name vlan3:lower netflow
        connect vlan3: netflow: upper iface1
        connect netflow: netflow: out0 out1

? будет в обе стороны.

 

и это без поддержки egrees которая в ng_netflow в 7-ST имеется.

так и было, но при 200 с лишним вланах это начинает выглядеть примерно так:

(кликабельно)

 

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

 

как бы очень очевидно что в такой ситуации решение со всего одним соединением физический_интерфейс <-> ng_netflow выглядит гораздо более идеологически правильным и красивым, нежели как минимум количество_вланов*2 соединений (а то и больше, учитывая что считать трафик надо в обе стороны)

[XeonVs]

так у вас все на tee было завязано, отсюда и эта ромашка.

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

 

идея с патчем "номер влана == номеру ифейса в нетфлоу" вполне хороша, кому-то может и пригодится.

[Giga-Byte]

ну и опять же если это роутер - то трафик будет только в одну сторону считаться. проверено на 7.1

бред, можно научить.

научите, люблю узнавать что-то новое.

да вы знаете. только не понял, зачем это написали.

 

а начиная с 7.2, насколько я понял, работает "из каропки" © не помню кто.

ну, то что "© не помню кто" - это конечно всё меняет!

а сами пробовали?

я вот только что попробовал, специально думаю, вдруг починили и всё ок.

ан нет - как было в одну сторону так и есть.

проверил, признаю, "из каропки" не работает.

 

[Giga-Byte]

а почему так не сделать:

        mkpeer vlan3: netflow lower iface0
        name vlan3:lower netflow
        connect vlan3: netflow: upper iface1
        connect netflow: netflow: out0 out1

? будет в обе стороны.

 

и это без поддержки egrees которая в ng_netflow в 7-ST имеется.

оно учитывается, только не в разных направлениях:

ingress && egress:

lagg0 192.168.1.11 vlan100 192.168.1.30 1 0000 0000 6

это 3 пинга. тоесть запрос-ответ 3 раза = 6 пакетов

 

только ingress:

lagg0 192.168.1.11 vlan100 192.168.1.30 1 0000 0000 3

 

может, попробовать разобраться?

Изменено 13 октября, 2009 пользователем Giga-Byte