Como saber qual MTU está sendo usado no Windows XP

Estou com um problema muito estranho no qual recebo aleatoriamente erros "A conexão ao 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 da página da Web Estou tentando acessar está na internet externa ou mesmo se for de uma instância local do Apache em execução no localhost. Afeta todos os computadores em nossa rede local (Ethernet, não sem fio), todos executando o Windows XP.

Foi-me sugerido que isso pode 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 sem fragmentar, posso executar ping no host local com um pacote de 1492 bytes (+28 bytes para um cabeçalho?) E posso executar ping no roteador com um pacote de 1462 bytes (que é 1490 bytes quando você inclui o cabeçalho de 28 bytes). Se eu tentar fazer ping em algo externo, como o Google, não consigo obter nada maior que 1430 (1458 com o cabeçalho).

Tentei seguir vários conjuntos de instruções para atualizar o registro do Windows XP com esta 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 também tentei 1462, 1458, 1430 etc. etc. Quando eu reinicio o computador para que as alterações tenham efeito, parece funcionar por alguns minutos (difícil dizer com certeza, pois é sempre aleatório e não consistente), mas nunca dura muito.

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ó podia obter um pacote de 1402 bytes no Google. Se eu atualizei a configuração do registro da MTU para 1402, quando reiniciei e esperei alguns minutos, seriam 1374, 1346 etc. etc. Outros computadores na rede permaneceram inalterados (ainda em 1430) e removendo a configuração da MTU do registro restauraria as coisas ao normal (e ainda está quebrado).

A coisa que eu acho mais difícil em diagnosticar tudo isso é que é muito difícil dizer se estou brincando com a configuração correta do registro. Portanto, no 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 em 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!

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

Windows 7, Windows Vista

Para mostrar o MTU atual no Windows 7 ou 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

Nota: Neste exemplo, minha interface IPv6 de conexão de área local possui uma MTU (1280) tão baixa porque estou usando um serviço de encapsulamento para obter conectividade IPv6 .

Você também pode alterar seu MTU (Windows 7, Windows Vista). Em 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 netshsintaxe para o 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

Nota: O Windows XP requer 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 da MTU de dentro netsh. Para isso você pode:

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

Testado com o Windows XP Service Pack 3

Veja também

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

Breve discussão sobre o que é MTU, de onde vêm os 28 bytes.

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) possui um cabeçalho de 8 bytes ( dados adicionais de 1 byte type, 1 byte code, 2 byte checksum, 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 "ausentes" - é o tamanho dos cabeçalhos necessários para enviar um pacote de ping.

Ao enviar um pacote de ping, você pode especificar a quantidade de dados de carga útil extra que deseja incluir. Nesse caso, se você incluir todos os 1472 bytes:

>ping -l 1472 obsidian

Em seguida, o pacote Ethernet resultante estará cheio até as brânquias. 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 esse 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      |
|                        |
|                        |
|                        |
|                        |
|                        |
+------------------------+

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

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

>ping -l 1473 -f obsidian

O sinalizador -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 precisar ser fragmentado, a rede realmente enviará um pacote ICMP informando que ocorreu uma fragmentação. Sua máquina obtém esse pacote ICMP, é informado qual era o maior tamanho e deve parar de enviar pacotes muito grandes. Infelizmente, a maioria dos firewalls bloqueia esses pacotes ICMP "Path MTU discovery", para que sua máquina nunca perceba que os pacotes estão sendo fragmentados (ou pior: descartados porque não podiam ser fragmentados).

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

A fragmentação de pacotes não é permitida no IPv6, todos são obrigados a (corretamente) permitir pacotes de descoberta ICMP mtu.

@ian Não tenho tanta certeza de que netshrealmente mostre o MTU usado atualmente. Na minha máquina com Windows XP Pro SP3, executei netsh interface ip show interfacee relatou o valor da MTU para a interface relevante como 1500. 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)

Microsoft diz que configuraçãoEnablePMTUDiscovery para 0 definirá o MTU para 576.

Definir a MTUentrada do registro define o MTU manualmente. Eu tentei vários valores para oMTU entrada (reiniciando cada vez).

Nos dois casos - adicionando a primeira entrada e a segunda entrada - netsh ainda havia o MTU como 1500. Os testes com ping confirmaram (ou pelo menos sugeriram) que o valor do MTU configurado no registro estava realmente sendo usado.

Além disso, quando tentei pela primeira vez na minha máquina, o serviço Roteamento e Acesso Remoto foi desativado; portanto, não foi possível iniciá-lo usando suas instruções. Eu o habilitei no Painel de Controle> Ferramentas Administrativas> Gerenciamento do Computador> Serviços e Aplicativos> Serviços. Alterei "Tipo de inicialização" de Desativado para Manual. Também iniciei o serviço a partir dessa caixa de diálogo.

Também não tenho certeza de que o KB283165 seja necessariamente as instruções corretas para alterar o MTU. Essas instruções não são relevantes apenas ao executar o cliente Windows PPPoE? Se você se conectar à Internet através de um roteador em que o roteador é o cliente PPPoE (como no meu caso), essas instruções não seriam relevantes, certo?

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

Editar por @ian

Parece que você está certo. Configure para 1.200, mas netshrelatórios 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ê deve usar tentativa e erro com o sinalizador Não fragmentar para encontrar o maior pacote que você pode enviar. Então você tem seu MTU.

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

ping <address> -f -l nnnn

Ping :

-f: especifica que as mensagens de solicitação de eco são enviadas com o sinalizador Não fragmentar no cabeçalho IP definido como 1. A mensagem de solicitação de eco não pode ser fragmentada por roteadores no caminho para o destino. Este parâmetro é útil para solucionar problemas do caminho da unidade máxima de transmissão (PMTU).

-l Tamanho: especifica o comprimento, em bytes, do campo Dados nas mensagens de solicitação de eco enviadas. O padrão é 32. O tamanho máximo é 65.527.

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

Consulte AdapterWatch :

O AdapterWatch exibe informações úteis sobre seus adaptadores de rede: endereços IP, endereço de hardware, servidores WINS, servidores DNS, valor MTU, número de bytes recebidos ou enviados, velocidade de transferência atual e muito mais. Além disso, ele exibe estatísticas gerais de TCP / IP / UDP / ICMP para o seu computador local.

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

Há uma referência de código VB aqui .
Há também uma ferramenta chamada DrTCP :

No registro,

• Vamos para HKLM\Software\Microsoft\Windows NT\CurrentVersion\NetworkCards
• Abra o adaptador no qual você está interessado
• Copie o ServiceName string
• Pesquise essa string HKLM\System; você vai combinar com umNetCfgInstanceId chave
• Um pouco acima disso será a MaxFrameSizechave (a minha mostra 1514)

Há também uma maneira de mudar isso com o netsh comando

Além disso, verifique sua configuração do Path MTU Discovery .