Recientemente he estado lidiando con problemas de MTU . Y todo parece derivarse del hecho de que el adaptador de Ethernet en las computadoras más nuevas tiene un tamaño de trama predeterminado de 1504 bytes:
>netsh interface ipv4 show subinterfaces
MTU MediaSenseState Bytes In Bytes Out Interface
------ --------------- --------- --------- -------------
1504 1 3954161316 804790885 Local Area Connection
Ahora, según una persona aleatoria en NetworkEngineering.stackexchange.com , cualquier paquete que sea demasiado grande será descartado por cualquier Tarjeta de interfaz de red (NIC) receptora, ya que el paquete de Ethernet es demasiado grande:
... cualquier cuadro con una MTU mayor que la especificación 802.3 de 1500
Un marco más grande que el conjunto máximo será dado de baja por el NIC - es un error, y el sistema operativo no sabe nada al respecto. (un contador de cuadros de gran tamaño hará clic, pero eso es todo).
Lo que causa problemas cuando la computadora intenta enviar paquetes a la máquina de la puerta de enlace. Lo ideal sería confiar en el descubrimiento de Path MTU . Pero dado que los paquetes de Ethernet que se generan son demasiado grandes para que los reciba cualquier otra máquina, no hay oportunidad de que se devuelvan mensajes de fragmentación demasiado grandes del paquete IP :
No habrá "fragmentación" en absoluto. La capa 2 (ethernet) no tiene ningún medio si indica "fragmentación necesaria". Esto se calcula en la capa 3 (IP) mediante enrutadores que envían un mensaje ICMP cuando tiene que descartar el paquete porque no cabe en la interfaz del siguiente salto.
Lo que me lleva a mi segunda pregunta primero:
- ¿Por qué hay una especificación que crea intencionalmente marcos de ethernet no válidos? ¿Cuál es el comportamiento previsto aquí? Dado que otras tarjetas de interfaz de red no pueden recibir estos nuevos paquetes de tamaño predeterminado, ¿qué esperaban que sucediera?
Esto luego me lleva a mi primera pregunta en segundo lugar. Y esto es algo que se ha preguntado antes, mucho.
- ¿Es la etiqueta QinQ de 4 bytes parte del encabezado del marco de ethernet o parte de la carga útil de ethernet? Si es parte del encabezado, ¿por qué el cuerpo de la carga útil aumentó en 4 bytes? Si es parte de la carga útil de Ethernet, ¿por qué la MTU de carga aumenta en 4 bytes (cuando sabemos que aumentarla en 4 bytes lo convierte en un paquete no válido)?
La pregunta más grande es ...
Si retrocedemos por un momento, tenemos la pregunta más grande:
¿Que se supone que hagamos?
Debe haber personas que diseñaron este estándar. ¿Qué esperaban que hicieran las personas con los dispositivos que generan estos paquetes demasiado grandes ?
Realmente estoy preguntando. Supongo que no estábamos destinados a ir a todos los dispositivos de hardware y deshacer el aumento del MTU 1504 y revertirlo a 1500:
netsh interface ipv4>set subinterface "Local Area Connection" mtu=1500 store=persistent
Ok.
eso sería (y está siendo) una pesadilla de configuración.
¿Quizás la idea es desactivar el etiquetado de VLAN? Aparte de la pesadilla de configuración, simplemente no funciona:
Paso 1: deshabilite el etiquetado de VLAN
Paso 2: observa que no funciona:
interfaz netsh ipv4 mostrar subinterfaces
MTU MediaSenseState Bytes In Bytes Out Interface
1504 1 238125 245855 Local Area Connection
Si la solución a esto es forzar manualmente todas las tarjetas de red a una MTU de 1500, ¿por qué lo aumentaron a 1504 bytes y crearon paquetes inválidos, en primer lugar?
Hay una pieza del rompecabezas que me estoy perdiendo.
Chatter de bonificación
Without 802.1Q tagging Without 802.1Q tagging
+------------------------+ +------------------------+
|Destination MAC: 6 bytes| |Destination MAC: 6 bytes|
|Source MAC: 6 bytes | |Source MAC: 6 bytes |
|Ethertype: 2 bytes | |802.1Q tag: 4 bytes |
+------------------------+ |Ethertype: 2 bytes |
| | +------------------------+
| | | |
/ Payload: 1500 bytes / / Payload: 1500 bytes /
| | | |
| | | |
+------------------------+ | |
| Frame Check Sequence: | +------------------------+
| 4 bytes| | Frame Check Sequence: |
+------------------------+ | 4 bytes|
+------------------------+
Diagrama de Red
+------------------+ +----------------+ +------------------+
| Realtek PCIe GBe | | NetGear 10/100 | | Realtek 10/100 |
| (on-board) | | Switch | | (on-board) |
| | +----------------+ | |
| Windows 7 | ^ ^ | |
| | | | | |
| 192.168.1.98/24 |-----------+ +------------| 192.168.1.10/24 |
| MTU = 1504 bytes | | MTU = 1500 bytes |
+------------------+ +------------------+
También puede sustituir cualquier configuración que desee, generando paquetes más grandes que los 1500bytes máximos permitidos :
+------------------+ +----------------+ +------------------+
| Realtek PCIe GBe | | NetGear 10/100 | | Realtek 10/100 |
| (on-board) | | Switch | | (on-board) |
| | +----------------+ | |
| Windows 7 | ^ ^ | MTU = 1500 bytes |
| MTU = 16384bytes | | | | |
| |-----------+ +------------| |
+------------------+ +------------------+
Estoy tratando de encontrar un sitio que pueda abordar mi problema técnico, conceptual, lógico, fundamental y teórico de cómo Ethernet puede funcionar cuando algunos dispositivos generan intencionalmente paquetes no válidos.
La preocupación surge cuando intento enviar un paquete Ethernet no válido a otro dispositivo Ethernet:
la computadora genera el paquete de Ethernet
Source MAC: xx-xx-xx-xx-xx-xx Destination MAC: yy-yy-yy-yy-yy-yy Ethertype: 0x0800 Payload: ...1504 bytes... (or could be ...16384 bytes, anything larger than 1500...) CRC: 4 bytes
Este paquete no es válido porque es demasiado grande para ser recibido por el dispositivo 802.3u de destino. Debido a que el sistema operativo host del destino nunca ve el paquete, y porque Ethernet no tiene funcionalidad para informar los paquetes no válidos al remitente, se pierde el paquete "grande" .
Chatter de bonificación
Desde el enlace entre conmutadores de Cisco y el formato de trama IEEE 802.1Q :
Tamaño del marco
La unidad de transmisión máxima (MTU) predeterminada de una interfaz es 1500 bytes. Con una etiqueta VLAN externa unida a una trama de Ethernet, el tamaño del paquete aumenta en 4 bytes. Por lo tanto, es aconsejable que aumente adecuadamente la MTU de cada interfaz en la red del proveedor. La MTU mínima recomendada es de 1504 bytes.
Mientras tanto:
El estándar Ethernet IEEE 802.3 solo exige el soporte para tramas MTU de 1500 bytes.