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

Cómo saber qué MTU se está utilizando en Windows XP

Estoy sufriendo un problema realmente extraño en el que recibo aleatoriamente errores de “La conexión con el servidor se ha restablecido” cuando intento acceder a páginas web (error HTTP 12031 según la herramienta de diagnóstico de red de Windows) - esto ocurre independientemente de si la página web a la que intento acceder está en la Internet externa o incluso si es desde una instancia local de Apache que se ejecuta en localhost. Afecta a todos los ordenadores de nuestra red local (Ethernet, no inalámbrica), todos ellos con Windows XP.

Me han sugerido que podría tener que ver con la MTU utilizada en el tráfico de red. Si hago la prueba de ping para averiguar el paquete más grande que puede pasar sin fragmentar, puedo hacer ping al localhost con un paquete de 1492 bytes (¿28 bytes para una cabecera?) y puedo hacer ping a nuestro router con un paquete de 1462 bytes (que son 1490 bytes si se incluye la cabecera de 28 bytes). Si intento hacer ping a algo de fuera como Google, no puedo conseguir nada más grande que 1430 (que son 1458 con la cabecera).

He intentado seguir varios conjuntos de instrucciones para actualizar el Registro de Windows XP con esta configuración de MTU, actualizando HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{AdapterID}\MTU. He probado un sinfín de valores alternativos: el valor correcto más obvio parece ser 1490, pero también he probado 1462, 1458, 1430, etc., etc. Cuando reinicio el ordenador para que el cambio surta efecto, parece que funciona durante unos minutos (es difícil saberlo con certeza, ya que siempre es aleatorio y no consistente), pero nunca dura mucho.

Inicialmente, cuando probaba 1430 como valor, después de unos minutos de funcionar bien, los resultados de la prueba de ping disminuían en 28 bytes - de repente me encontraba con que sólo podía conseguir un paquete de 1402 bytes a través de Google. Si actualizaba la configuración del registro de MTU a 1402, cuando reiniciaba y esperaba unos minutos, entonces era 1374, luego 1346, etc. etc. Otros ordenadores de la red no se veían afectados (seguían en 1430) y al eliminar la configuración de MTU del registro las cosas volvían a la normalidad (y seguían rotas).

Lo que más me cuesta diagnosticar todo esto es que es muy difícil saber si estoy jugando con la configuración correcta del registro. Así que en su forma más simple, mi pregunta sería: **¿Cómo puedo saber qué configuración de MTU está tratando de usar Windows?

Además, si alguien tiene alguna idea de cómo saber por qué la MTU sigue cayendo en 28, eso también sería útil (por ejemplo, ¿hay algún archivo de registro de Windows en algún lugar donde se registre algo en el punto en que el valor cambia?)

Por último, si alguien puede decirme definitivamente cómo saber qué configuración de MTU debería intentar utilizar, ¡sería genial!

Respuestas (5)

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

Para Windows 7, Windows Vista y Windows XP, la MTU para varias interfaces está disponible desde el propio Windows usando netsh.

Windows 7, Windows Vista

Para mostrar la MTU actual en Windows 7 o Windows Vista, desde una línea de comandos:

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

Y 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: En este ejemplo mi interfaz de conexión de área local IPv6 tiene una MTU tan baja (1280) porque estoy usando un servicio de túnel para obtener conectividad IPv6 .

También puedes cambiar tu MTU (Windows 7, Windows Vista). Desde un prompt de comando elevado:

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

Probado con Windows 7 Service Pack 1

Windows XP

La sintaxis netsh para Windows XP es ligeramente 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: ** Windows XP requiere que se inicie el servicio **Routing and Remote Access antes de poder ver los detalles de una interfaz (incluyendo la MTU):

C:\Users\Ian>net start remoteaccesss

Windows XP no proporciona una forma de cambiar la configuración de la MTU desde el netsh. Para ello puede:

Testado con Windows XP Service Pack 3

Ver también

Breve discusión sobre qué es la MTU, de dónde vienen los 28 bytes.

Su tarjeta de red (Ethernet) tiene un tamaño máximo de paquete de 1,500 bytes:

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

La parte IP de TCP/IP requiere una cabecera de 20 bytes (12 bytes de banderas, 4 bytes para la dirección IP de origen, 4 bytes para la dirección IP de destino). Esto deja menos espacio disponible en el paquete:

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

Ahora un paquete ICMP (ping) tiene una cabecera de 8 bytes (1 byte type, 1 byte code, 2 bytes checksum, 4 bytes de datos adicionales):

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

Ahí es donde están los 28 bytes “perdidos” - es el tamaño de las cabeceras necesarias para enviar un paquete ping.

Cuando envías un paquete ping, puedes especificar cuántos datos extra de carga útil quieres incluir. En este caso, si incluyes los 1472 bytes:

>ping -l 1472 obsidian

Entonces el paquete ethernet resultante estará lleno hasta los topes. Se llenará hasta el último byte del paquete de 1500 bytes:

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

Si intenta enviar un byte más

>ping -l 1473 obsidian

la red tendrá que fragmentar ese paquete de 1501 bytes en múltiples paquetes:

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 fragmentación ocurrirá entre bastidores, idealmente sin que usted lo sepa.

Pero puedes ser malo, y decirle a la red que el paquete no puede ser fragmentado:

>ping -l 1473 -f obsidian

La bandera -f significa no fragmentar. Ahora cuando intentas enviar un paquete que no cabe en la red obtienes el error

>ping -l 1473 -f obsidian  

Packet needs to be fragmented but DF set.

El paquete necesita ser fragmentado, pero la bandera Do not Fragment fue puesta.

Si en algún punto de la línea un paquete necesitaba ser fragmentado, la red envía realmente un paquete ICMP diciéndole que ha ocurrido una fragmentación. Su máquina recibe este paquete ICMP, se le dice cuál era el tamaño más grande, y se supone que debe dejar de enviar paquetes demasiado grandes. Desgraciadamente, la mayoría de los cortafuegos bloquean estos paquetes ICMP de “descubrimiento de la MTU de la ruta”, por lo que tu máquina nunca se da cuenta de que los paquetes están siendo fragmentados (o peor aún: son descartados porque no pudieron ser fragmentados).

Eso es lo que hace que el servidor web no funcione. Puede obtener las respuestas iniciales pequeñas (<1280 bytes), pero los paquetes más grandes no pueden pasar. Y los firewalls del servidor web están mal configurados, bloqueando los paquetes ICMP. Así que el servidor web no se da cuenta de que nunca recibió el paquete.

La fragmentación de paquetes no está permitida en IPv6, todo el mundo está obligado a permitir (correctamente) los paquetes ICMP de descubrimiento de mtu.

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

@ian No estoy seguro de que netsh muestre realmente la MTU utilizada actualmente. En mi máquina Windows XP Pro SP3, ejecuté netsh interface ip show interface y reportó el valor de MTU para la interfaz relevante como 1500. A continuación, añadí las siguientes claves del 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 dice que si se pone EnablePMTUDiscovery a 0 se pondrá la MTU a 576.

La configuración de la entrada del registro MTU establece la MTU manualmente. He probado varios valores para la entrada MTU (reiniciando cada vez).

En ambos casos - añadiendo la primera entrada, luego la segunda - netsh seguía informando de que la MTU era de 1500. Las pruebas con ping confirmaron (o al menos sugirieron) que el valor de MTU configurado en el registro estaba siendo utilizado.

Además, cuando probé esto por primera vez en mi máquina, el servicio de Enrutamiento y Acceso Remoto estaba deshabilitado, por lo que no pude iniciarlo siguiendo tus instrucciones. Lo activé yendo al Panel de control | Herramientas de administración | Administración de equipos | Servicios y aplicaciones | Servicios. Cambié el “Tipo de inicio” de Desactivado a Manual. Luego inicié el servicio desde ese diálogo también.

Tampoco estoy seguro de que KB283165 sean necesariamente las instrucciones correctas para cambiar la MTU. ¿No son esas instrucciones sólo relevantes cuando se ejecuta el cliente PPPoE de Windows? Si se conecta a Internet a través de un router donde el router es el cliente PPPoE (como en mi caso), esas instrucciones no serían relevantes, ¿verdad?

Las instrucciones que seguí, que me llevaron a hacer los cambios anteriores en el registro, estaban en KB900926: Recommended TCP/IP settings for WAN links with a MTU size of less than 576 (methods 2 & 3).

  • *

Edit by @ian

Parece que tienes razón. Configurar para 1.200, pero netsh informa de 1500.

>ping -l 1173 -f obsidian

Packet needs to be fragmented but DF set.

Así que supongo que la respuesta a la pregunta original es que en Windows XP tienes que usar el método de prueba y error con la bandera Do not fragment para encontrar el paquete más grande que puedes enviar. Entonces tienes tu MTU.

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

Puede encontrar la MTU usando ping con un enfoque de prueba y error:

ping <address> -f -l nnnn

-f : Especifica que los mensajes Echo Request se envían con la bandera Don’t Fragment en la cabecera IP puesta a 1. El mensaje Echo Request no puede ser fragmentado por los routers en la ruta al destino. Este parámetro es útil para solucionar problemas de unidades de transmisión máximas en la ruta (PMTU).

-l Tamaño : Especifica la longitud, en bytes, del campo Datos en los mensajes Echo Request enviados. El valor predeterminado es 32. El tamaño máximo es 65.527.

Recibirá mensajes “Packet needs to be fragmented but DF set” cuando la longitud sea demasiado grande.

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

Microsoft KB314496: Los tamaños de MTU por defecto para diferentes topologías de red .
No debería intentar jugar con la configuración de MTU en configuraciones de red normales.

Hay una referencia de código VB aquí .
También existe una herramienta llamada DrTCP :


En el registro,

  • Vaya a HKLM\Software\Microsoft\Windows NT\CurrentVersion\NetworkCards
  • Abra el adaptador que le interesa
  • Copie la cadena ServiceName
  • Busque esa cadena en HKLM\System; coincidirá con una clave NetCfgInstanceId
  • Un poco más arriba estará la clave MaxFrameSize (la mía muestra 1514)

También hay una forma de cambiar esto con el comando netsh.

Además, compruebe su configuración de Path MTU Discovery .

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

Ver AdapterWatch :

AdapterWatch muestra información útil sobre sus adaptadores de red: Direcciones IP, Dirección de hardware, Servidores WINS, Servidores DNS, Valor MTU, Número de bytes recibidos o enviados, La velocidad de transferencia actual, y más. Además, muestra las estadísticas generales de TCP/IP/UDP/ICMP de su ordenador local.