Como saber qual MTU está sendo usado no Windows XP

Question

Estou sofrendo de um problema muito estranho em que aleatoriamente recebo erros "A conexão com o servidor foi redefinida" ao tentar acessar páginas da Web (erro HTTP 12031 de acordo com a ferramenta de diagnóstico de rede do Windows) - isso acontece independentemente de a página da web que estou tentando acessar está na Internet externa ou mesmo em uma instância local do Apache em execução no host local. Afeta todos os computadores em nossa rede local (Ethernet, não sem fio), todos executando o Windows XP.

Foi sugerido para mim que isso poderia estar relacionado ao MTU usado no tráfego de rede. Se eu fizer o teste de ping para descobrir o maior pacote que pode passar por desfragmentado, eu posso pingar o localhost com um pacote de 1492 bytes (+28 bytes para um cabeçalho?) e eu posso pingar nosso roteador com um pacote de 1462 bytes (que é 1490 bytes quando você inclui o cabeçalho de 28 bytes). Se eu tentar pingar algo do lado de fora como o Google, não consigo fazer nada maior do que 1430 (que é 1458 com o cabeçalho).

Eu tentei seguir vários conjuntos de instruções para atualizar o Registro do Windows XP com essa configuração de MTU, atualizando HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{AdapterID}\MTU . Eu tentei sem fim de valores alternativos: o valor correto mais óbvio parece ser 1490, mas eu também tentei 1462, 1458, 1430, etc., etc. Quando eu reiniciar o computador para fazer a alteração ter efeito, parece que funcione por alguns minutos (difícil dizer com certeza, pois é sempre aleatório e não consistente), mas nunca dura muito tempo.

Inicialmente, quando eu estava tentando 1430 como um valor, depois de alguns minutos trabalhando bem, os resultados do Teste de Ping diminuíam em 28 bytes - de repente eu achava que só conseguiria um pacote de 1402 bytes para o Google. Se eu atualizasse a configuração do registro MTU para 1402, quando reinicializei e esperei alguns minutos, então seria 1374, depois 1346, etc. etc. Outros computadores na rede permaneciam inalterados (ainda em 1430) e removendo a configuração MTU do registro iria restaurar as coisas para normal (e ainda quebrado).

A coisa que eu acho mais difícil diagnosticar tudo isso é que é muito difícil dizer se estou jogando com a configuração correta do registro. Então, é mais simples, minha pergunta seria: Como posso saber qual configuração de MTU o Windows está tentando usar?

Além disso, se alguém tiver alguma idéia de como saber por que o MTU continua caindo por 28, isso também seria útil (por exemplo, existe um arquivo de log do Windows em algum lugar onde ele registrará algo no ponto em que o valor muda?)

Finalmente, se alguém puder me dizer definitivamente como saber qual configuração de MTU eu deveria estar tentando usar, isso seria ótimo!

    

Answer 1

Para o Windows 7, Windows Vista e Windows XP, a MTU para várias interfaces está disponível no próprio Windows usando netsh .

Windows 7, Windows Vista

Para exibir a MTU atual no Windows 7 ou no Windows Vista, em um prompt de comando:

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

E para interfaces 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

Observação: Neste exemplo, minha interface IPv6 de conexão de área local tem uma MTU tão baixa (1280) porque estou usando um tunnel service para obter conectividade IPv6 .

Você também pode alterar seu MTU (Windows 7, Windows Vista). De um prompt de comando elevado :

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

Testado com o Windows 7 Service Pack 1

Windows XP

A sintaxe netsh do Windows XP é um pouco diferente:

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

Observação: o Windows XP exige que o serviço Roteamento e acesso remoto seja iniciado antes que você possa ver detalhes sobre uma interface (incluindo MTU):

C:\Users\Ian>net start remoteaccesss

O Windows XP não fornece uma maneira de alterar a configuração de MTU de netsh . Para isso você pode:

• siga as instruções em KB283165 - Como alterar o tamanho da MTU PPPoE no Windows XP
• use o Dr. TCP ( Nota: apenas Windows 2000 / XP)

Testado com o Windows XP Service Pack 3

Veja também

• Configurar o tamanho da unidade de transferência máxima (MTU) TCPIP no Vista
• Definindo o MTU no Windows Vista
• Alterar configurações de MTU Ajuda!
• KB283165 - Como alterar o tamanho da MTU PPPoE no Windows XP
• DSLReports - DrTCP

Breve discussão sobre o que é MTU, de onde os 28 bytes estão vindo.

Sua placa de rede (Ethernet) tem um tamanho máximo de pacote de 1,500 bytes :

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

A parte IP do TCP / IP requer um cabeçalho de 20 bytes (12 bytes de sinalizadores, 4 bytes para o endereço IP de origem, 4 bytes para o endereço IP de destino). Isso deixa menos espaço disponível no pacote:

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

Agora, um pacote ICMP (ping) tem um cabeçalho de 8 bytes (1 byte type , 1 byte code , 2 bytes checksum , dados adicionais de 4 bytes):

+------------------------+
| 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      |
|                        |
|                        |
|                        |
+------------------------+

É aí que estão os 28 bytes "faltantes" - é o tamanho dos cabeçalhos necessários para enviar um pacote de ping.

Quando você envia um pacote de ping, é possível especificar quantos dados de carga útil extras você deseja incluir. Nesse caso, se você incluir todos os 1472 bytes:

>ping -l 1472 obsidian

Em seguida, o pacote ethernet resultante ficará cheio para as guelras. Cada último byte do pacote de 1500 bytes será preenchido:

+------------------------+
| 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....|
|........................|
|........................|
|........................|
|........................|
+------------------------+

Se você tentar enviar mais um byte

>ping -l 1473 obsidian

a rede terá que fragmentar o pacote de 1501 bytes em vários pacotes:

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      |
|                        |
|                        |
|                        |
|                        |
|                        |
+------------------------+

Esta fragmentação acontecerá nos bastidores, idealmente sem você saber.

Mas você pode ser malvado e dizer à rede que o pacote não pode ser fragmentado:

>ping -l 1473 -f obsidian

A sinalização -f significa não fragmentar . Agora, quando você tenta enviar um pacote que não cabe na rede, você recebe o erro:

>ping -l 1473 -f obsidian  

Packet needs to be fragmented but DF set.

O pacote precisa ser fragmentado, mas o sinalizador Não fragmentar foi definido.

Se em algum lugar ao longo da linha um pacote precisou ser fragmentado, a rede realmente envia um pacote ICMP informando que ocorreu uma fragmentação. Sua máquina recebe este pacote ICMP, é informado de qual foi o maior tamanho e deve parar de enviar pacotes muito grandes. Infelizmente, a maioria dos firewalls bloqueia esses pacotes ICMP "Path MTU discovery", portanto, sua máquina nunca percebe que os pacotes estão sendo fragmentados (ou pior: foram descartados porque não puderam ser fragmentados).

Isso é o que faz com que o servidor da Web não funcione. Você pode obter as respostas iniciais pequenas (< 1280 bytes), mas os pacotes maiores não podem passar. E os firewalls do servidor web estão mal configurados, bloqueando os pacotes ICMP. Então o servidor web não percebe que você nunca recebeu o pacote.

A fragmentação de pacotes não é permitida no IPv6, todos são necessários para (corretamente) permitir pacotes de descoberta de mtu ICMP.

    

Answer 2

@ian Não tenho tanta certeza de que netsh realmente mostre o MTU usado no momento. Na minha máquina com Windows XP Pro SP3, executei netsh interface ip show interface e ele reportou o valor da MTU para a interface relevante como 1500 . Em seguida, adicionei as seguintes chaves do Registro:

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)

A Microsoft diz que a configuração EnablePMTUDiscovery para 0 definirá a MTU como 576.

Definir a entrada de registro MTU define a MTU manualmente. Eu tentei vários valores para a entrada MTU (reinicializando a cada vez).

Em ambos os casos - adicionando a primeira entrada, a segunda entrada - netsh ainda relatou a MTU como 1500. O teste com ping confirmou (ou pelo menos sugeriu) que o valor da MTU configurado no registro estava realmente sendo usado embora.

Além disso, quando tentei isso pela primeira vez em minha máquina, o serviço de roteamento e acesso remoto estava desativado, por isso não consegui iniciá-lo usando suas instruções. Eu habilitei indo ao Painel de Controle > Ferramentas Administrativas > Gerenciamento de computadores > Serviços e Aplicativos > Serviços. Eu mudei "Startup type" de Disabled para Manual. Eu então iniciei o serviço a partir desse diálogo também.

Eu também não tenho certeza se o KB283165 é necessariamente as instruções corretas para alterar o MTU. Essas instruções não são relevantes somente ao executar o cliente Windows PPPoE? Se conectando à internet através de um roteador onde o roteador é o cliente PPPoE (como no meu caso), essas instruções não seriam relevantes, certo?

As instruções que eu segui, que me levaram a fazer as alterações acima no registro, estavam em KB900926: configurações de TCP / IP recomendadas para Links de WAN com um tamanho de MTU inferior a 576 (métodos 2 e 3).

Editar por @ian

Parece que você está certo. Configure para 1.200, mas netsh reports 1500 .

>ping -l 1173 -f obsidian

Packet needs to be fragmented but DF set.

Então eu acho que a resposta para a pergunta original é que no Windows XP você tem que usar tentativa e erro com o sinalizador Não fragmentar para encontrar o maior pacote que você pode enviar. Então você tem o seu MTU.

    

Answer 3

Veja AdapterWatch :

AdapterWatch displays useful information about your network adapters: IP addresses, Hardware address, WINS servers, DNS servers, MTU value, Number of bytes received or sent, The current transfer speed, and more. In addition, it displays general TCP/IP/UDP/ICMP statistics for your local computer.

    

Answer 4

Microsoft KB314496: Os tamanhos de MTU padrão para diferentes topologias de rede .
Você não deve tentar jogar com a configuração MTU em configurações normais de rede.

Existe uma referência do código VB aqui .
Existe também uma ferramenta chamada DrTCP :

Noregistro,

• IrparaHKLM\Software\Microsoft\WindowsNT\CurrentVersion\NetworkCards
• Abraoadaptadoremquevocêestáinteressado
• CopieastringServiceName
• PesquiseessasequênciaemHKLM\System;vocêcorresponderáàNetCfgInstanceIdkey
• Umpoucoacima,seráateclaMaxFrameSize(aminhamostra1514)

Hátambémumamaneiradealterarissocomocomandonetsh.

Alémdisso,verifiqueasuaconfiguração Path MTU Discovery .

    

Answer 5

Você pode encontrar o MTU usando ping com abordagem de tentativa e erro:

ping <address> -f -l nnnn

Ping :

-f : Specifies that Echo Request messages are sent with the Don't Fragment flag in the IP header set to 1. The Echo Request message cannot be fragmented by routers in the path to the destination. This parameter is useful for troubleshooting path Maximum Transmission Unit (PMTU) problems.

-l Size : Specifies the length, in bytes, of the Data field in the Echo Request messages sent. The default is 32. The maximum size is 65,527.

Você receberá mensagens "O pacote precisa ser fragmentado, mas o conjunto DF" quando o tamanho for muito grande.