r422: сервер не видит попыток соединения от клиента

[san]

У пользователя два блока:

• 3U с платой VE-02(ревизия 18) и модулем r422
• Vip(r1740) с модулем r422

Между блоками организовано соединение через Ethernet(спутниковый канал) и передаются/принимаются данные r422 через это соединение.

Периодически у пользователя проявляется странное поведение этой системы: во время работы(передачи данных) соединение разрывается, клиент делает попытки соединиться с сервером, но сервер, судя по логу, не видит этих попыток. Так продолжается ~15 минут, затем клиент подключается к серверу и работа продолжается.
Можно бы было предположить что в эти 15 минут нет связности между устройствами, но пользователь мониторит соединение между устройствами и уверен, что никаких проблем в сети в эти 15 минут не наблюдается(потерь нет, задержка 600-700ms.), пакеты передаются между устройствами. Более того пользователь говорит о том, что не видит даже причин для разрыва соединения.
Такое поведение повторилось уже несколько раз(много) и каждый раз с момента разрыва до момента соединения проходит 15 минут.
Логи:
Клиент(время в логе UTC+7)

root@comcerto:~# logread -f
Apr  8 08:45:38 comcerto daemon.err sip_ua[437]: r232.cpp:217: module 1: read() error: Connection reset by peer
Apr  8 08:45:38 comcerto daemon.info sip_ua[437]: r232.cpp:381: module 1: looking up 192.168.5.16...
Apr  8 08:45:38 comcerto daemon.info sip_ua[437]: r232.cpp:437: module 1: connecting to 192.168.5.16 port 12912...
Apr  8 08:48:47 comcerto daemon.err sip_ua[437]: r232.cpp:250: module 1: cannot connect: Connection timed out
Apr  8 08:48:47 comcerto daemon.info sip_ua[437]: r232.cpp:437: module 1: connecting to 192.168.5.16 port 12912...
Apr  8 08:51:56 comcerto daemon.err sip_ua[437]: r232.cpp:250: module 1: cannot connect: Connection timed out
Apr  8 08:52:30 comcerto daemon.info sip_ua[437]: r232.cpp:381: module 1: looking up 192.168.5.16...
Apr  8 08:52:30 comcerto daemon.info sip_ua[437]: r232.cpp:437: module 1: connecting to 192.168.5.16 port 12912...
Apr  8 08:55:39 comcerto daemon.err sip_ua[437]: r232.cpp:250: module 1: cannot connect: Connection timed out
Apr  8 08:55:39 comcerto daemon.info sip_ua[437]: r232.cpp:437: module 1: connecting to 192.168.5.16 port 12912...
Apr  8 08:58:48 comcerto daemon.err sip_ua[437]: r232.cpp:250: module 1: cannot connect: Connection timed out
Apr  8 08:59:22 comcerto daemon.info sip_ua[437]: r232.cpp:381: module 1: looking up 192.168.5.16...
Apr  8 08:59:22 comcerto daemon.info sip_ua[437]: r232.cpp:437: module 1: connecting to 192.168.5.16 port 12912...
Apr  8 09:00:56 comcerto daemon.err sip_ua[437]: r232.cpp:263: module 1: connected to server

Сервер(время в логе UTC)

root@comcerto:~# logread -f
Apr  8 01:45:38 comcerto daemon.err sip_ua[448]: r232.cpp:218: module 1: read() error: Connection timed out
Apr  8 01:45:38 comcerto daemon.info sip_ua[448]: r232.cpp:604: module 1: waiting for incoming connection...
Apr  8 02:00:56 comcerto daemon.info sip_ua[448]: r232.cpp:98: module 1: connect from ::ffff:198.18.1.34:48291

Настройки устройств


з.ы. В нашей сети есть VIP(192.168.0.1) и 3U с платой VE-02(192.168.1.52) доступные для экспериментов.

[alx]

"cannot connect: Connection timed out" в логе клиента говорит о том, что он ничего не получил в ответ на свои отправленные серверу пакеты.

Replying to san:

Можно бы было предположить что в эти 15 минут нет связности между устройствами, но пользователь мониторит соединение между устройствами и уверен, что никаких проблем в сети в эти 15 минут не наблюдается(потерь нет, задержка 600-700ms.), пакеты передаются между устройствами.

Чтобы в этом были уверены и мы, необходимо посмотреть tcpdump'ом на стороне сервера (3U), действительно ли в плату приходят пакеты от клиента. Например так:

tcpdump -i eth0 -pn tcp port 12912

Вывод tcpdump'а приложить к этому тикету.

[san]

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

Поэтому пользователю сложно поймать дамп, по крайней мере не удалось пока записать дамп происшествия со стороны сервера. Однако пользователя есть возможность постоянно записывать обмен данными на промежуточном оборудовании со стороны клиента, наверняка это и малополезно, но приложу дамп с одним из происшествий ниже.
Время разрыва UTC Apr 14 12:25 ... 12:41

[alx]

Приложенный дамп со стороны клиента подтверждает вывод, сделанный ранее на основании лога клиента: клиент не получает от сервера ответов на свои попытки установить соединение:

17:32:37.408124 IP 198.18.1.34.38265 > 192.168.5.16.12912: Flags [S], seq 4084316913, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 2], length 0
17:32:40.403123 IP 198.18.1.34.38265 > 192.168.5.16.12912: Flags [S], seq 4084316913, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 2], length 0
17:32:46.403173 IP 198.18.1.34.38265 > 192.168.5.16.12912: Flags [S], seq 4084316913, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 2], length 0
17:32:58.403395 IP 198.18.1.34.38265 > 192.168.5.16.12912: Flags [S], seq 4084316913, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 2], length 0
17:33:22.403459 IP 198.18.1.34.38265 > 192.168.5.16.12912: Flags [S], seq 4084316913, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 2], length 0

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

[san]

Выше прикрепил ещё один дамп происшествия comment:2
Пользовател обнаружил, что точек сьёма дампа две и выслал дамп где есть обе точки:

Vlan 42 - точка сбора трафика "за спутником" (перед клиентом, dsl-vip).
Vlan 299 - точка сбора трафика "перед спутником" (перед сервером, dsl-3u).

До точки съёма дампа перед сервером пакеты от клиента доходят.
Однако мы всё-ещё не можем быть уверены, что они дошли до сервера...

[san]

Т.к. пользователь "пропал", будем считать что проблема была на его стороне.