Unité de transmission maximale (original) (raw)
L'unité de transmission maximale (MTU) correspond à la taille, en octets, du plus grand paquet IP possible, englobant les en-têtes IP, les en-têtes de protocole de couche 4 et les données de couche 4 pouvant figurer dans une trame Ethernet.
Tailles de MTU valides pour le réseau VPC
Les réseaux de cloud privé virtuel (VPC) utilisent une MTU par défaut de 1 460 octets. Vous pouvez définir la MTU d'un réseau VPC sur n'importe quelle valeur comprise entre 1 300 octets et 8 896 octets (inclus). Les tailles de MTU personnalisées les plus courantes sont de 1 500 octets (le standard Ethernet) ou de 8 896 octets (le maximum possible). Nous vous recommandons de configurer la MTU de chaque interface réseau d'instance Compute Engine de sorte qu'elle corresponde à la MTU du réseau VPC auquel elle est connectée. Pour en savoir plus, consultez Instances de calcul et paramètres MTU.
Communication entre les instances de calcul dans les réseaux VPC
Des paquets IP dont la taille peut atteindre la MTU peuvent être envoyés entre deux instances de calcul, si les conditions suivantes sont remplies :
- Les instances d'envoi et de réception utilisent le même réseau VPC ou des réseaux VPC appairés ayant des MTU identiques.
- Les interfaces des deux instances sont configurées pour utiliser la MTU du réseau VPC.
Pour éviter les problèmes de non-concordance de MTU, nous vous recommandons d'utiliser la même MTU pour tous vos réseaux VPC connectés. Bien que cela constitue la pratique recommandée, vous n'êtes pas obligé de configurer des MTU identiques sur les réseaux VPC connectés. Pour en savoir plus sur la manière dont les protocoles gèrent les cas de non-concordance de MTU entre réseaux VPC, consultez la section MTU non concordantes, limitation de la taille MSS, détection de MTU de chemin.
Du point de vue d'une instance émettrice, les chemins d'accès aux destinations suivantes représentent le trafic entre plusieurs instances acheminé au sein d'un réseau VPC :
- Une adresse IPv4 interne régionale dans une plage d'adresses IPv4 principale ou secondaire du sous-réseau, y compris les plages d'adresses IPv4 privées et les plages d'adresses IPv4 publiques utilisées en mode privé, utilisées par les ressources de ces destinations :
- Adresse IPv4 interne principale de la carte d'interface réseau d'une instance de réception.
- Une adresse IPv4 interne dans une plage d'adresses IP d'alias de la carte d'interface réseau d'une instance de réception.
- Une adresse IPv4 interne d'une règle de transfert interne pour le transfert de protocole ou pour un équilibreur de charge réseau passthrough interne.
- Plages d'adresses de sous-réseau IPv6 internes utilisées par ces ressources de destination :
- Une adresse IPv6 de la plage d'adresses IPv6
/96attribuée à une carte d'interface réseau de l'instance de réception. - Une adresse IPv6 de la plage d'adresses IPv6
/96d'une règle de transfert interne pour le transfert de protocole ou pour un équilibreur de charge réseau passthrough interne.
- Une adresse IPv6 de la plage d'adresses IPv6
- Plages d'adresses de sous-réseau IPv6 externes utilisées par ces ressources de destination lorsque les paquets sont acheminés à l'aide de routes de sous-réseau ou de routes de sous-réseau d'appairage au sein du réseau VPC :
- Une adresse IPv6 de la plage d'adresses IPv6
/96attribuée à une carte d'interface réseau de l'instance de réception. - Une adresse IPv6 de la plage d'adresses IPv6
/96d'une règle de transfert externe pour le transfert de protocole ou pour un équilibreur de charge réseau passthrough externe.
- Une adresse IPv6 de la plage d'adresses IPv6
Les chemins d'instance à instance ci-après sont traités de la même manière que dans la section Communication vers des destinations situées en dehors d'un réseau VPC :
- Si la destination des paquets est une adresse IPv4 externe d'une carte d'interface réseau d'une instance de réception.
- Si la destination des paquets est une adresse IPv4 externe d'un équilibreur de charge réseau passthrough externe.
- Si la destination des paquets est une adresse IPv4 externe d'une règle de transfert pour le transfert de protocole
- Si la destination des paquets est une adresse IPv6 externe de la carte d'interface réseau d'une instance, d'un équilibreur de charge réseau passthrough externe ou d'une règle de transfert pour le transfert de protocole externe, et si la route applicable dans le réseau VPC utilise un paramètre de saut suivant défini sur la passerelle Internet par défaut. Dans ce scénario, les instances de réception ne se trouvent pas sur le même réseau VPC que l'instance d'envoi, ni sur un réseau VPC connecté au réseau VPC de l'instance d'envoi à l'aide de l'appairage de réseaux VPC.
Communication vers des destinations situées en dehors d'un réseau VPC
Google Cloud traite les paquets envoyés à partir d'instances de calcul vers des destinations en dehors du réseau VPC de l'instance émettrice, comme indiqué dans le tableau suivant. Les destinations en dehors du réseau VPC d'une instance émettrice incluent les adresses IP routables publiquement pour les ressources en dehors deGoogle Cloud et les adresses IP externes utilisables par le client dans Google Cloud.Google Cloud
Étant donné qu'Internet utilise généralement une MTU de 1 500 octets, le fait de ne pas dépasser une taille de paquet IP de 1 500 octets permet généralement d'éviter une perte de paquets liée à la MTU.
| Situation | Comportement |
|---|---|
| Paquets TCP SYN et SYN-ACK | Google Cloud applique si nécessaire un processus de limitation de la taille MSS, en modifiant la MSS pour assurer que les paquets correspondent à la MTU. |
| MTU des paquets IP compris entre 1 300 octets et 1 600 octets (inclus) | Google Cloud n'apporte aucune modification au paquet, à l'exception des paquets SYN et SYN-ACK comme indiqué dans la première ligne. |
| Paquet IP de plus de 1 600 octets | Google Cloud supprime le paquet et envoie un message de fragmentation requise (ICMP sur IPv4) ou de paquet trop volumineux (ICMPv6) lorsque le bit de non-fragmentation (DF, Don't Fragment) est activé, et lorsque le bit DF est désactivé. |
Communication avec les API et les services Google
Les instances de calcul utilisant n'importe quelle taille de MTU de réseau VPC valide peuvent envoyer des paquets aux API et services Google, y compris l'accès privé à Google et Private Service Connect pour les API Google. Les détails de cette section s'appliquent également aux ressources sur site qui envoient des paquets aux API et services Google à l'aide de l'accès privé à Google pour les hôtes sur site.
Le chemin de trafic à destination des API et services Google qui est décrit dans cette section est mis en œuvre par les Google Front Ends (GFE). Ces GFE utilisent des MTU fixes non configurables. Le trafic de Google Cloud vers les API et services Google utilise toujours le protocole TCP. Si une instance de calcul se connecte aux API et services Google à partir d'un réseau VPC dont la MTU ne correspond pas à celle du GFE, la taille du segment est négociée à l'aide de l'annonce MSS TCP, comme décrit dans MTU non concordantes, blocage MSS, découverte de MTU du chemin d'accès.
| Source des paquets | Destination des paquets |
|---|---|
| Toute adresse IPv4 interne : adresse IPv4 interne principale ou adresse IPv4 interne issue d'une plage d'adresses IP d'alias de la carte d'interface réseau de l'instance Une adresse IPv4 externe attribuée à la carte d'interface réseau de l'instance à l'aide d'une configuration d'accès NAT 1:1 : dans cette situation, Google Cloud applique la règle NAT 1:1 sur la sortie, en convertissant une adresse IPv4 interne principale d'origine en une adresse IPv4 externe source spécifiée dans la configuration d'accès. | Adresses IPv4 des API et services Google pour les domaines par défaut 199.36.153.4/30 (limité.googleapis.com) 199.36.153.8/30 (private.googleapis.com) Point de terminaison Private Service Connect pour les API et services Google |
| Adresse IPv6 externe ou interne, pour les instances à double pile ou IPv6 uniquement | Adresses IPv6 des API et services Google pour les domaines par défaut 2600:2d00:0002:1000::/64 (limité.googleapis.com) 2600:2d00:0002:2000::/64 (private.googleapis.com) |
Communication via des tunnels Cloud VPN
Cloud VPN dispose à la fois d'une MTU de passerelle pour les paquets encapsulés et d'une MTU de charge utile pour les paquets avant et après l'encapsulation.
Pour obtenir les valeurs précises des MTU de charge utile et des informations sur les autres MTU Cloud VPN, consultez la section Considérations relatives aux MTU dans la documentation de Cloud VPN.
Communication via des rattachements (de VLAN) Cloud Interconnect
Nous vous recommandons d'utiliser la même MTU pour tous les rattachements de VLAN connectés au même réseau VPC et de définir la MTU du réseau VPC sur la même valeur. Pour plus d'informations sur les MTU des rattachements de VLAN Cloud Interconnect, consultez la page MTU Cloud Interconnect.
Communication via les points de terminaison de pare-feu
Si vous utilisez des points de terminaison de pare-feu, configurez une MTU appropriée pour votre réseau VPC. Si le paramètre MTU de votre réseau VPC dépasse la taille de paquet acceptée par votre point de terminaison de pare-feu, Cloud Next Generation Firewall ne peut pas effectuer correctement l'inspection de couche 7. Pour en savoir plus, consultez Taille de paquet acceptée.
Compatibilité avec les trames géantes
Les trames géantes ont une charge utile de plus de 1 460 octets. Le tableau suivant récapitule la compatibilité des trames géantes avec les produits et fonctionnalités Google Cloud :
| Produit ou fonctionnalité | Compatibilité avec les trames géantes |
|---|---|
| Compute Engine | Oui |
| Cloud Interconnect | Oui |
| Points de terminaison de pare-feu | Oui |
| Cloud VPN | Non |
| API Google | Non |
Instances de calcul et paramètres MTU
Il est recommandé de faire correspondre la MTU de la carte d'interface réseau d'une instance de calcul à la MTU du réseau VPC auquel elle est connectée. La configuration de l'unité de transmission maximale (MTU) de la carte d'interface réseau (NIC) varie en fonction du système d'exploitation et de la configuration :
- Instances Linux basées sur une image d'OS publique : la MTU de chaque carte d'interface réseau est automatiquement définie sur la MTU du réseau VPC correspondant à l'aide de l'option 26 du protocole DHCP.
- Instances Windows basées sur une image d'OS publique : par défaut, chaque MTU de carte d'interface réseau est configurée avec une MTU fixe de
1,460octets. Si vous modifiez la MTU d'un réseau VPC contenant des instances Windows basées sur des images d'OS publiques, vous devez modifier le paramètre de MTU des instances Windows. - Images d'OS invités personnalisées : vous devez configurer les MTU des cartes d'interface réseau ou vérifier que l'OS invité accepte la MTU du réseau VPC à l'aide de l'option 26 du protocole DHCP.
- Instances avec plusieurs interfaces réseau : définissez chaque MTU de carte d'interface réseau sur la MTU du réseau VPC correspondant.
Si une MTU de carte d'interface réseau doit être différente de celle du réseau VPC, définissez cette MTU de carte d'interface réseau sur une valeur inférieure à la MTU du réseau VPC. La réduction forcée de la MTU de carte d'interface réseau est avantageuse pour certains scénarios avancés de mise en réseau.
Modifier la MTU d'un réseau VPC
Pour éviter les problèmes de connectivité, avant de modifier la MTU du réseau VPC, vous devez d'abord arrêter chaque instance de calcul. Le redémarrage d'une instance à partir de son système d'exploitation invité ne met pas à jour sa MTU. Si vous choisissez de configurer des instances avec une MTU inférieure à celle du réseau, vous devez toujours arrêter l'instance avant de modifier la MTU.
Pour en savoir plus sur la modification de la MTU du réseau, consultez Modifier le paramètre de MTU d'un réseau VPC.
Paramètres GKE et MTU
La MTU sélectionnée pour une interface de pod dépend de l'interface CNI (Container Network Interface) utilisée par les nœuds du cluster et du paramètre de MTU sous-jacent du VPC. Pour en savoir plus, consultez la section Pods.
La valeur de la MTU de l'interface de pod est 1460 ou héritée de l'interface principale du nœud.
| CNI | MTU | GKE Standard |
|---|---|---|
| kubenet | 1460 | Par défaut |
| kubenet (version 1.26.1 de GKE et versions ultérieures) | Hérité | Par défaut |
| Calico | 1460 | Activation à l'aide de --enable-network-policy. Pour en savoir plus, consultez la page Contrôler la communication entre les pods et les services à l'aide de règles de réseau. |
| netd | Hérité | Activation à l'aide de l'une des options suivantes : Visibilité intranœud Fédération d'identité de charge de travail pour GKE Mise en réseau de la double pile IPv4/IPv6 |
| GKE Dataplane V2 | Hérité | Activation à l'aide de --enable-dataplane-v2. Pour en savoir plus, consultez la page Utiliser GKE Dataplane V2. |
MTU non concordantes, limitation de la taille MSS, détection de MTU de chemin
Cette section décrit comment les protocoles TCP et non TCP gèrent les MTU non concordantes.
Protocole TCP
Le protocole TCP gère automatiquement les incohérences de MTU. Le client et le serveur calculent individuellement leurs propres valeurs de taille maximale de segment (MSS) TCP effectives à chaque ouverture d'une connexion TCP. Le client et le serveur n'ont pas besoin de se mettre d'accord sur une valeur MSS effective identique.
- Taille maximale de segment (MSS) TCP effective du client : la plus grande quantité de données transmissibles dans un segment TCP envoyé d'un client à un serveur est le minimum des deux valeurs suivantes :
- Valeur du champ MSS du paquet SYN-ACK reçu par le client du serveur lors de l'établissement de la connexion TCP.
- MTU de l'interface réseau du client, moins 40 octets. Les 40 octets soustraits incluent 20 octets pour l'en-tête IP et 20 octets pour l'en-tête TCP de base.
- Taille maximale de segment (MSS) TCP effective du serveur : la plus grande quantité de données transmissibles dans un segment TCP envoyé d'un serveur à un client est le minimum des deux valeurs suivantes :
- Valeur du champ MSS du paquet SYN reçu par le serveur du client lors de l'établissement de la connexion TCP.
- MTU de l'interface réseau du serveur, moins 40 octets. Les 40 octets soustraits incluent 20 octets pour l'en-tête IP et 20 octets pour l'en-tête TCP de base.
Limitation de la taille maximale de segment TCP
Le processus de limitation de la taille MSS TCP est un processus permettant à un appareil réseau entre un client et un serveur de modifier les valeurs MSS des paquets SYN et SYN-ACK lors de l'acheminement des paquets entre le client et le serveur. Google Cloud utilise la limitation de la taille MSS chaque fois qu'il envoie des paquets à des destinations en dehors d'un réseau VPC.
Les tunnels Cloud VPN et les rattachements de VLAN Cloud Interconnect utilisent également le processus de limitation de la taille MSS. Pour plus d'informations, consultez la section Encapsulation et traitement des paquets dans la documentation Cloud VPN et MTU Cloud Interconnect.
Les réseaux VPC n'effectuent pas de processus de limitation de la taille MSS pour les paquets acheminés par les sauts suivants au sein d'un réseau VPC, car le protocole TCP lui-même est suffisant.
Protocoles non TCP
D'autres protocoles, tels que UDP, nécessitent une attention particulière en présence de deux MTU de réseau VPC distinctes. Il incombe à un système d'envoi d'émettre des paquets correspondant à la MTU de son interface réseau, à la MTU de l'interface réseau du système récepteur et à la MTU de tous les réseaux intermédiaires. Google Cloud n'effectue pas de fragmentation des adresses IP pour les paquets acheminés par les sauts suivants dans un réseau VPC.
Lorsqu'un paquet IP est trop volumineux pour être distribué, par exemple lorsqu'il dépasse la MTU du réseau VPC où se trouve la carte d'interface réseau de l'instance de calcul de réception, Google Cloud supprime le paquet. Si le bit DF est défini dans le paquet, Google Cloud renvoie également à l'expéditeur un message indiquant qu'une fragmentation est requise (ICMP sur IPv4) ou que le paquet est trop volumineux (ICMPv6).
Google Cloud envoie un message de fragmentation requise ou de paquet trop volumineux dans les situations suivantes, même lorsque le bit DF est désactivé :
- Si la MTU du réseau VPC est inférieure à 1 600 octets et que le paquet envoyé est supérieur à la MTU du réseau VPC.
- Si la MTU du réseau VPC est supérieure ou égale à 1 600 octets et que le paquet envoyé est supérieur à 1 600 octets.
Les messages de fragmentation ICMP requise ou de paquet trop volumineux sont nécessaires pour qu'une instance de calcul qui envoie des paquets puisse utiliser la détection de MTU de chemin (PMTUD, Path MTU Discovery). Pour illustrer le fonctionnement de la PMTUD, considérons l'exemple suivant avec deux instances de calcul situées dans des réseaux VPC distincts, connectés à l'aide de l'appairage de réseaux VPC :
- L'instance émettrice possède une carte d'interface réseau dans un réseau VPC dont la MTU est de 8 896 octets.
- L'instance de réception a une carte d'interface réseau dans un réseau VPC dont la MTU est de 1 460 octets.
- L'instance émettrice émet un paquet IP de 8 000 octets dont le bit de non-fragmentation (
DF) est défini. Comme le paquet est trop volumineux pour être transmis à l'instance de réception, Google Cloud envoie à l'instance émettrice un message de fragmentation requise ou de paquet trop volumineux. Ce message indique la plus grande taille de paquet IP que l'émetteur peut utiliser lorsqu'il va tenter de retransmettre des paquets pour la connexion. - Le système d'exploitation de l'instance émettrice utilise ces informations pour réduire la taille des paquets IP lors de l'envoi de paquets ultérieurs à l'instance de réception.
La PMTUD est soumise aux exigences supplémentaires suivantes, car les paquets générés par la PMTUD et signalés comme requérant ou une fragmentation ou étant trop volumineux utilisent le protocole ICMP, et ont des sources correspondant à la destination d'un paquet d'origine :
- Vous devez configurer des règles d'autorisation d'entrée, consistant soit en des règles de pare-feu VPC, soit en des règles dans les stratégies de pare-feu, de sorte que les protocoles ICMP (pour IPv4) ou ICMPv6 (pour IPv6) soient autorisés à partir de sources correspondant aux destinations des paquets d'origine. Pour simplifier la configuration de pare-feu, envisagez d'autoriser ICMP et ICMPv6 depuis toutes les sources.
- Les règles de transfert pour l'équilibreur de charge réseau passthrough interne et le transfert de protocole interne doivent utiliser le protocole
L3_DEFAULTafin qu'elles traitent à la fois le protocole ICMP pour la PMTUD et le protocole utilisé par le paquet d'origine.
Étapes suivantes
- Pour voir le fonctionnement d'une autre MTU, consultez la section Créer et vérifier un réseau avec une MTU de trame géante.
- Créez un réseau VPC avec une MTU spécifiée.
- Modifiez le paramètre de MTU d'un réseau VPC.
Faites l'essai
Si vous débutez sur Google Cloud, créez un compte pour évaluer les performances de VPC en conditions réelles. Les nouveaux clients bénéficient également de 300 $ de crédits sans frais pour exécuter, tester et déployer des charges de travail.