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.
Respuestas:
Responder a inquietudes individuales en la publicación ...
Con respecto al descubrimiento de la ruta MTU
Según su diagrama, acepto que PMTUD no puede funcionar entre dos PC diferentes en el mismo segmento LAN; Las PC no generan mensajes de error ICMP requeridos por PMTUD .
Marcos jumbo
Algunos proveedores (como Cisco) tienen modelos de conmutadores que admiten cargas útiles de Ethernet de más de 1500 bytes. Oficialmente, IEEE no respalda esta configuración , pero la industria tiene necesidades válidas para desviarse juiciosamente de la MTU original de 1500 bytes. Tengo redes LAN / de respaldo que aprovechan el marco gigante por una buena razón; sin embargo, me aseguré de que todas las MTU coincidieran dentro del mismo vlan cuando desplegué marcos jumbo.
MTU no coincidentes dentro de un dominio de difusión
La conclusión es que nunca debe haber MTU de Ethernet no coincidentes dentro del mismo dominio de difusión de Ethernet; si lo hace, es un error o error de configuración. Independientemente del error o error, debe resolver estos problemas, a veces manualmente.
Toda esa discusión lleva a la siguiente pregunta ...
No estoy seguro de estar de acuerdo ... No veo cómo la serie IEEE 802.3 o RFC 894 crean marcos no válidos. Las implementaciones de host o las configuraciones incorrectas de host crean marcos no válidos. Para comprender si su implementación sigue las especificaciones, necesitamos mucha más evidencia ...
Este diagrama es al menos evidencia prima facie de que sus MTU no coinciden dentro de un dominio de difusión ...
¿Cómo debe responder una implementación compatible con 802.3 a los desajustes de MTU?
MTU 1504 y MTU 1500 dentro del mismo dominio de difusión es simplemente una configuración incorrecta; nunca se debe esperar que funcione más que las máscaras de red IP no coincidentes, o se puede esperar que las subredes IP no coincidan. Su empresa tendrá que concentrarse y corregir la causa raíz de los desajustes de MTU ... en este momento es difícil decir si la causa raíz es un error del usuario, un error de implementación o alguna combinación de lo anterior.
Si las máquinas Windows afectadas están iniciando sesión con éxito en un dominio de Active Directory, uno podría escribir scripts de inicio de sesión de Windows para corregir automáticamente los problemas de MTU en función de algunas pruebas bien construidas dentro de los scripts de inicio de sesión de dominio (suponiendo que el controlador de dominio no sea parte de la MTU cuestiones).
Si las máquinas no inician sesión en un dominio, el trabajo manual es otra opción.
Otras posibilidades para contener el daño.
Utilice un conmutador de capa 3 Nota 1 para crear un vlan personalizado para cualquier cosa que haya roto MTU y configure la MTU de ethernet del conmutador de capa 3 para que coincida con las máquinas rotas; Esto se basa en PMTUD para resolver los problemas de MTU en la capa IP. Los conmutadores de capa 3 generan los errores ICMP requeridos por PMTUD .
Esta opción funciona mejor si puede redirigir las máquinas rotas con DHCP; y puede identificar las máquinas rotas por la dirección mac.
Difícil de decir en este momento
802.1ad vs 802.1q
No he visto evidencia hasta ahora de que estés usando QinQ ; De la evidencia limitada que he visto hasta ahora, está utilizando la encapsulación 802.1q simple , que debería funcionar correctamente en Windows, suponiendo que el controlador NIC sea compatible con la encapsulación 802.1q.
Notas finales :
Nota 1 Cualquier conmutador de capa 3 debería hacer ... Cisco, Juniper y Brocades podrían realizar este tipo de función.
fuente
Puedo intentar responder a tu pregunta conceptual.
No puedo encontrar una cotización real, pero parece bastante claro que .1ad y .1q nunca fueron diseñados para ser procesados por PC u otros hosts finales. Se procesan (generalmente) solo con equipos de infraestructura. No sé lo que pensaban los diseñadores, pero es difícil imaginar que los paquetes QinQ vayan a una PC en un escenario de la vida real. Las interfaces Ethernet en equipos de infraestructura (rutas, conmutadores, etc.) pueden manejar paquetes más grandes.
Por lo tanto, los paquetes solo son inválidos para PC, que en teoría nunca deberían verlos.
fuente