2009-09-08 11:24:00 +0000 2009-09-08 11:24:00 +0000
21
21

Como dizer o que MTU está a ser usado no Windows XP

Estou a sofrer de um problema realmente estranho em que recebo aleatoriamente erros de “A ligação ao servidor foi reiniciada” ao tentar aceder a páginas web (erro HTTP 12031 de acordo com a ferramenta de diagnóstico de rede do Windows) - isto acontece independentemente de a página web que estou a tentar aceder estar na Internet externa ou mesmo se for de uma instância Apache local a correr no localhost. Afecta todos os computadores da nossa rede local (Ethernet, não wireless), todos os quais estão a executar o Windows XP.

Foi-me sugerido que poderia ter a ver com a MTU utilizada no tráfego da rede. Se eu fizer o Teste de Ping para descobrir o maior pacote que pode passar sem fragmentação, posso pingar o localhost com um pacote de 1492 bytes (+28 bytes para um cabeçalho?) e posso pingar o nosso router com um pacote de 1462 bytes (que é 1490 bytes quando se inclui o cabeçalho de 28 bytes). Se eu tentar pingar algo no exterior como o Google, não consigo passar nada com mais de 1430 (que é 1458 com o cabeçalho).

Tentei seguir vários conjuntos de instruções para actualizar o Registo do Windows XP com esta configuração MTU, actualizando HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{AdapterID}\MTU. Não tentei nenhum fim de valores alternativos: o valor correcto mais óbvio parece ser 1490, mas também tentei 1462, 1458, 1430, etc., etc. Quando reinicio o computador para fazer com que a alteração tenha efeito, ele saparece a funcionar durante alguns minutos (difícil de dizer com certeza, uma vez que é sempre aleatório em vez de consistente) mas nunca dura muito tempo.

Inicialmente, quando estava a tentar 1430 como valor, após alguns minutos a trabalhar bem, os resultados do Teste Ping diminuiriam em 28 bytes - de repente eu descobriria que só conseguiria obter um pacote de 1402 bytes para o Google. Se eu actualizasse a configuração do registo MTU para 1402, quando reiniciasse e esperasse alguns minutos, seria então 1374, depois 1346, etc., etc. Outros computadores na rede permaneceram inalterados (ainda em 1430) e a remoção da configuração MTU do registo restauraria as coisas ao normal (e ainda quebradas).

O que eu acho mais difícil em diagnosticar tudo isto é que é muito difícil dizer se estou sequer a brincar com a configuração correcta do registo. Por isso, a minha pergunta seria a mais simples: Como posso dizer qual a configuração do MTU que o Windows está a tentar usar?

Além disso, se alguém tiver alguma ideia de como dizer porque é que o MTU continua a cair por 28, isso também seria útil (por exemplo, existe um ficheiro de registo do Windows algures onde vai registar algo no ponto em que o valor muda?)

Finalmente, se alguém me puder dizer definitivamente como dizer qual a configuração MTU que eu deveria estar a tentar utilizar, isso seria óptimo!

Respostas (5)

58
58
58
2011-08-02 02:59:21 +0000

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

Windows 7, Windows Vista

Para mostrar o MTU actual no Windows 7 ou Windows Vista, a partir de 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 a minha interface de Área Local IPv6* tem uma MTU tão baixa (1280) porque estou a usar um serviço túnel para obter conectividade IPv6 .

Também pode alterar a sua MTU (Windows 7, Windows Vista). A partir de um prompt de comando elevado:

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

Testado com Windows 7 Service Pack 1

Windows XP

A sintaxe netsh para Windows XP é ligeiramente 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 **Routing and Remote Access seja iniciado antes de poder ver detalhes sobre uma interface (incluindo MTU):

C:\Users\Ian>net start remoteaccesss

O Windows XP não fornece uma forma de alterar a configuração da MTU a partir de netsh. Para isso, pode:

Testado com o pacote de serviços do Windows XP 3

Ver também

& - Configurar o tamanho da unidade de transferência máxima TCPIP (MTU) no Vista - Configurar a MTU no Windows Vista - Alterar a ajuda das definições da MTU! - KB283165 - Como alterar o tamanho da MTU PPPoE no Windows XP - DSLReports - DrTCP


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

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

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

A parte IP de TCP/IP* requer um cabeçalho de 20 bytes (12 bytes de bandeiras, 4 bytes para o endereço IP de origem, 4 bytes para o endereço IP de destino). Isto 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, 4 bytes de dados adicionais):

+------------------------+
| 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 se encontram os 28 bytes “em falta” - é o tamanho dos cabeçalhos necessários para enviar um pacote ping.

Quando envia um pacote ping, pode especificar quanto extra* dados de carga útil gostaria de incluir. Neste caso, se incluir todos os 1472 bytes:

>ping -l 1472 obsidian

Então o pacote ethernet resultante estará cheio até às 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 tentar enviar um byte a mais

>ping -l 1473 obsidian

a rede terá de fragmentar esse pacote de 1501 bytes em pacotes múltiplos:

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 que você saiba.

Mas pode ser mau, e dizer à rede que o pacote não pode ser fragmentado:

>ping -l 1473 -f obsidian

A bandeira -f significa não fragmentar. Agora, quando se tenta enviar um pacote que não cabe na rede, obtém-se o erro:

>ping -l 1473 -f obsidian  

Packet needs to be fragmented but DF set.

O pacote precisa de ser fragmentado, mas a bandeira não fragmentar foi colocada.

Se em qualquer ponto da linha um pacote precisasse de ser fragmentado, a rede envia na realidade um pacote ICMP dizendo-lhe que ocorreu uma fragmentação. A sua máquina recebe este pacote ICMP, é informada de qual era o maior tamanho, e é suposto deixar de enviar pacotes demasiado grandes. Infelizmente, a maioria das firewalls bloqueiam estes pacotes ICMP “Path MTU discovery”, pelo que a sua máquina nunca se apercebe que os pacotes estão a ser fragmentados (ou pior: largados porque não podiam ser fragmentados).

Isso é o que faz com que o servidor web não funcione. Pode obter as respostas iniciais pequenas (<1280 byte), mas os pacotes maiores não conseguem passar. E as firewalls do servidor web estão mal configuradas, bloqueando os pacotes ICMP. Assim, o servidor web não se apercebe que nunca recebeu o pacote.

A fragmentação de pacotes não é permitida em IPv6, todos são requeridos para (correctamente) permitir pacotes de descoberta de mtu ICMP.

8
8
8
2011-11-07 19:52:04 +0000

@ian Não tenho tanta certeza de que netsh mostre realmente a MTU actualmente utilizada. Na minha máquina Windows XP Pro SP3, eu executei netsh interface ip show interface e ele relatou o valor MTU para a interface relevante como 1500. Acrescentei então as seguintes chaves de registo:

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 a definição de EnablePMTUDiscovery a 0 irá definir o MTU como 576.

a definição de MTU a entrada de registo define o MTU manualmente. Tentei vários valores para a entrada MTU (reiniciar cada vez).

Em ambos os casos – adicionando a primeira entrada, depois a segunda entrada – netsh ainda reportou a MTU como 1500. Testes com ping confirmaram (ou pelo menos sugeriram) que o valor MTU configurado no registo estava de facto a ser utilizado.

Também, quando experimentei isto pela primeira vez na minha máquina, o serviço de Routing e Acesso Remoto foi desactivado, pelo que não consegui iniciá-lo utilizando as vossas instruções. Activei-o indo ao Painel de Controlo \i> Ferramentas Administrativas \i> Gestão Informática \i> Serviços e Aplicações \i> Serviços. Mudei “Tipo de Arranque” de Deficiente para Manual. Comecei então o serviço também a partir desse diálogo.

Também não tenho a certeza de que KB283165 seja necessariamente as instruções correctas para alterar a MTU. Essas instruções não são relevantes apenas quando se executa o cliente PPPoE do Windows? Se a ligação à Internet através de um router onde o router é 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 referidas ao registo, estavam em KB900926: Definições TCP/IP recomendadas para ligações WAN com um tamanho MTU inferior a 576 (métodos 2 & 3).


Editar por @ian

Parece que tem razão. Configurar para 1.200, mas netsh relatórios 1500.

>ping -l 1173 -f obsidian

Packet needs to be fragmented but DF set.

Por isso acho que a resposta à pergunta original é que no Windows XP tem de usar a bandeira Não fragmentar para encontrar o maior pacote que pode enviar. Depois tem o seu MTU.

2
2
2
2009-09-08 11:47:58 +0000

Pode encontrar MTU usando ping com abordagem de tentativa e erro:

ping <address> -f -l nnnn

-f : Especifica que as mensagens de Pedido de Eco são enviadas com a bandeira Don’t Fragment no cabeçalho do IP definido para 1. A mensagem de Pedido de Eco não pode ser fragmentada por routers no caminho para o destino. Este parâmetro é útil para a resolução de problemas do caminho Unidade Máxima de Transmissão (PMTU).

-l Tamanho : Especifica o comprimento, em bytes, do campo de Dados nas mensagens de Pedido de Eco enviadas. O valor por defeito é 32. O tamanho máximo é 65,527.

Receberá mensagens “Pacote precisa de ser fragmentado mas DF definido” quando o comprimento for demasiado grande.

1
1
1
2009-09-08 11:28:05 +0000

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

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


No registo,

  • Ir para HKLM\Software\Microsoft\Windows NT\CurrentVersion\NetworkCards
  • Abrir o adaptador que lhe interessa & - Copiar a ServiceName string
  • Procurar essa string em HKLM\System; irá corresponder a uma NetCfgInstanceId chave
  • Um pouco acima que será a chave MaxFrameSize (a minha mostra 1514)

& Existe também uma forma de alterar isto com o comando netsh.

Também, verifique a sua configuração Path MTU Discovery .

1
1
1
2009-09-08 11:41:12 +0000

Ver AdapterWatch :

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