31.4. Améliorer le débit de grandes quantités de flux de données contigus
Selon la norme IEEE 802.3, une trame Ethernet par défaut sans balise VLAN (Virtual Local Area Network) a une taille maximale de 1518 octets. Chacune de ces trames comprend un en-tête de 18 octets, ce qui laisse 1500 octets pour la charge utile. Par conséquent, pour chaque 1500 octets de données que le serveur transmet sur le réseau, 18 octets (1,2 %) d'en-tête de trame Ethernet sont surchargés et transmis également. Les en-têtes des protocoles des couches 3 et 4 augmentent encore le surdébit par paquet.
Envisagez d'utiliser des trames jumbo pour réduire la charge de travail si les hôtes de votre réseau envoient souvent de nombreux flux de données contigus, tels que les serveurs de sauvegarde ou les serveurs de fichiers hébergeant de nombreux fichiers volumineux. Les trames jumbo sont des trames non standardisées dont l'unité de transmission maximale (MTU) est supérieure à la taille de la charge utile Ethernet standard de 1 500 octets. Par exemple, si vous configurez des trames jumbo avec l'UTM maximale autorisée de 9000 octets de charge utile, la surcharge de chaque trame est réduite à 0,2 %.
En fonction du réseau et des services, il peut être intéressant de n'activer les trames jumbo que dans des parties spécifiques d'un réseau, comme le backend de stockage d'un cluster. Cela permet d'éviter la fragmentation des paquets.
31.4.1. Considérations à prendre en compte avant de configurer des trames jumbo
Selon le matériel, les applications et les services de votre réseau, les trames jumbo peuvent avoir différents impacts. Décidez avec soin si l'activation des trames jumbo présente un avantage dans votre scénario.
Conditions préalables
Tous les périphériques du réseau sur le chemin de transmission doivent prendre en charge les trames jumbo et utiliser la même taille d'unité de transmission maximale (MTU). Dans le cas contraire, vous risquez de rencontrer les problèmes suivants :
- Paquets abandonnés.
- Temps de latence plus élevé en raison de la fragmentation des paquets.
- Risque accru de perte de paquets causé par la fragmentation. Par exemple, si un routeur fragmente une trame unique de 9000 octets en six trames de 1500 octets et que l'une de ces trames de 1500 octets est perdue, la trame entière est perdue car elle ne peut pas être réassemblée.
Dans le diagramme suivant, tous les hôtes des trois sous-réseaux doivent utiliser le même MTU si un hôte du réseau A envoie un paquet à un hôte du réseau C :
Avantages des trames jumbo
- Débit plus élevé : Chaque trame contient plus de données utilisateur alors que la surcharge du protocole est fixe.
- Réduction de l'utilisation de l'unité centrale : Les trames Jumbo provoquent moins d'interruptions et permettent donc d'économiser des cycles de CPU.
Inconvénients des trames jumbo
- Temps de latence plus élevé : Les trames plus grandes retardent les paquets qui les suivent.
- Augmentation de l'utilisation de la mémoire tampon : Les trames plus grandes peuvent remplir plus rapidement la mémoire de la file d'attente.
31.4.2. Configuration du MTU dans un profil de connexion NetworkManager existant
Si votre réseau requiert une unité de transmission maximale (MTU) différente de celle par défaut, vous pouvez configurer ce paramètre dans le profil de connexion NetworkManager correspondant.
Les trames Jumbo sont des paquets réseau dont la charge utile est comprise entre 1500 et 9000 octets. Tous les appareils du même domaine de diffusion doivent prendre en charge ces trames.
Conditions préalables
- Tous les appareils du domaine de diffusion utilisent le même MTU.
- Vous connaissez le MTU du réseau.
- Vous avez déjà configuré un profil de connexion pour le réseau avec le MTU divergent.
Procédure
Facultatif : Affiche le MTU actuel :
# ip link show ... 3: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000 link/ether 52:54:00:74:79:56 brd ff:ff:ff:ff:ff:ff ...
Optionnel : Afficher les profils de connexion de NetworkManager :
# nmcli connection show NAME UUID TYPE DEVICE Example f2f33f29-bb5c-3a07-9069-be72eaec3ecf ethernet enp1s0 ...
Définissez le MTU dans le profil qui gère la connexion au réseau avec le MTU divergent :
# nmcli connection modify Example mtu 9000Réactiver la connexion :
# nmcli connection up Example
Vérification
Affichez le paramètre MTU :
# ip link show ... 3: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc fq_codel state UP mode DEFAULT group default qlen 1000 link/ether 52:54:00:74:79:56 brd ff:ff:ff:ff:ff:ff ...
Vérifiez qu'aucun hôte sur les chemins de transmission ne fragmente les paquets :
Du côté du récepteur, afficher les statistiques de réassemblage IP du noyau :
# nstat -az IpReasm* #kernel IpReasmTimeout 0 0.0 IpReasmReqds 0 0.0 IpReasmOKs 0 0.0 IpReasmFails 0 0.0Si les compteurs retournent
0, les paquets n'ont pas été réassemblés.Du côté de l'expéditeur, transmettre une requête ICMP avec le bit d'interdiction de fragmentation :
# ping -c1 -Mdo -s 8972 destination_hostSi la commande réussit, le paquet n'a pas été fragmenté.
Calculez la valeur de l'option
-spacket size comme suit : Taille MTU - 8 octets En-tête ICMP - 20 octets En-tête IPv4 = taille du paquet
