Как узнать, какой MTU используется в Windows XP

21

Я страдаю от действительно странной проблемы, когда я получаю случайные ошибки «Соединение с сервером было сброшено» при попытке доступа к веб-страницам (ошибка HTTP 12031 в соответствии с инструментом диагностики сети Windows) - это происходит независимо от того, есть ли веб-страница Я пытаюсь получить доступ через внешний интернет или даже если это локальный экземпляр Apache, работающий на localhost. Это влияет на все компьютеры в нашей локальной сети (Ethernet, а не беспроводной), все из которых работают под управлением Windows XP.

Мне было предложено, что это может быть связано с MTU, используемым для сетевого трафика. Если я выполню тест Ping, чтобы найти самый большой пакет, который может пройти через нефрагментированный файл, я могу пропинговать локальный хост с пакетом из 1492 байтов (+28 байтов за заголовок?), И я могу пропинговать наш маршрутизатор с пакетом из 1462 байтов (что составляет 1490 байт при включении 28-байтового заголовка). Если я попытаюсь что-то пропинговать снаружи, например, Google, я не смогу получить что-то большее, чем 1430 (то есть 1458 с заголовком).

Я пытался следовать различным наборам инструкций, чтобы обновить реестр Windows XP с помощью этого параметра MTU, обновление HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{AdapterID}\MTU. Я не пробовал конца альтернативных значений: наиболее очевидное правильное значение - 1490, но я также пробовал 1462, 1458, 1430 и т. Д. И т. Д. Когда я перезагружаю компьютер, чтобы изменения вступили в силу, оно кажется, работает в течение нескольких минут (трудно сказать наверняка, потому что это всегда случайный, а не последовательный), но это никогда не длится долго.

Первоначально, когда я пытался использовать значение 1430, после нескольких минут работы в порядке результаты теста Ping снизились бы на 28 байт - внезапно я обнаружил, что могу передать в Google только пакет из 1402 байт. Если я обновил параметр реестра MTU до 1402, когда я перезагрузился и подождал несколько минут, это было бы 1374, затем 1346 и т. Д. И т. Д. Другие компьютеры в сети оставались неизменными (все еще на 1430) и удаляли настройку MTU из реестра вернул бы все в нормальное состояние (и все еще сломанное).

Самое сложное в диагностике всего этого - то, что очень трудно определить, правильно ли я играю с правильными настройками реестра. Итак, в самом простом случае мой вопрос будет таким: Как я могу сказать, какие настройки MTU пытается использовать Windows?

Кроме того, если у кого-то есть идеи, как определить, почему MTU продолжает падать на 28, это тоже было бы полезно (например, есть ли файл журнала Windows где-нибудь, где он будет что-то регистрировать в точке, где значение изменяется?)

Наконец, если кто-нибудь может сказать мне окончательно, как определить настройку MTU, которую я должен пытаться использовать, это было бы здорово!

andygeers
источник
FWIW, в конце концов это была хитрая телефонная линия, которая была проблемой. Когда я подключил телефон, не было звонка.
andygeers

Ответы:

58

Для Windows 7, Windows Vista и Windows XP MTU для различных интерфейсов доступен из самой Windows, используя netsh.

Windows 7, Windows Vista

Чтобы отобразить текущий MTU в Windows 7 или Windows Vista, из командной строки:

C:\Users\Ian>netsh interface ipv6 show subinterfaces

       MTU  MediaSenseState   Bytes In  Bytes Out  Interface
----------  ---------------  ---------  ---------  -------------
      1280                1   24321220    6455865  Local Area Connection
4294967295                1          0    1060111  Loopback Pseudo-Interface 1
      1280                5          0          0  isatap.newland.com
      1280                5          0          0  6TO4 Adapter

И для интерфейсов IPv4:

C:\Users\Ian>netsh interface ipv4 show subinterfaces

       MTU  MediaSenseState   Bytes In  Bytes Out  Interface
----------  ---------------  ---------  ---------  -------------
      1500                1  146289608   29200474  Local Area Connection
4294967295                1          0      54933  Loopback Pseudo-Interface 1

Примечание. В этом примере мой интерфейс IPv6 для локального подключения имеет такой низкий MTU (1280), потому что я использую сервис туннеля для получения подключения IPv6 .

Вы также можете изменить свой MTU (Windows 7, Windows Vista). Из командной строки с повышенными правами:

>netsh interface ipv4 set subinterface "Local Area Connection" mtu=1492 store=persistent
Ok.

Протестировано с Windows 7 с пакетом обновления 1

Windows XP

netshСинтаксис для Windows XP немного отличается:

C:\Users\Ian>netsh interface ip show interface

Index:                                  1
User-friendly Name:                     Loopback
Type:                                   Loopback
MTU:                                    32767
Physical Address:                       

Index:                                  2
User-friendly Name:                     Local Area Connection
Type:                                   Etherenet
MTU:                                    1500
Physical Address:                       00-03-FF-D9-28-B7

Примечание: Windows XP требует, чтобы служба маршрутизации и удаленного доступа была запущена, прежде чем вы сможете увидеть подробности об интерфейсе (включая MTU):

C:\Users\Ian>net start remoteaccesss

Windows XP не позволяет изменить настройки MTU изнутри netsh. Для этого вы можете:

Протестировано с Windows XP с пакетом обновления 3

Смотрите также


Краткое обсуждение того, что такое MTU, откуда берутся 28 байтов.

Ваша сетевая карта (Ethernet) имеет максимальный размер пакета 1,500 bytes:

+---------+
| 1500    |
| byte    |
| payload |
|         |
|         |
|         |
+---------+

IP-часть TCP / IP требует 20-байтового заголовка (12 байт флагов, 4 байта для исходного IP-адреса, 4 байта для конечного IP-адреса). Это оставляет меньше места в пакете:

+------------------------+
| 12 bytes control flags | \
| 4 byte from address    | |- IP header: 20 bytes
| 4 byte to address      | /
|------------------------|
| 1480 byte payload      |
|                        |
|                        |
|                        |
+------------------------+

Теперь пакет ICMP (ping) имеет 8-байтовый заголовок (1 байт type, 1 байт code, 2 байта checksum, 4 байта дополнительных данных):

+------------------------+
| 12 bytes control flags | \
| 4 byte from address    | |
| 4 byte to address      | |- IP and ICMP header: 28 bytes
|------------------------| |
| 8 byte ICMP header     | /
|------------------------|
| 1472 byte payload      |
|                        |
|                        |
|                        |
+------------------------+

Вот где «пропущенные» 28 байтов - это размер заголовков, необходимых для отправки пакета проверки связи.

Когда вы отправляете пакет ping, вы можете указать, сколько дополнительных данных полезной нагрузки вы хотите включить. В этом случае, если вы включите все 1472 байта:

>ping -l 1472 obsidian

Тогда полученный пакет Ethernet будет полон жабрам. Каждый последний байт 1500-байтового пакета будет заполнен:

+------------------------+
| 12 bytes control flags | \
| 4 byte from address    | |
| 4 byte to address      | |- IP and ICMP header: 28 bytes
|------------------------| |
| 8 byte ICMP header     | /
|------------------------|
|........................|
|........................|
|. 1472 bytes of junk....|
|........................|
|........................|
|........................|
|........................|
+------------------------+

Если вы попытаетесь отправить еще один байт

>ping -l 1473 obsidian

сеть должна будет фрагментировать этот 1501-байтовый пакет на несколько пакетов:

Packet 1 of 2
+------------------------+
| 20 bytes control flags | \
| 4 byte from address    | |
| 4 byte to address      | |- IP and ICMP header: 28 bytes
|------------------------| |
| 8 byte ICMP header     | /
|------------------------|
|........................|
|........................|
|..1472 bytes of payload.|
|........................|
|........................|
|........................|
|........................|
+------------------------+

Packet 2 of 2
+------------------------+
| 20 bytes control flags | \
| 4 byte from address    | |
| 4 byte to address      | |- IP and ICMP header: 28 bytes
|------------------------| |
| 8 byte ICMP header     | /
|------------------------|
|.                       |
| 1 byte of payload      |
|                        |
|                        |
|                        |
|                        |
|                        |
+------------------------+

Эта фрагментация произойдет за кулисами, в идеале, без вашего ведома.

Но вы можете иметь в виду и сказать сети, что пакет не может быть фрагментирован:

>ping -l 1473 -f obsidian

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

>ping -l 1473 -f obsidian  

Packet needs to be fragmented but DF set.

Пакет должен быть фрагментирован, но флаг « Не фрагментировать» был установлен.

Если где-нибудь вдоль линии пакет должен быть фрагментирован, сеть фактически отправляет ICMP-пакет, сообщающий вам, что фрагментация произошла. Ваша машина получает этот ICMP-пакет, получает информацию о его наибольшем размере и должна прекратить посылать слишком большие пакеты. К сожалению, большинство брандмауэров блокируют эти ICMP-пакеты «Path MTU discovery», поэтому ваша машина никогда не осознает, что пакеты фрагментированы (или, что еще хуже, отброшены, поскольку их невозможно фрагментировать).

Вот почему веб-сервер не работает. Вы можете получить начальные небольшие (<1280 байт) ответы, но большие пакеты не могут пройти. А межсетевые экраны веб-сервера неправильно настроены, блокируя ICMP-пакеты. Таким образом, веб-сервер не понимает, что вы никогда не получили пакет.

Фрагментация пакетов не разрешена в IPv6, каждый должен (правильно) разрешать пакеты обнаружения ICMP mtu.

Ян Бойд
источник
8

@ian Я не уверен, что на netshсамом деле показывает текущий MTU. На моем компьютере с Windows XP Pro SP3 я выполнил netsh interface ip show interfaceи сообщил значение MTU для соответствующего интерфейса как 1500. Затем я добавил следующие ключи реестра:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\EnablePMTUDiscovery
    value: 0

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{ID}\MTU 
    value: various (e.g. 1200)

Microsoft говорит, что установка EnablePMTUDiscoveryв 0 установит MTU в 576.

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

В обоих случаях - при добавлении первой записи, затем второй записи - netshвсе еще сообщалось, что MTU равен 1500. Тестирование с помощью ping подтвердило (или, по крайней мере, предположило), что значение MTU, настроенное в реестре, действительно используется.

Кроме того, когда я впервые попробовал сделать это на своем компьютере, служба маршрутизации и удаленного доступа была отключена, поэтому я не смог запустить ее, следуя вашим инструкциям. Я включил его, перейдя в Панель управления> Администрирование> Управление компьютером> Службы и приложения> Службы. Я изменил «Тип запуска» с Отключено на Ручной. Затем я запустил сервис из этого диалога.

Я также не уверен, что KB283165 - обязательно правильные инструкции для изменения MTU. Разве эти инструкции актуальны только при запуске клиента Windows PPPoE? Если при подключении к Интернету через маршрутизатор, где маршрутизатор является клиентом PPPoE (как в моем случае), эти инструкции не будут актуальны, не так ли?

Следующие инструкции, которые привели меня к внесению вышеуказанных изменений в реестр, были в KB900926: Рекомендуемые настройки TCP / IP для каналов WAN с размером MTU менее 576 (методы 2 и 3).


Редактировать @ian

Похоже, ты прав. Настроить на 1200, но netshотчеты 1500.

введите описание изображения здесь

>ping -l 1173 -f obsidian

Packet needs to be fragmented but DF set.

Поэтому я думаю, что ответ на первоначальный вопрос заключается в том, что в Windows XP вы должны использовать метод проб и ошибок с флагом Не фрагментировать, чтобы найти самый большой пакет, который вы можете отправить. Тогда у вас есть MTU.

JMM
источник
2

Вы можете найти MTU, используя ping с методом проб и ошибок:

ping <address> -f -l nnnn

Пинг :

-f: указывает, что сообщения эхо-запроса отправляются с флагом «Не фрагментировать» в заголовке IP, равным 1. Сообщение эхо-запроса не может быть фрагментировано маршрутизаторами на пути к месту назначения. Этот параметр полезен для устранения неполадок в пути максимального блока передачи (PMTU).

-l Размер: указывает длину в байтах поля данных в отправляемых сообщениях эхо-запроса. Значение по умолчанию - 32. Максимальный размер - 65 527.

Вы получите сообщения «Пакет должен быть фрагментирован, но установлен DF», если длина слишком велика.

Т. Калтнекар
источник
Это то, что я делал выше, когда говорил о «Тесте
пинга
1

Смотрите AdapterWatch :

AdapterWatch отображает полезную информацию о ваших сетевых адаптерах: IP-адреса, аппаратный адрес, WINS-серверы, DNS-серверы, значение MTU, количество полученных или отправленных байтов, текущую скорость передачи и многое другое. Кроме того, он отображает общую статистику TCP / IP / UDP / ICMP для вашего локального компьютера.

harrymc
источник
1

Microsoft KB314496: размеры MTU по умолчанию для различных сетевых топологий .
Вы не должны пытаться играть с конфигурацией MTU в обычных сетевых настройках.

Здесь есть ссылка на код VB .
Существует также инструмент под названием DrTCP :

альтернативный текст


В реестре

  • Перейти к HKLM\Software\Microsoft\Windows NT\CurrentVersion\NetworkCards
  • Откройте интересующий вас адаптер
  • Скопируйте ServiceNameстроку
  • Поиск этой строки в HKLM\System; вам подойдет NetCfgInstanceIdключ
  • Чуть выше это будет MaxFrameSizeключ (мой показывает 1514)

Есть также способ изменить это с помощью netshкоманды.

Также проверьте настройку Path MTU Discovery .

Nik
источник
Спасибо за это, но в идеале я бы больше успокоился, если бы мог заставить Windows фактически сказать мне, какой MTU он на самом деле использует, а не то, что вы ожидаете по умолчанию. Может быть, это невозможно, хотя :-(
andygeers