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

Estoy sufriendo un problema realmente extraño en el que recibo al azar los errores "Se restableció la conexión al servidor" al intentar acceder a las páginas web (error HTTP 12031 de acuerdo con la herramienta de diagnóstico de red de Windows), esto sucede independientemente de si la página web Estoy tratando de acceder está en Internet externo o incluso si es de una instancia local de Apache que se ejecuta en localhost. Afecta a todas las computadoras de nuestra red local (Ethernet, no inalámbrica), todas las cuales ejecutan 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 Ping para descubrir el paquete más grande que puede pasar sin fragmentar, puedo hacer ping al host local con un paquete de 1492 bytes (¿+28 bytes para un encabezado?) Y puedo hacer ping a nuestro enrutador con un paquete de 1462 bytes (que es 1490 bytes cuando incluye el encabezado de 28 bytes). Si trato de hacer ping en el exterior como Google, no puedo obtener nada más grande que 1430 (que es 1458 con el encabezado).

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 intentado un sinfín de valores alternativos: el valor correcto más obvio parece ser 1490, pero también he intentado 1462, 1458, 1430, etc., etc. Cuando reinicio la computadora para que el cambio surta efecto, parece funcionar durante unos minutos (es difícil saberlo con certeza ya que siempre es aleatorio en lugar de coherente) pero nunca dura mucho.

Inicialmente, cuando estaba probando 1430 como valor, después de unos minutos de trabajar bien, los resultados de la Prueba Ping disminuyeron en 28 bytes; de repente, descubrí que solo podía enviar un paquete de 1402 bytes a Google. Si actualicé la configuración del registro MTU a 1402, cuando reinicié y esperé unos minutos, sería 1374, luego 1346, etc. etc. Otras computadoras en la red no se vieron afectadas (todavía en 1430) y eliminaron la configuración MTU desde el registro restauraría las cosas a la normalidad (y todavía está roto)

Lo que me resulta más difícil de diagnosticar todo esto es que es muy difícil saber si incluso estoy jugando con la configuración de registro correcta. Entonces, en mi 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 un archivo de registro de Windows en algún lugar donde registre algo en el punto donde cambia el valor?)

Finalmente, si alguien me puede decir definitivamente cómo saber qué configuración de MTU debería tratar de usar, ¡sería genial!

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

Windows 7, Windows Vista

Para mostrar la MTU actual en Windows 7 o Windows Vista, desde un símbolo del sistema:

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 las 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 IPv6 de Conexión de área local tiene una MTU tan baja (1280) porque estoy usando un servicio de túnel para obtener conectividad IPv6 .

También puede cambiar su MTU (Windows 7, Windows Vista). Desde un símbolo del sistema elevado :

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

Probado con Windows 7 Service Pack 1

Windows XP

La netshsintaxis 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 de enrutamiento y acceso remoto antes de que pueda ver detalles sobre una interfaz (incluida MTU):

C:\Users\Ian>net start remoteaccesss

Windows XP no proporciona una forma de cambiar la configuración de MTU desde dentro netsh. Para eso puedes:

• siga las instrucciones en KB283165 - Cómo cambiar el tamaño de la MTU PPPoE en Windows XP
• use Dr. TCP ( Nota: solo Windows 2000 / XP)

Probado con Windows XP Service Pack 3

Ver también

• Configure el tamaño de la unidad de transferencia máxima de TCPIP (MTU) en Vista
• Configuración de la MTU en Windows Vista
• Cambiar la configuración de MTU ¡Ayuda!
• KB283165 - Cómo cambiar el tamaño de la MTU PPPoE en Windows XP
• DSLReports - DrTCP

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

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

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

La porción IP de TCP / IP requiere un encabezado 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 un encabezado de 8 bytes (1 byte type, 1 byte code, 2 byte checksum, 4 byte 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 "faltantes": es el tamaño de los encabezados necesarios para enviar un paquete de ping.

Cuando envía un paquete de ping, puede especificar cuántos datos de carga útil adicionales desea incluir. En este caso, si incluye todos los 1472 bytes:

>ping -l 1472 obsidian

Entonces el paquete de ethernet resultante estará lleno hasta las agallas. Se completará cada ú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 intentas 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á detrás de escena, idealmente sin que lo sepas.

Pero puede ser malo y decirle a la red que el paquete no puede fragmentarse:

>ping -l 1473 -f obsidian

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

>ping -l 1473 -f obsidian  

Packet needs to be fragmented but DF set.

El paquete debe fragmentarse, pero se configuró el indicador No fragmentar .

Si en algún punto de la línea se necesita fragmentar un paquete, la red en realidad envía un paquete ICMP que le informa que ocurrió 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 deja de enviar paquetes demasiado grandes. Desafortunadamente, la mayoría de los cortafuegos bloquean estos paquetes ICMP "Path MTU discovery", por lo que su máquina nunca se da cuenta de que los paquetes están fragmentados (o peor aún, se descartan porque no pueden fragmentarse).

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 cortafuegos del servidor web están mal configurados, lo que bloquea los paquetes ICMP. Por lo tanto, el servidor web no se da cuenta de que nunca recibió el paquete.

La fragmentación de paquetes no está permitida en IPv6, todos están obligados (correctamente) a permitir paquetes de descubrimiento ICMP mtu.

@ian No estoy tan seguro de que netshrealmente muestre la MTU utilizada actualmente. En mi máquina Windows XP Pro SP3, ejecuté netsh interface ip show interfacee informó el valor de MTU para la interfaz relevante como 1500. Luego agregué las siguientes claves de 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 establecerlo EnablePMTUDiscoveryen 0 establecerá MTU en 576.

Establecer la MTUentrada del registro establece la MTU manualmente. Intenté varios valores para la MTUentrada (reiniciar cada vez).

En ambos casos, agregando la primera entrada, luego la segunda entrada, netshtodavía se informó que la MTU era 1500. Las pruebas con ping confirmaron (o al menos sugirieron) que el valor de MTU configurado en el registro se estaba utilizando.

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 usando sus instrucciones. Lo habilité yendo a Panel de control> Herramientas administrativas> Administración de computadoras> Servicios y aplicaciones> Servicios. Cambié "Tipo de inicio" de Deshabilitado a Manual. Luego comencé el servicio desde ese diálogo también.

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

Las instrucciones que seguí, que me llevaron a realizar los cambios anteriores en el registro, estaban en KB900926: Configuración de TCP / IP recomendada para enlaces WAN con un tamaño de MTU inferior a 576 (métodos 2 y 3).

Editar por @ian

Parece que tienes razón. Configurar para 1.200, pero netshinformes 1500.

>ping -l 1173 -f obsidian

Packet needs to be fragmented but DF set.

Entonces, supongo que la respuesta a la pregunta original es que en Windows XP debe usar prueba y error con el indicador No fragmentar para encontrar el paquete más grande que puede enviar. Entonces tienes tu MTU.

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

ping <address> -f -l nnnn

Ping :

-f: especifica que los mensajes de solicitud de eco se envían con el indicador No fragmentar en el encabezado IP establecido en 1. El enrutador no puede fragmentar el mensaje de solicitud de eco en la ruta al destino. Este parámetro es útil para solucionar problemas de la Unidad de transmisión máxima (PMTU) de la ruta.

-l Tamaño: especifica la longitud, en bytes, del campo de datos en los mensajes de solicitud de eco enviados. El valor predeterminado es 32. El tamaño máximo es 65.527.

Recibirá mensajes de "El paquete debe estar fragmentado pero el DF está configurado" cuando la longitud es demasiado grande.

Ver AdapterWatch :

AdapterWatch muestra información útil sobre sus adaptadores de red: direcciones IP, dirección de hardware, servidores WINS, servidores DNS, valor de MTU, número de bytes recibidos o enviados, la velocidad de transferencia actual y más. Además, muestra estadísticas generales de TCP / IP / UDP / ICMP para su computadora local.

Microsoft KB314496: los tamaños de MTU predeterminados para diferentes topologías de red .
No debe intentar jugar con la configuración MTU en configuraciones de red normales.

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

En el registro,

• Ir HKLM\Software\Microsoft\Windows NT\CurrentVersion\NetworkCards
• Abra el adaptador que le interesa.
• Copia la ServiceNamecadena
• Buscar esa cadena en HKLM\System; coincidirás con una NetCfgInstanceIdllave
• Un poco más arriba será la MaxFrameSizeclave (la mía muestra 1514)

También hay una manera de cambiar esto con el netshcomando.

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