По какой то причине после 0.00 CLAN корректно завершает tcp

Роман Лебедев

Привет Всем!
Есть проблема с которой не могу справится.
Три станции скидывают статистику о звонках в Барсум.
Без какой либо закономерности затыкается сбор статистики с одной и той же станции. По мониторингу делаем вывод что tcp-сессия закрывается корректно со стороны платы CLAN.

Вот она:

На хосте, собирающем статистику, осуществлялся полный дамп трафика и контроль
доступности атс посредством ping-a.
11 фев. 2008 в 00:59 наблюдается следующая картина:

00:59:09.006738 IP 172.16.0.6.11009 > 172.16.0.100.5714: . ack 1 win
8192
00:59:09.006811 IP 172.16.0.100.5714 > 172.16.0.6.11009: . ack 106 win
64259 <nop,nop,timestamp 4796115 4208679>
..... icmp запросы-ответы
.....
00:59:53.564864 IP 172.16.0.6 > 172.16.0.100: ICMP echo reply, id 512,
seq 53235, length 40
00:59:54.562342 IP 172.16.0.100 > 172.16.0.6: ICMP echo request, id
512, seq 54003, length 40
00:59:54.564865 IP 172.16.0.6 > 172.16.0.100: ICMP echo reply, id 512,
seq 54003, length 40
00:59:55.562511 IP 172.16.0.100 > 172.16.0.6: ICMP echo request, id
512, seq 55027, length 40
00:59:55.565027 IP 172.16.0.6 > 172.16.0.100: ICMP echo reply, id 512,
seq 55027, length 40
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
00:59:56.311630 IP 172.16.0.6.11009 > 172.16.0.100.5714: F 106:106(0)
ack 1 win 8192 <nop,nop,timestamp 4215613 4796115>
00:59:56.311716 IP 172.16.0.100.5714 > 172.16.0.6.11009: . ack 107
win 64259 <nop,nop,timestamp 4796588 4215613>
00:59:56.393376 IP 172.16.0.100.5714 > 172.16.0.6.11009: F 1:1(0) ack
107 win 64259 <nop,nop,timestamp 4796589 4215613>
00:59:56.396042 IP 172.16.0.6.11009 > 172.16.0.100.5714: . ack 2 win
8192 <nop,nop,timestamp 4215613 4796589>
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
00:59:56.562404 IP 172.16.0.100 > 172.16.0.6: ICMP echo request, id
512, seq 55539, length 40
01:00:01.953101 IP 172.16.0.100 > 172.16.0.6: ICMP echo request, id
512, seq 58867, length 40
01:00:07.453311 IP 172.16.0.100 > 172.16.0.6: ICMP echo request, id
512, seq 61683, length 40
01:00:12.953317 IP 172.16.0.100 > 172.16.0.6: ICMP echo request, id
512, seq 65011, length 40
01:00:18.453418 IP 172.16.0.100 > 172.16.0.6: ICMP echo request, id
512, seq 2292, length 40
01:00:23.953556 IP 172.16.0.100 > 172.16.0.6: ICMP echo request, id
512, seq 5620, length 40
01:00:29.453631 IP 172.16.0.100 > 172.16.0.6: ICMP echo request, id
512, seq 8436, length 40
01:00:31.881272 arp who-has 172.16.0.6 tell 172.16.0.6
01:00:34.953768 IP 172.16.0.100 > 172.16.0.6: ICMP echo request, id
512, seq 11764, length 40
01:00:34.956449 arp who-has 172.16.0.100 tell 172.16.0.6
01:00:34.958716 IP 172.16.0.6 > 172.16.0.100: ICMP echo reply, id 512,
seq 11764, length 40
01:00:35.953776 IP 172.16.0.100 > 172.16.0.6: ICMP echo request, id
512, seq 12532, length 40
01:00:35.956266 IP 172.16.0.6 > 172.16.0.100: ICMP echo reply, id 512,
seq 12532, length 40
01:00:36.953785 IP 172.16.0.100 > 172.16.0.6: ICMP echo request, id
512, seq 13300, length 40
01:00:36.956327 IP 172.16.0.6 > 172.16.0.100: ICMP echo reply, id 512,
seq 13300, length 40
01:00:37.953812 IP 172.16.0.100 > 172.16.0.6: ICMP echo request, id
512, seq 14068, length 40
01:00:37.956472 IP 172.16.0.6 > 172.16.0.100: ICMP echo reply, id 512,
seq 14068, length 40
01:00:38.953835 IP 172.16.0.100 > 172.16.0.6: ICMP echo request, id
512, seq 14836, length 40
01:00:38.956482 IP 172.16.0.6 > 172.16.0.100: ICMP echo reply, id 512,
seq 14836, length 40

172.16.0.6 - ip атс, с которой наблюдается проблема.
172.16.0.100 - ip хоста, на котором работает сбор статистики и
мониторинг.
Как видно из приведенного фрагмента, 172.16.0.6 инициирует закрытие
tcp-сессии, сессия корректно закрывается, далее атс перестает пинговаться
на 30 сек,
после чего ping возобновляется и больше не пропадает, но tcp сессий больше
нет никаких.
Около 8 утра атс удаленно перезагружают и она устанавливает
tcp-коннект, начинает передавать статистику:

07:55:41.803291 IP 172.16.0.100 > 172.16.0.6: ICMP echo request, id
512, seq 2072, length 40
07:55:41.805813 IP 172.16.0.6 > 172.16.0.100: ICMP echo reply, id 512,
seq 2072, length 40
07:55:42.803498 IP 172.16.0.100 > 172.16.0.6: ICMP echo request, id
512, seq 3096, length 40
07:55:42.806033 IP 172.16.0.6 > 172.16.0.100: ICMP echo reply, id 512,
seq 3096, length 40
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
07:55:43.684340 IP 172.16.0.6.11371 > 172.16.0.100.5714: S
680990814:680990814(0) win 8192 <mss 1460,nop,wscale 0,nop,nop,timestamp
49806 0>
07:55:43.684618 IP 172.16.0.100.5714 > 172.16.0.6.11371: S
3290684810:3290684810(0) ack 680990815 win 65535 <mss 1460,nop,wscale
0,nop,nop,timestamp 0 0>
07:55:43.687471 IP 172.16.0.6.11371 > 172.16.0.100.5714: . ack 1 win
8192 <nop,nop,timestamp 49807 0>
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
07:55:43.803470 IP 172.16.0.100 > 172.16.0.6: ICMP echo request, id
512, seq 3864, length 40
07:55:43.805929 IP 172.16.0.6 > 172.16.0.100: ICMP echo reply, id 512,
seq 3864, length 40
07:55:44.803334 IP 172.16.0.100 > 172.16.0.6: ICMP echo request, id
512, seq 4376, length 40
07:55:44.805815 IP 172.16.0.6 > 172.16.0.100: ICMP echo reply, id 512,
seq 4376, length 40
07:55:45.359774 IP 172.16.0.6.11371 > 172.16.0.100.5714: P 1:106(105)
ack 1 win 8192 <nop,nop,timestamp 49810 0>
07:55:45.362047 IP 172.16.0.6.11371 > 172.16.0.100.5714: P 106:211(105)
ack 1 win 8192 <nop,nop,timestamp 49810 0>
07:55:45.362282 IP 172.16.0.100.5714 > 172.16.0.6.11371: . ack 211 win
65325 <nop,nop,timestamp 5046073 49810>

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

Помогите а!!!

orbit_ · Сообщение **orbit_** » Ср 13 фев 2008, 10:36

Приветствую.

Была похожая проблема. С тем, кто рвет сесию не разбирались, но выяснили, что в 00:00 станция "радостно" шлет сообшение о начале нового дня ... от чего Барсум впадал в прострацию ... и начинал писать звонки в непредсказуемый момент ... то в 4 утра, то в 8 ...
Обновления СМ до последного - не помогло. Решилось саппортом Барсума ... дали файлы BarsumCollector.exe и definity.dll версии 5.02.005 ... теперь в ошибках барсума ежедневно появляется ошибка о "направильном формате" ... но звонки вроде пишет.

Роман Лебедев

дело в том что у меня три станции. Барсум многостанционный. Так вот картина затык наблюдается только с одной.

orbit_ · Сообщение **orbit_** » Ср 13 фев 2008, 12:28

Других идей нет

Если накопаете глубже ... поделитесь.
От себя еще могу сказать, что попытки вырубить все задачи по шедуллеру ... тоже не увенчались успехом ...
У нас: одна станция - один барсум ... сравнивать нечего ...

Роман Лебедев

Может быть у кого нибудь есть еще какие нить мысли по проблеме, а?

orbit_ · Сообщение **orbit_** » Пн 18 фев 2008, 14:24

Роман, может добавить ясность в конфигурацию? Сказано - "3 станции" - какие? как пишут звонки? Все по tcp? и т.п. Просто если все одинаково ... а одна глючит - это одна история (копать на предмет различий), а если они в Барсум подключены по другому (COM или еще чего), то можно пойти по нашему пути.

Leva · Сообщение **Leva** » Ср 20 фев 2008, 13:01

Роман Лебедев писал(а):Может быть у кого нибудь есть еще какие нить мысли по проблеме, а?

Роман проверьте версию фирмваре на C-lan. Может в этом проблема.

Роман Лебедев

А какая должна быть? У меня 26

Leva · Сообщение **Leva** » Ср 20 фев 2008, 17:03

26 это последняя. Значит проблема не в этом... А увас все последние патчина СМ стоят. У вас вообще что за система?
И еще есть одня идейка. А у вас есть возможность поменять местами платы? Тогда будет точно понятно что проблема с платой

....