Застревает исходящий трафик

[rudwut]

Ubuntu 10.04 x86-64

При работе через браузеры upload выполняется либо с задержкой где-то в полминуты, либо вообще застревает.
Например, на speedtest.net удается выполнить только тест download, а тест upload застревает намертво на стадии Preparing for upload test.
Аналогично на других сайтах, например на youtube невозможно залить видео.

Работаю в сети через роутер D-Link DI-524, но при работе с этого же компа под Windows такой проблемы нет. (Отсылаю это сообщение тоже и Windows, из Ubuntu не получается)

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

Заранее спасибо!
Пользователь решил продолжить мысль 20 Сентября 2010, 12:13:11:Пардон, забыл

ifconfig

(Нажмите, чтобы показать/скрыть)

eth0      Link encap:Ethernet  HWaddr 00:19:5b:c0:91:61 
          inet addr:192.168.1.10  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::219:5bff:fec0:9161/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:165442 errors:0 dropped:0 overruns:0 frame:0
          TX packets:93629 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:235546734 (235.5 MB)  TX bytes:8405319 (8.4 MB)
          Interrupt:16

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:8 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:480 (480.0 B)  TX bytes:480 (480.0 B)

route

(Нажмите, чтобы показать/скрыть)

Таблица маршутизации ядра протокола IP
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0     *               255.255.255.0   U     1      0        0 eth0
link-local      *               255.255.0.0     U     1000   0        0 eth0
default         192.168.1.1     0.0.0.0         UG    0      0        0 eth0

cat /etc/resolv.conf

(Нажмите, чтобы показать/скрыть)

# Generated by NetworkManager
nameserver 192.168.1.1

[fisher74]

окошки на этой же машине?

[rudwut]

Да, речь об одной и той же машине. На ней и Ubuntu и Windows

[Mam(O)n]

Вообще похоже на проблему с MTU (Maximum Transmit Unit). По идее, когда какой-либо пакет не пролазит где-то на промежуточном роутере, то от него должен прийти icmp пакет, извещающий об этом и содержащий максимальный размер кадра. На основе этой информации система должна сгенерировать новый пакет, меньшего размера. Так вот, если где-то режется icmp то естественно будут траблы. На убунте файрволы никакие не поднимал? Что говорит sudo iptables-save ?

[rudwut]

На убунте файерволов не поднимал, команда

sudo iptables-save

никакого вывода не дала (я что-то не так сделал? может какие ключи нужны?)

[Mam(O)n]

никакого вывода не дала

Значит всё чисто.

Тогда пробуй крутить MTU на интерфейсе в сторону уменьшения, методом научного тыка...... Или основываясь на максимальном размере проходящего пинга до узла назначения...

[AnrDaemon]

tracepath вам в помощь.

[rudwut]

Тогда пробуй крутить MTU на интерфейсе в сторону уменьшения, методом научного тыка...... Или основываясь на максимальном размере проходящего пинга до узла назначения...

Зашел в роутер посмотреть значение MTU, там (почему-то) стояло 1500. Изменил на дефолтное 1492 - проблема решилась. Спасибо!

Но пара ламерских вопросов осталась:

1. Почему Windows mtu=1500 хавает, а Ubuntu нет? Где в убунте это можно настроить?
2. Как правильно подобрать оптимальное значение mtu?

Спасибо
Пользователь решил продолжить мысль 20 Сентября 2010, 16:57:27:Вот вывод команды tracepath yandex.ru

(Нажмите, чтобы показать/скрыть)

tracepath yandex.ru
 1:  mypc-desktop.local (192.168.1.10)                    0.129ms pmtu 1500
 1:  192.168.1.1 (192.168.1.1)                              1.302ms
 1:  192.168.1.1 (192.168.1.1)                              0.909ms
 2:  192.168.1.1 (192.168.1.1)                              0.917ms pmtu 1492
 2:  192.168.2.1 (192.168.2.1)                              2.370ms
 3:  a197-crs-1-be1-53.msk.stream-internet.net (212.188.1.113)  23.014ms asymm  5
 4:  a197-crs-1-be1-53.msk.stream-internet.net (212.188.1.113)  22.382ms asymm  5
 5:  m9-crs-1-be4.msk.stream-internet.net (195.34.59.49)   23.083ms asymm  9
 6:  m9-cr02-po6.msk.stream-internet.net (195.34.59.242)   23.763ms asymm  7
 7:  Yandex-m9.msk.stream-internet.net (195.34.36.30)      22.294ms asymm  8
 8:  gallium-vlan901.yandex.net (77.88.56.126)             23.986ms asymm 11
 9:  l3-s1100-s900-2.yandex.net (213.180.213.55)           23.718ms asymm 10
10:  yandex.ru (93.158.134.11)                             24.477ms reached
     Resume: pmtu 1492 hops 10 back 54

Где-то 1500, где-то 1492 - что к чему относится?
И что означает Resume: pmtu 1492 hops 10 back 54 ?
Чисто для самообразования!  

[AnrDaemon]

http://translate.google.ru/?client=opera&oe=utf-8&ie=UTF-8&sa=N&hl=en#auto|ru|Resume:%20pmtu%201492%20hops %2010%20back%2054

Это и есть ответ.

[Mam(O)n]

стояло 1500. Изменил на дефолтное 1492 - проблема решилась.

VPN? Тады твой роутер скорее всего и являлся чёрной дырой (black hole router)

1. Почему Windows mtu=1500 хавает, а Ubuntu нет? Где в убунте это можно настроить?

Хз, первым делом копать надо снятием дампов трафика. Возможно, что mtu в венде подкручен или пакеты формируются с другими параметрами mss. Потом нужно ковырнуть механизм "black hole router detection". И в Ubuntu и на венде этот механизм есть, только надо удостоверится, что он работает. В Linuxе за это отвечает параметр sysctl net.ipv4.tcp_mtu_probing, но возможно в Ubuntu оно отключено. Возможные значения данного параметра: 0: disabled, 1: enabled when black hole detected, 2: always enabled.

2. Как правильно подобрать оптимальное значение mtu?

Подбирается пингом ping -s размер_пинга -M do ya.ru, где размер пинга это MTU минус 28 байт ip и icmp echo заголовков.

Где-то 1500, где-то 1492 - что к чему относится?

Начали пакетом 1500, это на твоём интерфейсе. Потом дошли до твоего роутера, который нам сказал, что 1500 это дофига и надо бы снизить до 1492...

И что означает Resume: pmtu 1492 hops 10 back 54 ?

1492 это path mtu, т.е. полученный от роутеров максимальный размер пакета по этому пути. hops 10 означает, что прошли 10 роутеров, которые изменили значение ttl -1. back 54 это вероятное количество роутеров по пути назад. Вычисляется по томуже ttl... Более подробно, см. man tracepath

[AnrDaemon]

2. Как правильно подобрать оптимальное значение mtu?

Подбирается пингом ping -s размер_пинга -M do ya.ru, где размер пинга это MTU минус 28 байт ip и icmp echo заголовков.

Вообще-то для этого есть tracepath... И пингами яндекса мало что можно сделать, до него обычно самый большой pmtu, так как он часто оказывается прямо налево от раздающей точки.

[Mam(O)n]

Вообще-то для этого есть tracepath...

Утилита tracepath роутеры-"чёрные дыры" не пробивает. Она pmtu определяет на основе ответов от роутеров типа icmp destination-unreachable и если он зарезан где-то  на одном из роутеров по пути, то tracepath тут не помощник:

(Нажмите, чтобы показать/скрыть)

Код: ("На ноуте") [Выделить]

mamon@mamon-laptop:~$ tracepath ya.ru
 1:  mamon-laptop (172.22.22.45)                            0.272ms pmtu 1500
 1:  router (172.22.22.2)                                   1.595ms
 1:  router (172.22.22.2)                                   1.415ms
 2:  router (172.22.22.2)                                   1.583ms pmtu 1460
 2:  star124.medvedkovo.control.starnet.ru (10.0.14.124)    5.412ms
 3:  no reply
 4:  no reply
 5:  v11-jun.msk.mmts-9.starnet.ru (217.172.16.249)        97.115ms asymm  6
 6:  msk-ix-m9.yandex.net (193.232.244.93)                  4.076ms asymm  7
 7:  www.yandex.ru (93.158.134.3)                           6.921ms reached
     Resume: pmtu 1460 hops 7 back 58


Код: ("На роутере 172.22.22.2") [Выделить]

root@router:~# iptables -A OUTPUT -p icmp --icmp-type destination-unreachable  -j DROP


Код: ("Снова на ноуте") [Выделить]

mamon@mamon-laptop:~$ tracepath ya.ru
 1:  mamon-laptop (172.22.22.45)                            0.238ms pmtu 1500
 1:  router (172.22.22.2)                                   1.170ms
 1:  router (172.22.22.2)                                   1.052ms
 1:  no reply
 2:  no reply
 3:  no reply
...
31:  no reply
     Too many hops: pmtu 1500
     Resume: pmtu 1500


И пингами яндекса мало что можно сделать, до него обычно самый большой pmtu, так как он часто оказывается прямо налево от раздающей точки.

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

ЗЫ. У меня появилось небольшое ощущение дежавю

[AnrDaemon]

Не так часто попадаются именно чёрные дыры, на моей практике, по крайней мере.
www.sony.net пока единственный.

[Mam(O)n]

А если нет дыр, то и нет проблем с mtu, хинты отправляемые через icmp помогут сформировать пакет правильного размера, если только не режутся локальным файрволом... В дебрях инета такое действительно редкость, но на моей практике очень часто попадаются горе-админы в местных сетях, которые рубят весь им непонятный icmp трафик на шлюзе... Или возмем, например, случай, описаный в данном топике. Из за неверно выставленного mtu на ppp интерфейсе роутера, пакеты роутер принимал, а вот дальше они не уходили и данный хоп становился "черной дырой". А такие случаи не редки, и у нас на форуме не раз проскакивали. Самое простое было бы настроить роутер правильно, но не всегда есть возможность им управлять и вычислить максимальный реальный размер mtu тут можно только пингом или подстваив наиболее популярные значения и tracepath в общем то в этих делах бесполезная утилита.

[AnrDaemon]

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

Пример из жизни - у меня ноуты к серверу коннектятся через изолированную сеть и получают сервер и инет по PPP.
Многие жаловались на тормоза. После пары экспериментов, нашел решение - в виндовом VPN подключении в реестре создать
MTU=dword32:(MTU интерфейса на сервере - 40).
После этого всё забегало быстро и красиво.