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.