Как лучше организовать сбор neflow

[SokolovS]

Есть варианты.

1. Щейпящий бридж через который идет транзит, на нем есть доп. сетевая карта не входящая в состав бриджа. На FORWARD вешаем действие NETFLOW, трафик благополучно бежит на коллектор.

2. На совсем отдельный сервер отмиррорить трафик, в promisc режиме его ловить и коллектор разместить на этой же машине (127.0.0.1)

 

Какой из вариантов лучше?

[Ivan Rostovikov]

лишняя машина = лишняя точка отказа.

делайте 1-й вариант если производительность позволяет

[SokolovS]

Ну тогда если вопрос поставить так. Коллектор все равно стоит уже на отдельной машине, что лучше, делать на него миррор или слать флоу-данные с бриджа? P.S.: Потеря данных при простое не так критична, скорее важна производительность решения.

Edited May 26, 2010 by SokolovS

[Zaqwr]

Потеря данных при простое не так критична, скорее важна производительность решения.

сколько летит на бридже ? что за машинка шейпит ? а вообще если уже есть коллектор, то на нем и собирайте flow

[SokolovS]

На бридже порядка 300 Мбит, в перспективе на конец года 500. Шейпит обычный сервант на Intel 3000AH, проц Intel Core Quad CPU Q6700. PPS 45-50k. Справляется пока, загрузка 15-20%. Будет мало, возьмем ксеончик или еще что посвежее.

 

а вообще если уже есть коллектор, то на нем и собирайте flow

Т.е. все таки вариант 1?

[Ilya Evseev]

Моё IMHO - зеркалирование не нужно.

Во-первых, если входящий+исходящий в сумме >1Gbit/s, зеркалировать их придётся не на один порт, а на два.

Во-вторых, если зеркалируется ~1Gbit/s, на сервере-приёмнике придётся выделять отдельный физический интерфейс (или два).

Порты на коммутаторе не бесплатны.

Серверы не резиновые.

 

Раньше зеркалирование ещё имело смысл, когда счётчики работали через divert-сокеты в usermode, а потоки были до 100mbps. Перенос счётчика на отдельный компьютер не требовал дополнительных портов, повышал быстродействие шлюза и убирал с него точку отказа, т.е. при падении счётчика клиенты по крайней мере не оставались без Интернета. Теперь ngnetflow и ipt_netflow ресурсов потребляют немного, не глючат, поэтому особого смысла убирать их со шлюза больше нет.

[SokolovS]

Спасибо за доводы, так и сделаем.