Столкнулись со следующей проблемкой...
Есть файл с сетевым трафиком, записанный tcpdump'ом. В нем 10 пакетов, из которых 9 пакетов длиной 40-60 байт, а 1 пакет с данными длиной 1000 байт.
Пробуем пулять данный трафик по 10 Гбитной оптике с хоста А на хост В при помощи tcpreplay на разных скоростях (от 2 Кбит до 3 Гбит/сек). Так вот порядок пакетов приходящий на хост В отличается от того, который в исходном трафике в зависимости от скорости передачи. Плюс пробовали сравнивать, что уходит с хоста А и там тоже порядок другой. На маленкой скорости вроде все ок, а на большой — порядок иной. Кто-нить сталкивался?
Здравствуйте, -prus-, Вы писали:
P>Всем привет!
P>Столкнулись со следующей проблемкой... P>Есть файл с сетевым трафиком, записанный tcpdump'ом. В нем 10 пакетов, из которых 9 пакетов длиной 40-60 байт, а 1 пакет с данными длиной 1000 байт. P>Пробуем пулять данный трафик по 10 Гбитной оптике с хоста А на хост В при помощи tcpreplay на разных скоростях (от 2 Кбит до 3 Гбит/сек). Так вот порядок пакетов приходящий на хост В отличается от того, который в исходном трафике в зависимости от скорости передачи. Плюс пробовали сравнивать, что уходит с хоста А и там тоже порядок другой. На маленкой скорости вроде все ок, а на большой — порядок иной. Кто-нить сталкивался? P>Заранее спасиб!
А что интересует-то? Причины, почему так происходит? Или что?
Вообще-то сеть оставляет за собой право нарушать порядок передачи пакетов. А также терять или дублировать их — для этого-то TCP и придумали.
Собственно, причина явления, описанного тобой, скорее всего, кроется в параллелизации — на малых скоростях данные передаются в одном потоке, на больших, например, плодится сразу куча потоков.
Здравствуйте, DOOM, Вы писали:
DOO>Собственно, причина явления, описанного тобой, скорее всего, кроется в параллелизации — на малых скоростях данные передаются в одном потоке, на больших, например, плодится сразу куча потоков.
Да, прошу прощения, забыл написать, что нужно...
А нужно нам собственно добиться ситуации, чтобы пакеты отправлялись и принимались в той последовательности, в которой они расположены в файле.
По поводу кучи потоков мы примерно поняли...
Драйвера стоят ixgbe. ОС RHEL 6.1 и SLES. Пробовали отключать MultiQueue (modprobe MQ=0...), но эффекта не получили. Или тут имеются ввиду другие потоки?
Здравствуйте, -prus-, Вы писали:
P>Здравствуйте, DOOM, Вы писали:
DOO>>Собственно, причина явления, описанного тобой, скорее всего, кроется в параллелизации — на малых скоростях данные передаются в одном потоке, на больших, например, плодится сразу куча потоков.
P>Да, прошу прощения, забыл написать, что нужно... P>А нужно нам собственно добиться ситуации, чтобы пакеты отправлялись и принимались в той последовательности, в которой они расположены в файле.
Непонятно только, зачем. Оно должно уметь само с такими проблемами справляться.
P>По поводу кучи потоков мы примерно поняли... P>Драйвера стоят ixgbe. ОС RHEL 6.1 и SLES. Пробовали отключать MultiQueue (modprobe MQ=0...), но эффекта не получили. Или тут имеются ввиду другие потоки?
Отключали на обеих сторонах?
Вообще это вряд ли в драйвере сетевухи, вероятнее — где-то в IP стеке в политике выходных очередей.
TC используется?
Здравствуйте, netch80, Вы писали:
N>Непонятно только, зачем. Оно должно уметь само с такими проблемами справляться.
Да вот то ли мы не понимаем чего, то ли не справляется само.
N>Отключали на обеих сторонах? N>Вообще это вряд ли в драйвере сетевухи, вероятнее — где-то в IP стеке в политике выходных очередей. N>TC используется?
Нет, сами мы Traffic Control не настраивали. Все по умолчанию. Просто подняли 2 интерфейса и пуляем трафик. Особо ничего не настраивали, кроме как поигрались с Multi Queue, но эффекта нету.
Пока проблема не решена.
Здравствуйте, -prus-, Вы писали:
N>>Непонятно только, зачем. Оно должно уметь само с такими проблемами справляться. P>Да вот то ли мы не понимаем чего, то ли не справляется само.
В чём это выражается? TCP глючит или тормозит?
N>>Отключали на обеих сторонах? N>>Вообще это вряд ли в драйвере сетевухи, вероятнее — где-то в IP стеке в политике выходных очередей. N>>TC используется? P>Нет, сами мы Traffic Control не настраивали. Все по умолчанию. Просто подняли 2 интерфейса и пуляем трафик. Особо ничего не настраивали, кроме как поигрались с Multi Queue, но эффекта нету. P>Пока проблема не решена.
Тогда уточните постановку задачи. Где точки контроля и что в них видно?
А именно, где какой порядок виден в точках
1) tcpdump на A на выходе в сторону B (из исходного письма непонятно, что там)
2) tcpdump на B на входе со стороны A (там нарушено?)
Где исходная генерация посылки — на A или ещё где-то до A?
Здравствуйте, netch80, Вы писали:
N>Тогда уточните постановку задачи. Где точки контроля и что в них видно?
Вроде поняли почему так...
Вобщем нас смутил тот факт, что Wireshark, которым проверяем трафик, показывал нам tcp retransmission пакеты. Мы просто сессию из 10-ти пакетов пуляем в цикле покругу и там получаются одинаковые идентификаторы в IP-заголовке. Из-за этого нам Wireshark показывает все немного в измененном виде. Сразу не обратили внимание на это. Сейчас попробуем использовать tcpreplay-edit и видоизменять трафик подготовленный. Все равно спасиб.
