Как сделать дамп TCP, где гарантировано, что все пакеты, которые действительно проходят по сети, захвачены, и ничего не пропущено?
Подробности: у нас есть проблема со сторонним поставщиком, который предоставляет решение поверх стека SCTP, которое он также реализует.
При достаточно высокой пропускной способности (52 000 сообщений / сек, средний размер сообщения 500 байт) канал SCTP разрывается.
Мы полагаем, что ошибка находится в стеке SCTP поставщика.
Но производитель говорит, что это происходит потому, что стек SCTP отправляет сообщение, не получает на него ACK, отправляет несколько повторных передач, также не получает ACK и закрывает ссылку SCTP.
Производитель говорит, что виновата именно сеть, потому что она теряет пакеты.
В дампах TCP с обеих сторон, клиента и сервера, мы видим, что исходные сообщения достигают сервера, и видим, что сервер не отвечает ACK. Но производитель говорит, что дампы TCP ненадежны, что при захвате дампа TCP некоторые пакеты могут быть не захвачены, поскольку библиотека libpcap работает только в одном аппаратном потоке, ее мощности может быть недостаточно для регистрации всех пакетов.
Технические данные: 52 000 сообщений / сек, средний размер сообщения 500 байт, итого 26 МБ / сек, используются 4 канала SCTP.
Аппаратное обеспечение: CPU E5-2670, 2,6 ГГц, 8 потоков HW
Сеть: 10 Гбит, трафик между блейдами HP, которые расположены в одной стойке.
RHEL 6.
При вашем объеме трафика я бы сказал, что у libpcap не должно быть проблем с отброшенными пакетами, если у вас нет особенно неэффективной настройки. Если вы используете tcpdump для захвата он сообщит количество потерянных пакетов в своей последней строке вывода. Если вы видите отброшенные пакеты, вы можете увеличить размер буфера tcpdump, указав то -B вариант чтобы установить значение, значительно превышающее значение по умолчанию 2 МБ.
Тем не менее, вы можете захотеть взглянуть на PF_RING:
Кому нужен PF_RING ™?
Практически все, кому приходится обрабатывать много пакетов в секунду. Термин «многие» меняется в зависимости от оборудования, которое вы используете для анализа трафика. Он может варьироваться от 80 тыс. Пакетов в секунду на ARM с тактовой частотой 1,2 ГГц до 14 млн пакетов в секунду и выше на процессорах 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 для захвата пакетов.