Создание дампов TCP без потери пакетов

Как сделать дамп TCP, где гарантированно перехвачены все пакеты, которые действительно проходят через сеть, и ничего не пропущено?

Подробности: У нас проблема со сторонним поставщиком, который предоставляет решение поверх стека SCTP, которое он также реализует.
При довольно высокой пропускной способности (52 000 сообщений в секунду, средний размер сообщения составляет 500 байт), канал SCTP разрывается.
Мы считаем, что ошибка находится в стеке поставщика SCTP.
Но поставщик говорит, что это происходит потому, что стек SCTP отправляет сообщение, не получает ACK для него, отправляет несколько повторных передач, также не получает ACK для них и закрывает канал SCTP.
Поэтому продавец говорит, что виновата именно эта сеть, потому что она теряет пакеты.

В дампах TCP с обеих сторон, клиента и сервера, мы видим, что исходные сообщения достигают сервера, и что сервер не отвечает с помощью ACK. Но производитель говорит, что дампы TCP ненадежны, что при захвате дампа TCP некоторые пакеты могут быть не перехвачены, поскольку библиотека libpcap работает только в одном аппаратном потоке, ее мощности может быть недостаточно для регистрации всех пакетов.

Технические данные: 52 000 сообщений / с, средний размер сообщения - 500 байт, всего 26 МБ / с, используется 4 канала SCTP.
Аппаратное обеспечение: процессор E5-2670, 2,6 ГГц, 8 HW потоков
Сеть: 10 Гбит, трафик между блейд-серверами HP, расположенными в одной стойке.
РЕЛ 6.

Источник

1 ответ

На ваш объем трафика, я бы сказал, что libpcap не должен иметь проблем с отброшенными пакетами, если у вас нет особенно неэффективной настройки. Если вы используете tcpdump для захвата он сообщит количество пропущенных пакетов в своей последней строке вывода. Если вы видите потерянные пакеты, вы можете увеличить размер буфера tcpdump, предоставив -B возможность установить значение значительно выше, чем по умолчанию 2 МБ.

Тем не менее, вы можете посмотреть на PF_RING:

Кому нужен PF_RING™?

В основном каждый, кто должен обрабатывать много пакетов в секунду. Термин "многие" меняется в зависимости от оборудования, которое вы используете для анализа трафика. Он может варьироваться от 80 тыс. ПКТ / с на 1,2 ГГц ARM до 14M ПКТ / с и выше на низкочастотном Xeon 2,5 ГГц. PF_RING™ не только позволяет захватывать пакеты быстрее, но и захватывать пакеты более эффективно, сохраняя циклы ЦП. Просто чтобы дать вам некоторые цифры, вы можете увидеть, как быстро nProbe, тест NetFlow v5/v9, может использовать PF_RING™, или взглянуть на таблицы ниже.

10-гигабитные тесты, выполненные на Core2Duo 1,86 ГГц и младшем Xeon 2,5 ГГц

                                    ixgbe 
            Application                                 Rate 
pfcount (RX, with PF_RING™ DNA)        11 Mpps (Core2Duo), 14.8 Mpps (Xeon) 
pfsend (TX, with PF_RING™ DNA)         11 Mpps (Core2Duo), 14.8 Mpps (Xeon)

Руководство пользователя PF_RING объясняет, как скомпилировать и настроить библиотеки libpcap с поддержкой PF_RING, если вы настаиваете на использовании приложений libpcap для захвата пакетов.

Источник
Другие вопросы по тегам