Шукати в цьому блозі

четвер, 4 червня 2009 р.

Рекомендации по диагностике. Определение значения MTU.

Кнопка Пуск->пункт Выполнить->набрать cmd->нажать Enter

В открывшемся окне пишем:
Код:
C:\>ipconfig

Windows IP Configuration


Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix  . :
IP Address. . . . . . . . . . . . : 10.100.1.150
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 10.100.1.254
Определяем "Default Gateway" (в русскоязычной версии Windows - "Шлюз по-умолчанию").
Дальше посылаем на шлюз - эхореквест:
Код:
ping 10.100.1.254 -n 100
Данный вариант ping'а пошлет 100 пакетов и выведет статистику по своей работе. Тут есть одна рекомендация:
  • Если первые несколько ping'ов не прошли и выдали "Request timed out." (в русскоязычной версии Windows - "Превышен интервал ожидания для запроса."), останавливаем выполнение (Ctrl+C) и запускаем заново. Потеря первой пары-тройки ping'ов может отзначать задержку по резолву в обратной зоне службы DNS, так что не есть факт, что это потери именно по layer 3. Конечно-же если потеряно больше чем пара-тройка первых пакетов, то тут уже проблемы другого рода.
После того как вышеприведенная команда закончит свою работу, не надо отсылать всь "простыню", достаточно выделить несколько первых ping'ов, а потом последний и суммарную статистику:
Код:
C:\>ping 10.100.1.254 -l 1500 -n 100

Pinging 10.100.1.254 with 32 bytes of data:

Reply from 10.100.1.254: bytes=32 time=1ms TTL=255
Reply from 10.100.1.254: bytes=32 time=1ms TTL=255
...
Reply from 10.100.1.254: bytes=32 time=1ms TTL=255

Ping statistics for 10.100.1.254:
Packets: Sent = 100, Received = 100, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 1ms, Average = 0ms
Поверьте, что для диагностики эта информация будет иметь большую ценность, нежели киллометровые расппечатки пингов.
Собственно это была проверка Вашего шлюза в сеть, но при этом она проводилась маленьгими пакетами - всего 32 байта.
Дальше было бы неплохо выяснить размер MTU который пропускает шлюз по умолчанию. Для этого займёмся несколько нетривиальной, для рядового пользователя, задачей. Доведём размер эхо-реквест пакета до максимального, который может пропустить шлюз.
Код:
C:\> ping 10.100.1.254 -n 100 -l 1500 -f
Опция -f указывает на то, чтобы отослынне пакеты не фрагментировались по MTU. Объяснение физики этого процесса выходит за рамки этого очерка. Опция -l 1500 указывает на то, что мы будем отсылать пакеты размером 1500 байт. Итак Enter. Если пакеты прошли - ура! Значит все хорошо и мы выделяем ту-же статистику, что и в первом варианте (см.выше).
Но так-же вы можете увидеть в ответ "Packet needs to be fragmented but DF set". В этом случае укоротите размер пакета в опции -l. Если опять пакеты не прошли, сделайте это ещё раз. В определённй момент времени покеты начнут идти! У себя я экспериментально установил, что максимальный не фрагментируемый размер пакета - 1472 байт. Запомните это значение (не 1472, а то которое Вы найдёте для себя). Это важно! Можете записать его маркером на своём мониторе (шутка;)), но не забудьте его, чтобы не мучатся в следующий раз. Ну теперь опять пускаем ping:
Код:
C:\>ping 10.100.1.254 -n 100 -l 1472 -f

Pinging 10.100.1.254 with 1472 bytes of data:

Reply from 10.100.1.254: bytes=1472 time=1ms TTL=255
...
Reply from 10.100.1.254: bytes=1472 time=1ms TTL=255

Ping statistics for 10.100.1.254:
Packets: Sent = 100, Received = 100, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 1ms, Average = 0ms
Теперь пустите ping на хост 10.100.100.1, сначала стандартные для Windows 32 байта, а затем найденным размером с опцией -f, и отошлите собранную статистику.

Потом можете попробовать пропинговать таким-же образом сайты в Интернете (например google.com, ya.ru).

В случае проблем с доступом на сайты желательно проверить его доступность с помощью программы WinMTR. В строке Host пишем адрес сайта и жмем Start.

"Момент истины". Зачастую для ethernet карточек размер MTU устанавливается в 1500 байт. Но, как видим выше, в моём случае маршрутизатор не пропустил не фрагментируемые пакеты размером больше чем 1472 байта. Т.е. имеет смысл снизить для сетевой карты размер MTU для 1472 байт, так как маршрутизатор все равно не пропускает целиком пакеты больше этого значения, и фрагментирует их на несколько частей, после чего отсылает. Естественно, что это создает лишнюю нагрузку на маршрутизатор, и плюс к этому, в случае реальных потерь, никому ненужную нагрузку на сеть.

Для установки MTU можно либо вручную подправить реестр (страшно, да? ;)) либо воспользоваться утилитами сторонних разработчиков, например DrTCP. Кстати, определить размер MTU можно и не вручную, как описано выше, а опять таки с помощью специализированых утилит, например mturoute.

И ещё. Чуть было не забыл. Если удалённый хоть не отвечает на ping'и (не шлет Ech-Reply), то это не всегда означает, что этот ресурс недоступен. Иногда, для снижения нагрузки на сервер, или ещё по каким либо религиозным причинам, ответы на Echo-Requiest'ы просто отклучаются администраторами, либо просто заблокированы запросы из нашей/вашей сети. Так что критически анализируйте так называемую "недоступность хоста" :)
__________________

Немає коментарів: