Если аппаратура сама умеет считать и отправлять куда нужно статистику, то конечно же всё будет хорошо.
Я про подсчёт сырого трафика средствами PCAP.
Вы ведь писали: «или tcpdump-а на офисном шлюзе».
Для малого офиса прокатит, а вот для большой сети вряд ли.
Также вангую, что если малый офис подвергнется DDoS атаке типа NTP amplification, то шлюз с запущенным tcpdump сразу склеит ласты.
Также, при определённых условиях любой из сотрудников малого офиса может положить торрентом шлюз с запущенным tcpdump.
Вот в чём дело:
«Сначала я хотел бы поделиться парой слов о том, как работает pcap — общеизвестный способ захвата пакетов. Он используется в таких популярных утилитах как iftop, tcpdump, arpwatch. Кроме этого, он отличается очень высокой нагрузкой на процессор.
Итак, Вы открыли им интерфейс и ждете пакетов от него используя обычный подход — bind/recv. Ядро в свою очередь получает данные из сетевой карты и сохраняет в пространстве ядра, после этого оно обнаруживает, что пользователь хочет получить его в юзер спейсе и передает через аргумент команды recv, адрес буфера куда эти данные положить. Ядро покорно копирует данные (уже второй раз!). Выходит довольно сложно, но это не все проблемы pcap.
Кроме этого, вспомним, что recv — это системный вызов и вызываем мы его на каждый пакет приходящий на интерфейс, системные вызовы обычно очень быстры, но скорости современных 10GE интерфейсов (до 14.6 миллионов вызовов секунду) приводят к тому, что даже легкий вызов становится очень затратным для системы исключительно по причине частоты вызовов.»
У нас уже больше года отлично работает.
PCAP — далеко не лучший выбор при большом количестве PPS.
Мы зеркалируем трафик на машину с Linux, на которой модуль ядра ipt_netflow считает трафик, и передаёт статистику для fastnetmon в формате NetFlow.
Я про подсчёт сырого трафика средствами PCAP.
Вы ведь писали: «или tcpdump-а на офисном шлюзе».
Для малого офиса прокатит, а вот для большой сети вряд ли.
Также вангую, что если малый офис подвергнется DDoS атаке типа NTP amplification, то шлюз с запущенным tcpdump сразу склеит ласты.
Также, при определённых условиях любой из сотрудников малого офиса может положить торрентом шлюз с запущенным tcpdump.
Вот в чём дело:
«Сначала я хотел бы поделиться парой слов о том, как работает pcap — общеизвестный способ захвата пакетов. Он используется в таких популярных утилитах как iftop, tcpdump, arpwatch. Кроме этого, он отличается очень высокой нагрузкой на процессор.
Итак, Вы открыли им интерфейс и ждете пакетов от него используя обычный подход — bind/recv. Ядро в свою очередь получает данные из сетевой карты и сохраняет в пространстве ядра, после этого оно обнаруживает, что пользователь хочет получить его в юзер спейсе и передает через аргумент команды recv, адрес буфера куда эти данные положить. Ядро покорно копирует данные (уже второй раз!). Выходит довольно сложно, но это не все проблемы pcap.
Кроме этого, вспомним, что recv — это системный вызов и вызываем мы его на каждый пакет приходящий на интерфейс, системные вызовы обычно очень быстры, но скорости современных 10GE интерфейсов (до 14.6 миллионов вызовов секунду) приводят к тому, что даже легкий вызов становится очень затратным для системы исключительно по причине частоты вызовов.»
habrahabr.ru/post/261161
PCAP — далеко не лучший выбор при большом количестве PPS.
Мы зеркалируем трафик на машину с Linux, на которой модуль ядра ipt_netflow считает трафик, и передаёт статистику для fastnetmon в формате NetFlow.
github.com/pavel-odintsov/fastnetmon/tree/master/src