Jump to content
Калькуляторы

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

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

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

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

 

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

Edited by SokolovS

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

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

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

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

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

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this