Firewall блокирует out of order TCP-пакеты?

А почему ты решил что у тебя много пакетов не по порядку? я думаю это редкость, тем более в локалке когда маршрут один.

Доступ по ssh/telnet в этот ящик есть?

Доступ по ssh есть, как я и писал, правда линукс там обрезанный и поставить доп. инструментарий туда вряд ли получится, так что придется обходиться тем,что есть.

А почему ты решил что у тебя много пакетов не по порядку?

Посмотрел wireshark'ом. Попробую объяснить на пальцах, что я увидел.

Есть оптика, которая пережила несколько экскаваторов, сервер на одном конце, хост и фаерволл на другом.

1. Сервер и хост в одном широковещательном домене. Сервер посылает пакеты: 1,2,3,4,5. Хост получает 1,5, начинает спамить dup ack'ами для второго пакета, получает 2-ой (wireshark пишет Fast retransmission),и тут же 3 и 4 (wireshark пишет Out of order, видимо потому, что 5-ый уже пришел)

2. Сервер и хост разделены фаерволлом (он маршрутизирует пакеты между разными вланами). Хост видит пакеты 1,5, шлет dup ack'и для 2-го, получает 2-ой и тишина. Примерно через 200 мс поступают 3 и 4, wireshark пишет просто TCP retransmission

Самое главное забыл. В первом случае скорость, несмотря на потери, упирается в пропускную способность интерфейса (там 100 мбит/с через медиаконвертеры), во втором - 20-30, видимо из-за пауз в передаче.

да, похоже что там шибко «умная» железка. А в панели управления нет никаких рычагов? Например, «защита от атак», я на роутерах видел неадекватное поведение защиты. Вообще, почему бы не поставить нормальную ОС на ящик или не заменить ящик нормальным компом?

кстати, на сервере ты можешь тоже крутить настройки tcp чтобы, например, уменьшить паузу на ретрансмит. Не знаю чем это скажется для инета, а для локалки нормально.

Кстати, проверь sysctl. Всякие net.ipv4.tcp_reordering итп.

Вот ещё может помочь: http://serverfault.com/questions/287475/why-does-my-gigabit-bond-not-deliver-...

А в панели управления нет никаких рычагов?

Я через ssh полез не от хорошей жизни ;)

Вообще, почему бы не поставить нормальную ОС на ящик или не заменить ящик нормальным компом?

Этот «программно-аппаратный комплекс» должен быть сертифицирован ФСБ.

Вот ещё может помочь:

Ха, я половину уже сделал. Надо будет попробовать вторую. Но лично я сомневаюсь, что увеличение буферов поможет, если роутер пакеты режет еще на входе. Я вот и хотел узнать точную причину: то ли буферов не хватает, то ли пакеты режет...

можно попробовать написать на ящик саппорту

Саппорт уже больше полугода чешет бороду в попытках заставить кластер из 2-х восьмиголовых(!) ксеонов выдать 1Гбит/с через IPSec.

Меня терзают смутные сомнения, что проблема как-то связана с отслеживанием соединений, ну должен же ФВ этим заниматься. Не подскажешь, какие способы в линуксе для этого есть (тут не через iptables сделано), а то я даже не знаю, как запрос в гугл сформулировать...

А может быть Вам с другого конца зайти, сделать так, чтобы пакеты меньше терялись? Судя по всему по оптике Вы больше 100 мбит пропустить не можете. Дак может быть Вам зажать скорость на интерфейсах маршрутизатора? На том интерфейсе, который смотрит в медиаконвертер. У медиаконвертера короткая очередь пакетов, они просто могут теряться.

какие способы в линуксе для этого есть

Например, через то что использует tcpdump - libpcap. Это специальная либа для достаточно изощрённого мониторинга трафика. А что top показывает на железке?

Кстати, плюсую ansky, лучше не ящик ковырять, а каналы починить. tcp retransmit через netstat можно посмотреть - там будет статистика по пакетам. И на интерфейсах можно посмотреть потери.

Все оказалось гораздо хуже, оказывается, сервер не всегда посылает эти пакеты. Я запустил wireshark на хосте и сервере:

1. Когда они в одной подсети (т.е. без фаерволла) сервер в ответ на dup ack для 2-ого пакета самостоятельно перепосылает 3 и 4. Это видно из захваченных пакетов непосредственно на сервере.

2. Когда они в разных подсетях, сервер перепосылает только 2-ой, а 3-ий и 4-ый - только по таймауту. В чем может быть причина такой избирательности?

А может быть Вам с другого конца зайти, сделать так, чтобы пакеты меньше терялись?

Я бы рад, но тут подход «работает - и ладно». Это у меня перфекционизм чешется.

Update:

для второго случая (с разными подсетями): хост флудит dup ack'ами для 2-ого пакета, сервер перепосылает его, хост получает, начинает слать dup ack'и для 3-его, сервер их получает (все 38 штук), но не реагирует на них, а отсылает их только через 200 мс.

Сервер на линуксе

[root@localhost ~]# netstat -s -v
Ip:
    60645992 total packets received
    54440181 forwarded
    0 incoming packets discarded
    4157301 incoming packets delivered
    57636167 requests sent out
    75505 outgoing packets dropped
Icmp:
    20389 ICMP messages received
    0 input ICMP message failed.
    ICMP input histogram:
        destination unreachable: 286
        echo requests: 20098
        echo replies: 5
    95994 ICMP messages sent
    0 ICMP messages failed
    ICMP output histogram:
        destination unreachable: 343
        redirect: 75505
        echo request: 48
        echo replies: 20098
IcmpMsg:
        InType0: 5
        InType3: 286
        InType8: 20098
        OutType0: 20098
        OutType3: 343
        OutType5: 75505
        OutType8: 48
Tcp:
    18 active connections openings
    136 passive connection openings
    0 failed connection attempts
    63 connection resets received
    1 connections established
    4136721 segments received
    3088494 segments send out
    86812 segments retransmited
    0 bad segments received.
    8 resets sent
Udp:
    190 packets received
    1 packets to unknown port received.
    0 packet receive errors
    191 packets sent
UdpLite:
TcpExt:
    18 TCP sockets finished time wait in fast timer
    1936 delayed acks sent
    Quick ack mode was activated 4 times
    167 packets directly queued to recvmsg prequeue.
    102 packets directly received from prequeue
    305120 packets header predicted
    2054976 acknowledgments not containing data received
    1602815 predicted acknowledgments
    10294 times recovered from packet loss due to fast retransmit
    8764 times recovered from packet loss due to SACK data
    27 congestion windows recovered after partial ack
    18456 TCP data loss events
    TCPLostRetransmit: 80
    5181 timeouts after reno fast retransmit
    95 timeouts in loss state
    38020 fast retransmits
    21 forward retransmits
    33692 retransmits in slow start
    193 other TCP timeouts
    TCPRenoRecoveryFail: 9575
    8 connections aborted due to timeout
    TCPSackShifted: 49626
    TCPSackMerged: 24156
    TCPSackShiftFallback: 55567
IpExt:
    InNoRoutes: 15
    InMcastPkts: 11743
    InBcastPkts: 1676809
    InOctets: 45550846719
    OutOctets: 53762783325
    InMcastOctets: 375776
    InBcastOctets: 142678693

В чем может быть причина такой избирательности?

хз, настолько сильно я сырцы ядра не копал. Но можно сравнить дампы и посмотреть чем отличаются сессии. Думаю, не хватает опции SACK на втором сервере, проверь настройки tcp.

Блин, мужик, ты реально гуру. Оказывается, фаерволл выкидывает опцию SACK из параметров tcp-сессии. Без тебя я б еще пару недель думал, в чем тут дело, мне честно не пришло в голову сюда глянуть. Спасибо огромное, теперь хоть есть что техподдержке предъявить.

Как я понял, у вас случаи «в одной подсети» и «в разных подсетях» отличаются каналообразующим оборудованием, так как "(там 100 мбит/с через медиаконвертеры)".

Вы полностью не описали все стыки в том и другом случае, хотя вам писали, что у конвертора может быть маленький буфер пакетов и т.д.

А причина избирательности, возможно, объяснена в файле /usr/src/linux/Documentation/networking/tcp-thin.txt . Там написано, что ядро выделяет «тонкие» потоки модифицирует для них алгоритм Fast retransmission, может быть это ваш случай. Ещё в описании алгоритмов tcp в ядре linux говорится о том, что ядро постоянно оценивает RTT для tcp-сесии и это тоже, вроде, влияет на включение Fast retransmission.

Я надеюсь, что вы убедились в идентичности параметров tcp-соединения (например, размер окна) для двух ваших случаев.

И у вас действительно из пяти пакетов доходят только первый и пятый или вы где-то специально их дропаете? Потому что, если у вас с данными проходят только выборочные пакеты, а dup ack проходят все, то может попробовать просто снизить MTU (MSS).

Как я понял, у вас случаи «в одной подсети» и «в разных подсетях» отличаются каналообразующим оборудованием

Да, наверно стоило упомянуть, что клиентскую машину я перекидывал, просто меняя ip-адрес и влан на порту свитча, так что каналообразующее оборудование не менялось(ну за исключением фаерволла)

Я надеюсь, что вы убедились в идентичности параметров tcp-соединения (например, размер окна) для двух ваших случаев.

Нет, в этом была моя ошибка и, как выяснилось, причина такого загадочного поведения

И у вас действительно из пяти пакетов доходят только первый и пятый или вы где-то специально их дропаете?

Где-то на оптике пачками по 2-5 штук пропадают.