Перейти к содержимому
Калькуляторы

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

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

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Изменено пользователем SokolovS

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.