Version corta

Mi red doméstica es puramente gigabit con dispositivos que admiten marcos jumbo de al menos ~ 9000 bytes. Aumentar la configuración del marco jumbo MTU en Synology a 6000 (bytes) aumenta el rendimiento (810 Mbps de escritura y 945 Mbps de lectura). Establecer el valor en 7000 destruye solo el rendimiento de lectura (que disminuye hasta 4Mbps); El rendimiento de escritura se mantiene rápido.

Esto es inesperado porque la mayoría de los problemas de trama gigante no tienen una direccionalidad asociada con ellos y generalmente son todo o nada (los paquetes se descartan en un conmutador, sin importar de dónde provienen). No parece haber ninguna fragmentación de IP en absoluto, pero la capa TCP es realmente infeliz. ¿Qué podría causar este comportamiento asimétrico / escamoso y cómo puedo solucionarlo para admitir la MTU de 9000 bytes completa que se supone que admite todo mi equipo?

Versión larga

Estas son mis notas editadas tomadas al tratar de resolver esto.

Cliente

Controlador de la familia Realtek PCIe GBE
Marco Jumbo RTL8167 : MTU de 9 KB

$ netsh interface ipv4 show subinterfaces
   MTU  MediaSenseState   Bytes In  Bytes Out  Interface
------  ---------------  ---------  ---------  -------------
  9198                1   32501506   11275394  Local Area Connection

(parece que 9198 no incluye el encabezado ethernet de 14 bytes)

$ ping -l 1500 -f 192.168.1.84

(observado con Wireshark ejecutándose en el Cliente; todos los tamaños son tamaños de bytes de cable)
[9213, ∞] no enviado por el host (requeriría fragmentación)
[9019, 9212] enviado pero sin respuesta
[9015, 9018] respuesta IP fragmentada
[42, 9014 ] IP no fragmentada
[0, 41]? (no se puede generar ya que los encabezados eth + IP + ICMP = 14 + 20 + 8 = 42 bytes)

Enrutador (parte del interruptor)

Asus RT-AC68U - Firmware 3.0.0.4.378_4585
Habilitar trama jumbo: "Habilitar"
No se puede determinar qué tamaño de trama jumbo es realmente compatible, parece ser al menos 9000

Fragmenta las solicitudes de ping del Cliente a 1514 bytes (¿pero hacer ping al enrutador podría estar activando su comportamiento de enrutador WAN en lugar de su comportamiento de conmutador LAN?)

Switch no administrado

Marcos Jumbo TP-LINK TL-SG1008D (hojas de especificaciones): 9 KB (su sitio web dice 15 KB pero parece un dispositivo diferente)

Servidor

Synology DS1815 + - DSM 5.2-5565 Update 1
Jumbo Frame: 9000

Paquetes de lectura de archivos desde Synology al
tamaño del cliente : la mayoría son 9014 bytes (en ambas direcciones)
Indicadores IP: no fragmente
Wireshark descubierto: retransmisión espuria TCP, segmento anterior TCP no capturado, TCP fuera de servicio, retransmisión rápida TCP, y paquetes normales (9014 bytes) Paquetes
de protocolo SMB2 sobre NetBIOS longitud de lectura de respuesta de lectura: 65,536 (~ 8 segmentos TCP)

$ ifconfig
bond0     Link encap:Ethernet  HWaddr --:FF
          inet addr:192.168.1.84  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addrs: --/64 Scope:Link, --/64 Scope:Global, --/64 Scope:Global
          UP BROADCAST RUNNING MASTER MULTICAST  MTU:9000  Metric:1
          RX packets:lots errors:85 dropped:0 overruns:0 frame:85
          TX packets:lots errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:237 GiB  TX bytes:117 GiB

eth2      Link encap:Ethernet  HWaddr --:00
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:9000  Metric:1
          RX packets:lots errors:19 dropped:0 overruns:0 frame:19
          TX packets:lots errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:236 GiB  TX bytes:83 GiB

eth3      Link encap:Ethernet  HWaddr --FF
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:9000  Metric:1
          RX packets:lots errors:66 dropped:0 overruns:0 frame:66
          TX packets:lots errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1 GiB  TX bytes:33 GiB

eth2 y eth3 están unidos mediante el Equilibrio de carga adaptativo (sin soporte de interruptor)

$ ping -c 5 -s 1500 192.168.1.82

(observado con Wireshark ejecutándose en el Cliente; todos los tamaños son tamaños de bytes de cable)
[9019, ∞] solicitud enviada, respuesta enviada, respuesta no recibida
[9015, 9018] solicitud de IP fragmentada (probablemente fragmentada por Synology, busybox ping no tiene un opción sin fragmentos, por lo que es difícil saber)
[60, 9014] IP no fragmentada
[0, 59]? (no se puede generar porque el ping de busybox pone como mínimo 18 bytes más los encabezados de 42 bytes)

Datos misceláneos

• Cambiar la MTU del cliente a 8 KB no ayudó
• La velocidad de lectura del servidor cae por un precipicio cuando se cambia la MTU del servidor de 6000 (excelente, 945 Mbps) a 7000 (terrible, 4 Mbps)
• La velocidad de escritura del servidor básicamente no se ve afectada en todas las configuraciones de MTU del servidor (siempre entre 700 y 825 Mbps)
• Synology tiene una red unida (2 de los 4 puertos)
• Los cables son todos Cat6 o Cat5e

Actualiza el firmware

En mi experiencia, Synology soluciona muchos problemas en cada versión de firmware y el que está ejecutando tiene casi cuatro años. No he leído las notas de la versión, pero parece que hay muchas oportunidades para que se haya solucionado un error de marco Jumbo desde entonces.

Prueba con una conexión directa

Conecte su máquina de prueba directamente a Synology (asigne IP estáticas en la misma subred) con nuevos cables de conexión y vuelva a ejecutar sus pruebas. Esto eliminará el cableado y los interruptores, así como cualquier otro equipo y problemas de configuración. Si el problema persiste, ejecute sus pruebas con otra computadora. Si aún permanece, ciertamente es el NAS.

Si el problema desaparece durante la prueba de conexión directa, intente reemplazar primero el interruptor y luego el cableado. No ha mostrado las conexiones, así que supongo que solo el TPLINK entre la máquina de prueba y el NAS.