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:
Probado con Windows XP Service Pack 3
Ver también
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.
