Version courte

Mon réseau domestique est un gigabit pur avec des appareils qui prennent tous en charge des trames jumbo jusqu'à au moins ~ 9000 octets. L'augmentation du paramètre de trame jumbo MTU sur le Synology à 6000 (octets) augmente les performances (810 Mbps en écriture et 945 Mbps en lecture). La définition de la valeur à 7000 détruit uniquement les performances de lecture (ce qui diminue jusqu'à 4 Mbps); les performances d'écriture restent rapides.

Ceci est inattendu car la plupart des problèmes de trames jumbo n'ont pas de directionnalité qui leur sont associés et sont généralement tout ou rien (les paquets sont déposés à un commutateur, peu importe d'où ils viennent). Il ne semble pas y avoir de fragmentation IP, mais la couche TCP est vraiment mécontente. Qu'est-ce qui pourrait provoquer ce comportement asymétrique / irrégulier et comment puis-je le corriger pour prendre en charge la MTU complète de 9 000 octets que tout mon équipement est censé prendre en charge?

Version longue

Ce sont mes notes éditées prises en essayant de comprendre cela.

Client

Realtek PCIe GBE Family Controller RTL8167
Jumbo Frame: 9KB MTU

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

(apparaît que 9198 n'inclut pas l'en-tête Ethernet de 14 octets)

$ ping -l 1500 -f 192.168.1.84

(observé avec Wireshark exécuté sur le client; toutes les tailles sont des tailles d'octets de fil)
[9213, ∞] non envoyé par l'hôte (nécessiterait une fragmentation)
[9019, 9212] envoyé mais pas de réponse
[9015, 9018] réponse IP fragmentée
[42, 9014 ] IP non fragmentée
[0, 41]? (impossible de générer car les en-têtes eth + IP + ICMP = 14 + 20 + 8 = 42 octets)

Routeur (partie commutateur)

Asus RT-AC68U - Firmware 3.0.0.4.378_4585
Enable Jumbo Frame: "Enable"
Impossible de déterminer la taille de trame jumbo qu'il prend en charge, semble être au moins 9000

Il fragmente les requêtes ping du client à 1514 octets (mais le ping du routeur peut déclencher son comportement de routeur WAN au lieu de son comportement de commutateur LAN?)

Commutateur non géré

Cadres Jumbo TP-LINK TL-SG1008D (fiches techniques): 9 Ko (leur site Web dit 15 Ko mais il ressemble à un appareil différent)

Serveur

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

Paquets de lecture de fichiers de Synology à la
taille du client : la plupart sont de 9014 octets (dans les deux sens)
Indicateurs IP: ne fragmentez pas
Wireshark découvert: TCP Spurious Retransmission, TCP segment précédent non capturé, TCP Out-Of-Order, TCP Fast Retransmission, et paquets normaux (9014 octets) paquets
SMB2 sur protocole NetBIOS lisent réponse longueur de lecture: 65 536 (~ 8 segments 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 et eth3 sont liés à l'aide de l'équilibrage de charge adaptatif (pas de prise en charge de commutateur)

$ ping -c 5 -s 1500 192.168.1.82

(observé avec Wireshark en cours d'exécution sur le client; toutes les tailles sont des tailles d'octets)
[9019,,] demande envoyée, réponse envoyée, réponse non reçue
[9015, 9018] demande IP fragmentée (probablement fragmentée par Synology, le ping de la boîte occupée n'a pas option sans fragment, il est donc difficile de dire)
[60, 9014] IP non fragmentée
[0, 59]? (impossible de générer car le ping de la boîte occupée met au minimum 18 octets plus les en-têtes de 42 octets)

Données diverses

• La modification du MTU client à 8 Ko n'a pas aidé
• La vitesse de lecture du serveur tombe d'une falaise lors du changement de la MTU du serveur de 6000 (excellent, 945 Mbps) à 7000 (terrible, 4 Mbps)
• La vitesse d'écriture du serveur n'est pratiquement pas affectée à tous les paramètres MTU du serveur (toujours entre 700 et 825 Mbps)
• Le Synology a un réseau lié (2 des 4 ports)
• Les câbles sont tous Cat6 ou Cat5e

Mettre à jour le firmware

D'après mon expérience, Synology corrige de nombreux problèmes dans chaque version du micrologiciel et celui que vous utilisez a presque quatre ans. Je n'ai pas lu les notes de publication, mais il semble qu'il y ait beaucoup de possibilités pour qu'un bug de trame Jumbo ait été corrigé depuis.

Test avec une connexion directe

Connectez votre machine de test directement au Synology (attribuez des adresses IP statiques sur le même sous-réseau) avec de nouveaux câbles de raccordement et réexécutez vos tests. Cela éliminera le câblage et les commutateurs ainsi que tout autre problème d'équipement et de configuration. Si le problème persiste, exécutez vos tests avec un autre ordinateur. S'il reste encore, c'est certainement le NAS.

Si le problème disparaît pendant le test de connexion directe, essayez d'abord de remplacer le commutateur, puis le câblage. Vous n'avez pas montré les connexions, donc je suppose que le TPLINK entre la machine de test et le NAS.