Unité de transmission maximale
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). Google vous recommande de configurer la MTU de chaque interface réseau d'instance de machine virtuelle (VM) de sorte qu'elle corresponde à la MTU du réseau VPC auquel elle est connectée. Pour en savoir plus, consultez la section Paramètres des VM et MTU.
Communication entre VM Google Cloud au sein de réseaux VPC
Lorsque la VM émettrice et la VM de réception utilisent le même réseau VPC ou des réseaux VPC appairés ayant des MTU identiques, des paquets IP dont la taille peut atteindre la MTU peuvent être envoyés entre les deux VM, si les interfaces de ces deux VM 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 prévoir des MTU identiques entre 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 VM émettrice, les chemins d'accès aux destinations suivantes représentent le trafic entre plusieurs VM 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 :
- L'adresse IPv4 interne principale de la carte d'interface réseau d'une VM de réception.
- Une adresse IPv4 interne dans une plage d'adresses IP d'alias de la carte d'interface réseau d'une VM 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 la VM de réception à deux piles. - 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 les ressources de ces destinations lorsque les paquets sont acheminés à l'aide de routes de sous-réseau ou de routes d'appairage de sous-réseau au sein du réseau VPC :
- Une adresse IPv6 de la plage d'adresses IPv6
/96attribuée à une carte d'interface réseau de la VM de réception à deux piles. - 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 de VM à VM 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 de VM Google Cloud 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 VM Google Cloud, de l'é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 VM de réception ne se trouvent pas sur le même réseau VPC que la VM émettrice, ni sur un réseau VPC connecté au réseau VPC de la VM émettrice à l'aide de l'appairage de réseaux VPC.
Communication vers des destinations situées en dehors d'un réseau VPC
La façon dont Google Cloud traite les paquets envoyés vers des destinations extérieures au réseau VPC de la VM émettrice est indiquée dans le tableau suivant. Les destinations situées en dehors du réseau VPC d'une VM émettrice incluent des adresses IP routables publiquement pour les ressources en dehors de Google Cloud, ainsi que des adresses IP externes utilisables par le client dans 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 VM 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 VM se connecte aux API et services Google à partir d'un réseau VPC dont la MTU ne correspond pas à la MTU du GFE, la taille du segment est négociée à l'aide de l'annonce MSS TCP, comme décrit dans la section MTU non concordantes, limitation de la taille MSS, détection de MTU de chemin.
| 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 la VM Une adresse IPv4 externe attribuée à la carte d'interface réseau de la VM à 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 spécifiée dans la configuration d'accès. |
|
| Adresse IPv6 externe ou interne, pour les VM double pile |
|
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
Google recommande 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.
Compatibilité avec les trames géantes
Le tableau suivant récapitule la compatibilité de trame géante entre les produits et fonctionnalités Google Cloud :
| Produit ou fonctionnalité | Compatibilité avec les trames géantes |
|---|---|
| Compute Engine | Oui |
| Cloud Interconnect | Oui |
| Cloud VPN | Non |
| Services compatibles avec les API Google | Non |
Paramètres des VM et MTU
Il est recommandé de faire correspondre la MTU de la carte d'interface réseau d'une VM à la MTU du réseau VPC auquel elle est connectée :
Chaque MTU de carte d'interface réseau d'une VM Linux basée sur une image d'OS publique est automatiquement définie sur la MTU du réseau VPC correspondant à l'aide de l'option 26 du protocole DHCP.
Chaque MTU de carte d'interface réseau d'une VM Windows basée sur une image d'OS publique est configurée avec une MTU fixe de
1,460octets. Si vous modifiez la MTU d'un réseau VPC contenant des VM Windows basées sur des images d'OS publiques, vous devez modifier la MTU de la VM Windows.Si vous utilisez des 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.
Si une VM comporte 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
Tenez compte des points suivants si vous modifiez la MTU d'un réseau VPC avec des VM en cours d'exécution :
Si vous réduisez la MTU du réseau VPC, vous devez arrêter et relancer chaque VM. Le redémarrage d'une VM à partir de son système d'exploitation invité ne met pas à jour sa MTU.
Si vous augmentez la MTU du réseau VPC, l'exécution de VM exploitant ce réseau VPC ne profitera pas de l'augmentation de la MTU du réseau VPC tant que les VM n'auront pas été arrêtées et relancées. Elles continueront pendant ce temps à utiliser la valeur de MTU précédente (inférieure).
Pour obtenir des instructions, consultez la page 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 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 : |
| GKE Dataplane V2 | Hérité |
Activation à l'aide de 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 le processus de 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 la VM 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).
Les situations dans lesquelles Google Cloud envoie un tel message de fragmentation requise ou de paquet trop volumineux sont les 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 VM 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 VM situées dans des réseaux VPC distincts, connectés à l'aide de l'appairage de réseaux VPC :
- La VM émettrice a une carte d'interface réseau dans un réseau VPC dont la MTU est de 8 896 octets.
- La VM de réception a une carte d'interface réseau dans un réseau VPC dont la MTU est de 1 460 octets.
- La VM é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 à la VM de réception, Google Cloud envoie à la VM é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 la VM émettrice utilise ces informations pour réduire la taille des paquets IP lors de l'envoi de paquets ultérieurs à la VM 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 gratuits pour exécuter, tester et déployer des charges de travail.
Profiter d'un essai gratuit de VPC