Comment tester les Jumbo Frames sur un NAS domestique sans interrompre l'accès SMB
Testez les jumbo frames sur un chemin NAS isolé tout en conservant une route MTU 1500 vérifiée pour la récupération SMB.
Sur un réseau domestique, l’accès SMB peut traverser une carte réseau client, un port de commutateur, un VLAN, un pont, un commutateur virtuel, une interface NAS ou un chemin de routeur qui ne partagent pas la même limite de trame. L’objectif sûr n’est donc pas seulement d’entrer MTU 9000 sur deux appareils, mais de préserver un chemin de gestion fonctionnel, de prouver la totalité du chemin de test dans les deux sens, de comparer la même charge SMB avant et après le changement, et de revenir immédiatement en arrière lorsque les preuves indiquent un décalage MTU.
Enregistrez une Base de Référence MTU 1500 Connue et Fonctionnelle
Commencez avec le NAS, le client de test et le commutateur en utilisant leur MTU standard actuel, puis confirmez que le partage SMB se monte, s’explore, se lit, s’écrit, se reconnecte et survit à un redémarrage normal du client. Cette base de référence est l’état de récupération que vous devez pouvoir reproduire sans deviner.
Un MTU plus grand ne change que l’efficacité des paquets ; il ne supprime pas les limites de stockage, CPU, SMB ou client. L’explication de ZimaSpace sur pourquoi les jumbo frames peuvent ne pas améliorer les transferts NAS est utile ici car un test sûr nécessite à la fois une base de référence de connectivité et une base de référence de charge de travail.
Enregistrez le MTU actuel de l’interface, l’adresse IP, le VLAN, l’appartenance au pont, le chemin SMB et le résultat de transfert mesuré. Confirmez également que vous pouvez atteindre le NAS depuis un autre appareil qui restera en MTU 1500, ou organisez un accès console local avant de modifier la seule interface de gestion.
Cartographiez Chaque Saut dans le Chemin Exact du Test SMB
Tracez le chemin que le client choisi utilise réellement pour atteindre le NAS. Incluez les ports physiques du commutateur, les interfaces LAG ou pont, les sous-interfaces VLAN, les commutateurs hyperviseurs, les adaptateurs Ethernet USB, les interfaces de routeur et toute couche réseau de conteneur ou machine virtuelle impliquée dans le point de terminaison SMB.
La communication jumbo nécessite un support de trame de bout en bout car un appareil de couche 2 qui ne peut pas transmettre la trame plus grande peut la supprimer plutôt que de la redimensionner. Le point le plus petit supporté sur le chemin définit donc la taille de paquet utilisable.
Marquez chaque saut comme confirmé, inconnu ou hors test. N’activez pas les jumbo frames tant qu’un pont caché, un port de commutateur, un VLAN ou une frontière routée reste inconnu ; simplifiez d’abord le chemin ou gardez ce composant du côté MTU standard de l’expérience.
Modifiez l’Infrastructure Avant un Seul Point de Test
Augmentez d’abord la limite maximale de trame sur le commutateur ou le VLAN de stockage isolé, car augmenter une limite de commutateur permet normalement des trames plus grandes sans forcer les appareils ordinaires à les envoyer. Puis modifiez l’interface de test NAS et un seul client, en laissant tous les autres clients et le chemin de récupération intacts.
Les commutateurs implémentent la configuration MTU différemment : certains utilisent un maximum global, d’autres configurent des interfaces individuelles, et certains traitent séparément les MTU routés et commutés. Un nombre affiché sur une interface peut aussi décrire une couche différente de la valeur affichée par un autre appareil.
Appliquez un changement à la fois et enregistrez-le. Si le NAS n’a qu’une interface, ne commencez pas par la modifier à distance sans méthode de retour en arrière ; utilisez une fenêtre de maintenance, une seconde carte réseau, une console directe ou un VLAN de test pouvant être retiré indépendamment.
Vérifiez la Taille du Paquet dans les Deux Sens Avant d’Ouvrir SMB
Répétez d’abord un ping petit normal pour confirmer la portée de base, puis envoyez un paquet large avec fragmentation désactivée. Pour un MTU IPv4 de 9000, une charge utile de test courante est de 8972 octets car les en-têtes IP et ICMP utilisent les 28 octets restants.
Effectuez le test de paquet large du client vers le NAS et du NAS vers le client. Le succès dans un seul sens ne suffit pas : une gestion VLAN asymétrique, un commutateur virtuel ou un chemin de retour différent peut permettre un sens tout en supprimant silencieusement l’autre.
Si le paquet large échoue, réduisez la charge utile jusqu’à ce qu’il passe et identifiez le saut dont la limite configurée ou supportée correspond à ce plafond. Ne continuez pas le benchmarking SMB tant que la taille de paquet prévue ne réussit pas de manière répétée dans les deux sens sans avertissements de fragmentation, délais d’attente ou augmentation des erreurs d’interface.
Comparez la Même Charge SMB à MTU 1500 et au MTU de Test
Utilisez un gros fichier local, le même client, le même partage NAS, les mêmes stockages source et destination, et les mêmes paramètres de sécurité SMB. Exécutez assez longtemps pour dépasser le cache RAM et les rafales d’écriture courtes, puis enregistrez le débit, l’utilisation CPU, la latence, les retransmissions et si le partage se reconnecte normalement.
Un schéma pratique de dépannage communautaire est de tester les jumbo frames activés et désactivés plutôt que d’attribuer chaque changement de vitesse au MTU. Le résultat importe uniquement lorsque le chemin de paquet large est propre et que la charge de travail reste inchangée.
Interprétez le test A/B avec la carte des résultats suivante au lieu d’accepter un seul chiffre maximal :
| Résultat Observé | Signification Probable | Action Suivante |
|---|---|---|
| Ping large échoue et SMB se bloque | Incompatibilité MTU de bout en bout | Revenir en arrière sur le point de test et inspecter chaque saut |
| Ping large réussi mais SMB est plus lent | Le MTU n’est pas le goulot d’étranglement utile ou les erreurs augmentent sous charge | Vérifier CPU, stockage, retransmissions et compteurs d’interface |
| SMB s’améliore avec latence stable et pas d’erreurs | La charge testée bénéficie de ce chemin exact | Répéter avec des clients normaux et des tests de récupération avant un déploiement plus large |
| Pas de changement significatif | Les trames standard répondent déjà à la charge | Conserver MTU 1500 sauf si une autre charge mesurée en bénéficie |
Revenez en Arrière au Premier Problème de Connectivité ou d’Erreur
Le retour en arrière est nécessaire lorsque le montage SMB devient instable, que les paquets larges échouent dans un sens ou l’autre, que les retransmissions ou erreurs CRC augmentent, que les clients ordinaires perdent l’accès, ou que le test ne produit aucun bénéfice de charge répétable. Un test jumbo frame n’est pas réussi simplement parce qu’un benchmark se termine.
Ramenez d’abord le client de test à MTU 1500 pour qu’il puisse communiquer via le chemin connu bon, puis revenez sur l’interface de test NAS si nécessaire. Supprimez le VLAN de test ou l’override du commutateur seulement après avoir confirmé à nouveau l’accès SMB, l’exploration, l’écriture et la reconnexion en MTU standard.
Conservez les jumbo frames uniquement lorsque tout le chemin sélectionné est documenté, que la route de retour reste disponible, et que la charge réelle du NAS s’améliore sans nuire à la latence ou à la compatibilité. Sinon, le résultat correct du test est de conserver MTU 1500 plutôt que de continuer à ajuster une fonctionnalité qui n’a pas justifié son coût opérationnel.
Produits recommandés
Assistance et conseils
Plus à lire
Plex peut-il partager un GPU avec un autre conteneur Docker ?
Plex et un autre conteneur peuvent souvent accéder au même GPU, mais vous devez tester la prise en charge des pilotes, le mappage des...
Comment déterminer si une erreur Plex vient du client ou du serveur
Reproduisez le même élément sur un autre client, comparez le chemin de session, puis recueillez les preuves côté serveur uniquement après que la portée...
Comment configurer le cache de Plex et le stockage temporaire du transcodage
Protégez l’état persistant de Plex en plaçant les fichiers temporaires de transcodage sur un stockage local adapté, puis vérifiez le nettoyage, l’espace libre et...
