[pcap]О потере пакетов

350 мбит/сек

Канала памяти не хватит, чтобы такой поток гнать с карты, обрабатывать его и ещё вся остальная система работала.

>Канала памяти не хватит, чтобы такой поток гнать с карты, обрабатывать его и ещё вся остальная система работала.

Вроде канал в серверных платформах должно с головой хватать?
Если не так то как тогда в cisco sce это все тянеться ?

Вроде канал в серверных платформах должно с головой хватать?

Серверные платформы от домашних ноутбуков в плане скорости работы с памятью не очень сильно отличаются. Я не знаю, что такое cisco sce, но если это спец.железка (а не x86), то на то она и спец.железка.

libpcap сокет просто в raw-режиме открывает, что позволяет миновать netfilter, но с копированиями карта->ядро->юзерспейс он ничем не поможет. Юзерспейс->ядро->юзерспейс - переключения контекста, которые хоть и подешевели, но ещё совсем не бесплатные. Копирования непоследовательные и короткие, значит, память будет работать на скорости далеко от пиковой. Куча копирований одних и тех же данных на разных уровнях, значит, дели пропускную способность памяти на N.

Кроме того, проц будет синхронизировать кэш с памятью, дели ещё на два.

А ещё с принимаемыми данными ведь надо что-то делать, обрабатывать, вести статистику, etc...

x86 для high throughput совсем не годится. Особенно, если в качестве сетевой железки используется обычный ширпотреб с обычными драйверами.

Проблем в данном случае много. pcap сильно в кастомных случаях сможет справляться(у меня получалось pcap-ить 320Мбит, хотя можно было подоптимайзит и дотянуть думаю до 380-400), в общем случае нет.

2.Если она есть - то в чем ее фундаментальная причина?

Фундаментальная причина в том, что raw-сокет (который используется в недрах libpcap) не может препятствовать прохождению пакетов через сетевой интерфейс. Так что как только скорость потока пакетов превзойдёт производительность механизма, снифающего трафик (сокет в ядре, интерфейс ядро -> юзерспейс и собственно сама программа + libpcap), часть пакетов просто перестанет попадать в буфер raw-сокета, так как он будет переполнен.

Но решение этому есть :)

http://www.ntop.org/PF_RING.html

Опробовано... Работает шикарно :)

libpcap воде уже научилась через libnfqueue работать и тянуть данные в юзер спейс без копирования керне-> юзер. На сколько x86 справился тоже сложно сказать. И сильно зависит от того как фильтр pcap настроен. Скорее всего весь трафик именно не нужен, а нужна какая-то часть. Например входящий http. Тогда это можно соптимизировать.

изначально это и делалось через патченый pcap.
Пару лет назад я гонял тесты на 500-700 Мбитах... С тех пор много что изменилось :)

на мой взгляд в данном случае pcap излишен. Достаточно QUEUE (если надо пакеты возвращать обратно) или ULOG (если только считать/анализировать). Прелесть pcap в фильтрах, возможности сохранять и воспроизводить поток, а вам эти фичи ненужны. А без них - это просто обёртка со значительным лишним оверхедом.

Не могу лишь понять - насколько существенна проблема потеря pcap пакетов при нагрузке?

Она есть и этого достаточно

лучше написать модуль для NF который будет делать предобработку на месте, а в юзерспейс отсылать только агрегированные данные

>Проблем в данном случае много. pcap сильно в кастомных случаях сможет справляться(у меня получалось pcap-ить 320Мбит, хотя можно было подоптимайзит и дотянуть думаю до 380-400), в общем случае нет.

Что за кастомный случай был,можешь поподробней?

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

Про это я как то подзабыл(да и там будет хуже чем делить на N)

Я не знаю, что такое cisco sce, но если это спец.железка (а не x86), то на то она и спец.железка.

Здесь мне могут достать только тысячную версия а там тока до 1 гига держит - http://www.cisco.com/en/US/products/ps6151/index.html

>на мой взгляд в данном случае pcap излишен. Достаточно QUEUE (если надо пакеты возвращать обратно) или ULOG (если только считать/анализировать). Прелесть pcap в фильтрах, возможности сохранять и воспроизводить поток, а вам эти фичи ненужны. А без них - это просто обёртка со значительным лишним оверхедом.

А разве в ulog будет падать сам raw пакет для его последущей обработке?

(Сейчас просто система работает на анализе NetFLow и там не хватает возможности заглянуть в сам пакет чтобы по более умному его анализировать и отправить в соответсвующию очередь обслуживания)

>изначально это и делалось через патченый pcap.
Пару лет назад я гонял тесты на 500-700 Мбитах... С тех пор много что изменилось :)

А на сколько это лучше архитектурно чем pcap(просто мне это некоторые джедаи советовали посмотреть) -
http://www.ntop.org/PF_RING.html ?

>часть пакетов просто перестанет попадать в буфер raw-сокета, так как он будет переполнен.

А как в линуксе это посмотреть что происходит переполнение(только врублением всего сетевого в режиме глубоко дебага?) или какая часть инфы будет и так экспортироваться?

>лучше написать модуль для NF который будет делать предобработку на месте, а в юзерспейс отсылать только агрегированные данные

Сложноватенько это все честно говоря будет и времени больше чем надо будет займет(я хочу на постобработке сосредоточиться а не на механизмах копирования и тд и тп)

Сейчас уже не расскажу во всех деталях, но это было кастрированное ядро+ заточка под конкретную аппаратную платформу. Если это так сильно нужно, могу поискать в архивах какие-то наработки... Но вообщем-то посля этого «костыльного» решения как раз и был найден пф-ринг, который решал те же задачи но быстрее и лучше :) :)

А разве в ulog будет падать сам raw пакет для его последущей обработке?

да. С некоторыми ограничениями. Не попадает канальный уровень

>да. С некоторыми ограничениями. Не попадает канальный уровень

Oк. Мне нужно подсчитать сколько флоу жило по времени и длина тср и bpp.
А есть ли аналог в ФриБСД?

>Но вообщем-то посля этого «костыльного» решения как раз и был найден пф-ринг, который решал те же задачи но быстрее и лучше :) :)

А он щас что у тебя делает(какие нагрузки и тд) ?

Нет... Я занимался этим 3-4 года назад. С тех пор я уже дважды работу поменял :))))))

ULOG не панацея, тоже теряет пакеты.

Но само приложении ты писал с pcap но backend был pf_ring ?
Или юзал уже напрямую api pf_ring?

>ULOG не панацея, тоже теряет пакеты.

На каком потоке и железе?

Процессор VIA C3, тактовая частота вроде 600Mz. Поток 40 - 60 мбит, захватывали только первые 40 байт пакета. Точно не помню, давно было.

Конечно приложение на pcap'е... Я же не ССЗБ :)

>Процессор VIA C3, тактовая частота вроде 600Mz. Поток 40 - 60 мбит, захватывали только первые 40 байт пакета. Точно не помню, давно было.

Железка очень слабая для таких вещей + там сетувшка никакой из видов offloading не держит.

А насчет bpf (http://en.wikipedia.org/wiki/Berkeley_Packet_Filter ) - он вроде на порядок лучше чем стандартный linux в виду zero copy?

Для примитивных вещей pcap'а достаточно. Для больших нагрузок, и bpf не нужен :) Я так щитаю :) Но признаюсь сразу что с bpf дела не имел...