"connection timed out" при каждой второй попытке соединения

[Данuл]

Ubuntu Server 10.04 LTS.

Конечно, не при каждой второй попытке, а в случайном порядке, но "connection timed out" выскакивает очень часто. При чём всё настроено вроде бы нормально: /etc/network/interfaces настроен правильно, днс-ки в /etc/resolv.conf прописаны верно. И что самое странное, пинг идёт просто превосходно, без единой потери. А вот wget если не срабатывает сразу, то срабатывает только с 3-8 попытки подключения.

Что важно: подключал ноут с виндой к интернет-кабелю - всё идёт превосходно, без потерь и обрывов, соединение происходит моментально. На Ubuntu Server же проблемы.

Помогите пожалуйста советом. Любые варианты проверю, т.к. сам уже проверил всё, что только мог проверить.

P.S. Кстати, забыл упомянуть, что если соединение установлено - оно не обрывается. Т.е. если wget подключился, то тащит файлик полностью, каким бы объёмным он ни был и сколько бы времени это не заняло.

[fisher74]

/etc/network/interfaces настроен правильно

Это как? Про mtu там есть?

[Данuл]

/etc/network/interfaces настроен правильно

Это как? Про mtu там есть?

Это значит, что ещё месяц назад всё работало корректно с этими же настройками.
За месяц только успел установить pptpd и снести его через apt-get purge со всеми подгруженными с ним пакетами.

[fisher74]

Будем дальше словоблудством заниматься или всё-таки начнём показывать инфу?

Код: [Выделить]

cat /etc/network/interfaces
ifconfig -a
nslookup ya.ru
tracepath ya.ru
wget ya.ru -O /dev/null

[Данuл]

Простите, хотел вечером кинуть конфиги, но плюнул (т.к. решение требовалось найти менее чем за сутки), сделал бэкап и за ночь поднял всё с нуля (благо сервер выполняет только функции хостинг-сервера).

Спасибо огромное за попытку помочь.

[Данuл]

Видимо это судьба: столкнуться с этой проблемой и решить её, а не бегать от неё каждый раз за диском с дистрибутивом убунты...

Проблема вновь себя показала. Проработало всё около 2 месяцев, а потом таймауты вернулись... Хотя поставил всё начисто, никаких сторонних приложений (кроме red5, lamp, proftpd и ispconfig3 для управления всем вышеперечисленным) не ставил. Всё работало корректно до наступления дня "Ч". Напомню, что в прошлый раз проблема начала себя сильно проявлять также на выходных, но через некоторое время (через пару недель) проблема перешла в полной мере и на будни.

Напомню, проблема в том, что 90% попыток соединения (например, через wget) с любым внешним сервером заканчивается таймаутом, хотя любые пинги идут прямо, без задержек. Замечу, что при подключении к другим серверам одной локальной сети проблем с таймаутом не бывает. В моей юрисдикции только данный сервер (Ubuntu Server 10.04 LTS), но обратиться с претензией к вышестоящему управлению, которое занимается it-поддержкой других серверов и связующего оборудования, не могу, потому что при подключении на данный интернет-канал системного блока под win таймаутов нет, всё коннектится с первого раза (в данный момент (до понедельника) проверить возможности нет, т.к. работаю удалённо, но такие симптомы (с подключением компа под win) были в прошлый раз (2 месяца назад), когда возникла данная проблема).

Сервер не загружен почти ничем (пара сотен одиночных посещений через apache в сутки). Рестарт никак не исправляет ситуацию (таймауты начинаются сразу после загрузки системы). И, ориентируясь по прошлому разу, симптомы будут проявляться всё чаще и чаще, системе будет становится всё хуже и хуже...

Привожу всё, что просили. Как видно, traceroute просто безупречный, днс-ки настроены верно. Memory загружен на 50%, swap на данный момент пуст. Загрузка системы по данным landscape: 0.07.

Код: [Выделить]

$ cat /etc/network/interfaces
# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
        address ███.██.67.126
        netmask 255.255.255.252
        network ███.██.67.0
        broadcast ███.██.67.255
        gateway ███.██.67.125

Код: [Выделить]

$ ifconfig -a
eth0      Link encap:Ethernet  HWaddr 00:1a:92:60:3c:1f
          inet addr:███.██.67.126  Bcast:███.██.67.255  Mask:255.255.255.252
          inet6 addr: fe80::21a:92ff:fe60:3c1f/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:73307 errors:0 dropped:0 overruns:0 frame:0
          TX packets:95541 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:7713063 (7.7 MB)  TX bytes:95520547 (95.5 MB)
          Interrupt:22

lo        Link encap:Локальная петля (Loopback)
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:4034 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4034 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:589028 (589.0 KB)  TX bytes:589028 (589.0 KB)

Код: [Выделить]

$ nslookup ya.ru
Server:         ███.██.67.129
Address:        ███.██.67.129#53

Non-authoritative answer:
Name:   ya.ru
Address: 213.180.193.3
Name:   ya.ru
Address: 213.180.204.3
Name:   ya.ru
Address: 77.88.21.3
Name:   ya.ru
Address: 87.250.250.3
Name:   ya.ru
Address: 87.250.250.203
Name:   ya.ru
Address: 87.250.251.3
Name:   ya.ru
Address: 93.158.134.3
Name:   ya.ru
Address: 93.158.134.203

Код: [Выделить]

$ tracepath ya.ru
 1:  vhost.lan23.com (███.██.67.126)                        0.143ms pmtu 1500
 1:  host125.net███-██-67.omkc.ru (███.██.67.125)           0.407ms
 1:  host125.net███-██-67.omkc.ru (███.██.67.125)           0.476ms
 2:  host253.net137-50.omkc.ru (94.137.50.253)              1.358ms
 3:  rt1.omkc.ru (217.25.208.161)                           1.148ms
 4:  212.188.22.141 (212.188.22.141)                        2.362ms asymm  5
 5:  212.188.42.145 (212.188.42.145)                       20.663ms asymm  7
 6:  212.188.42.1 (212.188.42.1)                           26.619ms asymm  8
 7:  stan-cr01-xe1-1-0.uln.stream-internet.net (212.188.28.221)  29.857ms asymm  9
 8:  212.188.29.217 (212.188.29.217)                       43.983ms
 9:  212.188.42.37 (212.188.42.37)                         37.086ms asymm 10
10:  212.188.42.37 (212.188.42.37)                         37.131ms
11:  212.188.29.193 (212.188.29.193)                       45.848ms asymm  7
12:  212.188.42.57 (212.188.42.57)                         46.211ms asymm 10
13:  m9-cr02-po6.msk.stream-internet.net (195.34.59.242)   45.704ms
14:  Yandex-m9.msk.stream-internet.net (195.34.36.30)      45.466ms
15:  carmine-red-vlan602.yandex.net (87.250.242.206)       58.316ms asymm  8
16:  l3-s600-s2190.yandex.net (213.180.213.37)             71.569ms asymm  9
17:  no reply
18:  www.yandex.ru (77.88.21.3)                            60.692ms reached
     Resume: pmtu 1500 hops 18 back 54

Код: [Выделить]

$ wget ya.ru -O /dev/null
--2012-04-08 01:53:26--  http://ya.ru/
Преобразование адреса ya.ru... 93.158.134.3, 93.158.134.203, 213.180.193.3, ...
Устанавливается соединение с ya.ru|93.158.134.3|:80... ошибка: Время ожидания соединения истекло.
Устанавливается соединение с ya.ru|93.158.134.203|:80... ошибка: Время ожидания соединения истекло.
Устанавливается соединение с ya.ru|213.180.193.3|:80... соединились.
Запрос HTTP послан, ожидание ответа... 200 Ok
Длина: 8082 (7,9K) [text/html]
Saving to: «/dev/null»

100%[======================================>] 8 082       --.-K/s   в 0,06s

2012-04-08 01:54:17 (133 KB/s) - «/dev/null» saved [8082/8082]

[koshev]

Шпиономания, итить. Первые два замазанных октета 178.74

Код: [Выделить]

Тхис сите ис нот фоунд! Сорри!Но это лирика
Что за чип сетвушки?
lspci -knn |grep "\Eth" -A2

[fisher74]

Можеь попробовать снизить mtu?
Хотя 2-х месячная бесперебойная работа, конечно, несколько настораживает...

[ArcFi]

Шпиономания, итить.

Теперь ТС прочитает man tracepath и узнает о ключе -n. %)

[Данuл]

Шпиономания, итить. Первые два замазанных октета 178.74

Код: [Выделить]

Тхис сите ис нот фоунд! Сорри!Но это лирика
Что за чип сетвушки?
lspci -knn |grep "\Eth" -A2

Замазано было не из-за паранойи. С работы попереть могут, если узнают, что во внешний мир обратился с внутренним вопросом, либо сервер отберут, что тоже не есть good... Так что спасибо, что ставите мою работу под угрозу.

А теперь ближе к вопросу:

Код: [Выделить]

$ lspci -knn |grep "\Eth" -A2
02:04.0 Ethernet controller [0200]: Marvell Technology Group Ltd. 88E8001 Gigabit Ethernet Controller [11ab:4320] (rev 14)
        Kernel driver in use: skge
        Kernel modules: skge

Может попробовать снизить mtu?
Хотя 2-х месячная бесперебойная работа, конечно, несколько настораживает...

Возможно я ошибаюсь, но вроде же тот факт, что маршрутизатор успешно передаёт данные между этим сервером и остальными серверами в пределах сети, говорит о том, что изменением mtu проблему не решить?.. Хотя, конечно, если рассинхронизация происходит как раз во время передачи данных сервера между маршрутизатором локальной сети и верхним оборудованием, то есть возможность снизить процент таймаутов, но это не решает проблему целиком... Хотелось бы избавиться от неё раз и навсегда...

[fisher74]

но вроде же тот факт, что маршрутизатор успешно передаёт данные между этим сервером и остальными серверами в пределах сети, говорит о том, что изменением mtu проблему не решить?..

Ой ли маршрутизатор? Может всё-таки комммутатор? Встроенность его в корпус маршрутизатора и дополнение его функций не меняет его назначения.

Хотя, конечно, если рассинхронизация происходит как раз во время передачи данных сервера между маршрутизатором локальной сети и верхним оборудованием

Именно на разделах сетей происходит "рассинхронизация" (иногда/очень часто/от случая к случаю)

, то есть возможность снизить процент таймаутов, но это не решает проблему целиком... Хотелось бы избавиться от неё раз и навсегда...

Вы уверены, что Вы правильно понимаете физический смысл MTU и зачем его приходится выравнивать?

[Данuл]

Вы уверены, что Вы правильно понимаете физический смысл MTU и зачем его приходится выравнивать?

Я про него узнал только вчера, заглянув в wiki после вашего сообщения, поэтому скорее всего я не до конца понимаю его смысл. Но я предполагал, что если проблемы не постоянные (например, в данный момент сервер работает как часы: wget уже более 1000 раз прошёл без заминки, хотя вчера вечером проходило на complete только каждое 3-е (4-е, 5-е, когда как) соединение). Плюс ко всему, пинг всегда проходит с первого раза. Проблема возникает только при подключении к внешним серверам по определённому порту (wget, telnet). Если подключаться к внутренним серверам, связанным с моим, то всё проходит нормально. И мне из описания mtu показалось, что mtu с этим вряд ли связан. Но чтобы уже наверняка отмести этот вариант скажите значение mtu, которое необходимо проставить, чтобы я попробовал его поменять в момент, когда начинаются проблемы с сетью.

Если это не поможет - попробую поменять сетевую карту на другую, не от Marvell.

P.S. Я всё таки оставляю надежду, что проблемы не в настройке данного сервера, а в сетевом оборудовании, которое стоит над ним. Но для того, чтобы передать решение данной проблемы высшему управлению, занимающемуся сетями в нашей организации, мне требуются неопровержимые доказательства того, что проблема у них, а не на сервере.

[fisher74]

Конкретные значения относятся к конкретным случаям. Обычно проверяется плавным снижением значения. Вот пара стандартных значений 1492 и 1400. Но повторюсь - возможны вариации.
То что "вчера по капле, сегодня водопад" это, конечно, на mtu не похоже, но проверить всё же стоит.
Кстати, проверить ведь можно тем же пингом изменяя размер пакета
Вот смотрите. В моём случае роутер выравнивает размер пакета до 1400 (провайдер).
А я намеренно пакет icmp увеличиваю вровень и на байт больше. Заметьте, что сам пакет icmp заворачивается в контейнер (+8 байт)

~$ ping ya.ru -c2 -s 1372
PING ya.ru (77.88.21.3) 1372(1400) bytes of data.
1380 bytes from www.yandex.ru (77.88.21.3): icmp_seq=1 ttl=54 time=42.3 ms
1380 bytes from www.yandex.ru (77.88.21.3): icmp_seq=2 ttl=54 time=43.2 ms

~$ ping ya.ru -c2 -s 1373
PING ya.ru (87.250.250.3) 1373(1401) bytes of data.
From dir-320 (192.168.4.2) icmp_seq=1 Frag needed and DF set (mtu = 1400)
1381 bytes from www.yandex.ru (87.250.250.3): icmp_seq=2 ttl=55 time=37.0 ms

Если у Вашего или вышестоящего роутера нет выравнивания,то он тупо перестанет пропускать пакеты толщиной больше определённого значения.

[Данuл]

Конкретные значения относятся к конкретным случаям. Обычно проверяется плавным снижением значения. Вот пара стандартных значений 1492 и 1400. Но повторюсь - возможны вариации.
То что "вчера по капле, сегодня водопад" это, конечно, на mtu не похоже, но проверить всё же стоит.
Кстати, проверить ведь можно тем же пингом изменяя размер пакета
Вот смотрите. В моём случае роутер выравнивает размер пакета до 1400 (провайдер).
А я намеренно пакет icmp увеличиваю вровень и на байт больше. Заметьте, что сам пакет icmp заворачивается в контейнер (+8 байт)

~$ ping ya.ru -c2 -s 1372
PING ya.ru (77.88.21.3) 1372(1400) bytes of data.
1380 bytes from www.yandex.ru (77.88.21.3): icmp_seq=1 ttl=54 time=42.3 ms
1380 bytes from www.yandex.ru (77.88.21.3): icmp_seq=2 ttl=54 time=43.2 ms

~$ ping ya.ru -c2 -s 1373
PING ya.ru (87.250.250.3) 1373(1401) bytes of data.
From dir-320 (192.168.4.2) icmp_seq=1 Frag needed and DF set (mtu = 1400)
1381 bytes from www.yandex.ru (87.250.250.3): icmp_seq=2 ttl=55 time=37.0 ms

Если у Вашего или вышестоящего роутера нет выравнивания,то он тупо перестанет пропускать пакеты толщиной больше определённого значения.

Ок. Спасибо. Как только симптомы вернуться - сразу же проверю и отпишусь. Написал маленький скриптик, который каждые 10 минут пытается скачать страницу google.com и при ошибке уведомит меня о ней на мобильный. Так что жду смс-ок от сервера...

[Дмитрий Бо]

А не два одинаковых IP в сети?