Unità massima di trasmissione
L'unità massima di trasmissione (MTU) è la dimensione, in byte, del pacchetto IP più grande possibile, Intestazioni IP, intestazioni di protocollo di livello 4 e dati di livello 4, che possono essere inseriti in un frame Ethernet.
Dimensioni MTU valide della rete VPC
Le reti Virtual Private Cloud (VPC) utilizzano una MTU predefinita di 1460 byte. Puoi impostare l'MTU di una rete VPC su qualsiasi valore compreso tra 1300 byte e 8896 byte (inclusi). Le dimensioni MTU personalizzate più comuni sono 1500 byte ( Ethernet) o 8896 byte (il massimo possibile). Ti consigliamo di configurare la MTU per ciascuna interfaccia di rete (NIC) dell'istanza di macchina virtuale (VM) in modo che alla MTU della rete VPC a cui è connesso. Per ulteriori informazioni, consulta VM e impostazioni MTU.
Comunicazione tra VM Google Cloud all'interno di reti VPC
Quando le VM di invio e ricezione utilizzano la stessa rete VPC o reti VPC con peering con MTU identici, è possibile inviare pacchetti IP fino alla dimensione MTU tra le due VM, se le interfacce di entrambe le VM sono configurate per utilizzare il MTU della rete VPC.
Per evitare problemi di mancata corrispondenza dell'MTU, ti consigliamo di utilizzare lo stesso MTU per tutte le reti VPC collegate. Sebbene questa sia la non sei obbligato ad avere MTU identiche tra i reti VPC. Per informazioni dettagliate su come i protocolli gestiscono le situazioni in cui è presente una mancata corrispondenza dell'MTU tra le reti VPC, consulta MTU non corrispondenti, limitazione MSS, rilevamento MTU del percorso.
Dal punto di vista di una VM mittente, i percorsi alle seguenti destinazioni rappresentano il traffico da VM a VM indirizzato all'interno di una rete VPC:
- Un indirizzo IPv4 interno regionale in un intervallo di indirizzi IPv4 della subnet principale o della subnet secondaria, inclusi gli intervalli di indirizzi IPv4 privati e gli intervalli di indirizzi IPv4 pubblici utilizzati privatamente, utilizzati da queste risorse di destinazione:
- L'indirizzo IPv4 interno principale dell'interfaccia di rete di una VM ricevente (NIC).
- Un indirizzo IPv4 interno in un intervallo IP alias della NIC di una VM di destinazione.
- Un indirizzo IPv4 interno di una regola di forwarding interno per entrambi i protocolli o per un bilanciatore del carico di rete passthrough interno.
- Intervalli di indirizzi di subnet IPv6 interni utilizzati da queste risorse di destinazione:
- Un indirizzo IPv6 dall'intervallo di indirizzi IPv6
/96
assegnato alla NIC di una VM a doppio stack di destinazione. - Un indirizzo IPv6 dell'intervallo di indirizzi IPv6
/96
di una regola di inoltro interna per il forwarding del protocollo o per un bilanciatore del carico di rete passthrough interno.
- Un indirizzo IPv6 dall'intervallo di indirizzi IPv6
- Intervalli di indirizzi di subnet IPv6 esterni utilizzati da queste risorse di destinazione quando i pacchetti vengono instradati utilizzando route di subnet o route di subnet di peering all'interno della rete VPC:
- Un indirizzo IPv6 dall'intervallo di indirizzi IPv6
/96
assegnato a uno stack doppio che riceve il NIC della VM. - Un indirizzo IPv6 dall'intervallo di indirizzi IPv6
/96
di un inoltro esterno per il forwarding del protocollo o per un bilanciatore del carico di rete passthrough esterno.
- Un indirizzo IPv6 dall'intervallo di indirizzi IPv6
I seguenti percorsi VM-to-VM vengono trattati nello stesso modo delle comunicazioni con destinazioni esterne a una rete VPC:
- Se la destinazione del pacchetto è un indirizzo IPv4 esterno di un NIC della VM Google Cloud.
- Se la destinazione del pacchetto è un indirizzo IPv4 esterno di un bilanciatore del carico di rete passthrough esterno.
- Se la destinazione del pacchetto è un indirizzo IPv4 esterno di una regola di forwarding per il forwarding del protocollo
- Se la destinazione del pacchetto è un indirizzo IPv6 esterno della NIC di una VM Google Cloud, di un bilanciatore del carico di rete passthrough esterno o di una regola di inoltro per l'inoltro del protocollo esterno e la route applicabile nella rete VPC utilizza un prossimo hop del gateway internet predefinito. In questo scenario, le VM di destinazione non si trovano nella stessa rete VPC della VM di invio né in una rete VPC collegata alla rete VPC della VM di invio tramite il peering di rete VPC.
Comunicazione con destinazioni esterne a una rete VPC
Google Cloud elabora i pacchetti inviati alle destinazioni al di fuori dell'area di invio Rete VPC della VM come mostrato nella tabella seguente. Le destinazioni al di fuori della rete VPC di una VM di invio includono gli indirizzi IP instradabili pubblicamente per le risorse esterne a Google Cloud indirizzi IP esterni utilizzabili dal cliente all'interno in Google Cloud.
Poiché in genere internet utilizza un MTU di 1500 byte, mantenere le dimensioni dei pacchetti IP inferiori o uguali a 1500 byte di solito evita la perdita di pacchetti correlata all'MTU.
Situazione | Comportamento |
---|---|
Pacchetti SYN e SYN-ACK TCP | Se necessario, Google Cloud esegue il capping MSS, modificando il valore MSS per assicurarsi che i pacchetti rientrino nell'MTU. |
MTU del pacchetto IP compreso tra 1300 e 1600 byte (inclusi) | Google Cloud non apporta modifiche al pacchetto, ad eccezione dei pacchetti SYN e SYN-ACK come discusso nella prima riga. |
Pacchetto IP più grande di 1600 byte | Google Cloud elimina il pacchetto e invia un messaggio di frammentazione necessaria (ICMP su IPv4) o di pacchetto troppo grande (ICMPv6) sia quando il bit DF è attivo sia quando è disattivato. |
Comunicazione con le API e i servizi Google
Le VM che utilizzano qualsiasi dimensione MTU della rete VPC valida possono inviare pacchetti le API e i servizi Google, incluso l'uso Accesso privato Google e Private Service Connect per Google di terze parti. I dettagli riportati in questa sezione si applicano anche alle risorse on-premise che inviano pacchetti alle API e ai servizi Google utilizzando l'accesso privato Google per gli host on-premise.
Il percorso del traffico verso le API e i servizi Google descritto in questa sezione è implementati dai Google Front End (GFE). Questi GFE utilizzano componenti non configurabili, MTU. Il traffico da Google Cloud alle API e ai servizi Google utilizza sempre il protocollo TCP: se una VM si connette alle API e ai servizi Google da una rete VPC il cui MTU non corrisponde a quello del GFE, la dimensione del segmento viene negoziata utilizzando l'annuncio MSS TCP come descritto in MTU non corrispondenti, limitazione MSS, rilevamento MTU del percorso.
Sorgente pacchetti | Destinazione pacchetto |
---|---|
Qualsiasi indirizzo IPv4 interno: indirizzo IPv4 interno principale o indirizzo IPv4 interno da un intervallo IP alias della NIC della VM Un indirizzo IPv4 esterno assegnato alla NIC della VM utilizzando una configurazione di accesso NAT 1:1: in questa situazione, Google Cloud esegue il NAT 1:1 in uscita, convertendo un indirizzo IPv4 interno principale di origine originale in un indirizzo IPv4 esterno di origine specificato nella configurazione di accesso. |
|
Indirizzo IPv6 esterno o interno, per VM a doppio stack |
|
Comunicazione tramite i tunnel Cloud VPN
Cloud VPN ha sia una MTU gateway per i pacchetti incapsulati, payload MTU per i pacchetti prima e dopo l'incapsulamento.
Per valori MTU del payload precisi e altre informazioni sulla MTU di Cloud VPN, consulta Considerazioni sulla MTU nella documentazione di Cloud VPN.
Comunicazione tramite collegamenti di Cloud Interconnect (VLAN)
Ti consigliamo di utilizzare lo stesso MTU per tutti i collegamenti VLAN connessi alla stessa rete VPC e di impostare lo stesso valore per l'MTU della rete VPC. Per maggiori dettagli su MTU per il collegamento VLAN di Cloud Interconnect, consulta Cloud Interconnect MTU.
Supporto dei frame jumbo
La tabella seguente riassume il supporto di jumbo frame tra Google Cloud prodotti e funzionalità:
Prodotto o funzionalità | Supporto per Jumbo frame |
---|---|
Compute Engine | Sì |
Cloud Interconnect | Sì |
Cloud VPN | No |
API di Google | No |
Impostazioni di VM e MTU
Come best practice, associa l'MTU della NIC di una VM all'MTU della rete VPC a cui è collegata la NIC:
Ogni MTU del NIC per una VM Linux basata su un'immagine del sistema operativo pubblica viene impostato automaticamente sul rispettivo MTU della rete VPC utilizzando l'opzione 26 DHCP.
Ogni MTU della NIC per una VM Windows basata su un'immagine del sistema operativo pubblico è configurato con un MTU fisso di
1,460
byte. Se modifichi la MTU di una rete VPC che contiene VM Windows basate su immagini del sistema operativo pubbliche, devi modificare la MTU per la VM Windows.Se utilizzi immagini del sistema operativo guest personalizzate, devi configurare le MTU della NIC o verificare che il sistema operativo guest accetti la MTU della rete VPC utilizzando l'opzione DHCP 26.
Se una VM ha più interfacce di rete, imposta l'MTU di ogni NIC sul valore MTU della rete VPC corrispondente.
Se un MTU NIC deve essere diverso dall'MTU della rete VPC, impostalo su un valore inferiore a quello della rete VPC. Forzata la riduzione della MTU del NIC è vantaggiosa per alcune funzionalità di networking avanzate diversi scenari.
Modifica della MTU di una rete VPC
Se modifichi la MTU di una rete VPC con VM in esecuzione, mantieni le seguenti considerazioni:
Se riduci il valore MTU della rete VPC, devi arrestare e avviare ogni VM. Il riavvio di una VM dal sistema operativo guest non ne aggiorna la MTU.
Se aumenti l'MTU della rete VPC, le VM in esecuzione che utilizzano la rete VPC non ne trarranno vantaggio finché non saranno state interrotte e riavviate. Fino a quando ogni VM non viene arrestata e riavviata, continua a utilizzare valore MTU precedente (inferiore).
Per istruzioni, consulta Modifica dell'impostazione della MTU di un VPC Google Cloud.
Impostazioni di GKE e MTU
L'MTU selezionato per un'interfaccia del pod dipende dall'interfaccia di rete del contenitore (CNI) utilizzata dai nodi del cluster e dall'impostazione MTU VPC sottostante. Per ulteriori informazioni, consulta la pagina Pod.
Il valore MTU dell'interfaccia del pod è 1460
o ereditato dall'istanza principale
all'interfaccia del Nodo.
CNI | MTU | GKE Standard |
---|---|---|
Kubernetes | 1460 | Predefinito |
kubenet (GKE versione 1.26.1 e successive) |
Ereditato | Predefinito |
Calico | 1460 |
Abilitato utilizzando Per maggiori dettagli, vedi Controllare la comunicazione tra pod e servizi tramite criteri di rete. |
netd | Ereditato | Attivata utilizzando una delle seguenti opzioni: |
GKE Dataplane V2 | Ereditato |
Attivazione tramite Per maggiori dettagli, consulta Utilizzo di GKE Dataplane V2. |
MTU non corrispondenti, limitazione MSS, rilevamento MTU del percorso
Questa sezione descrive in che modo i protocolli TCP e non TCP gestiscono le MTU non corrispondenti.protocollo TCP
Il protocollo TCP gestisce automaticamente le corrispondenze errate delle MTU. Sia il client sia il server calcolano singolarmente i propri valori di dimensione massima del segmento TCP (MSS) effettivi ogni volta che viene aperta una connessione TCP. Il client e il server non devono necessariamente essere d'accordo su un valore MSS effettivo identico.
Dimensione massima del segmento (MSS) TCP effettiva del client: la quantità maggiore di dati trasmissibili in un segmento TCP inviato da un client a un server è la minimum dei due seguenti valori:
Il valore del campo MSS nel pacchetto SYN-ACK ricevuto dal client dal server durante l'instaurazione della connessione TCP.
La MTU dell'interfaccia di rete del client, meno 40 byte. I 40 byte sottratti includono 20 byte per l'intestazione IP e 20 byte per l'intestazione TCP di base.
Dimensione massima del segmento (MSS) TCP effettiva del server: la dimensione di dati trasmissibili in un segmento TCP inviato da un server a un client è il minimo dei due valori seguenti:
Il valore del campo MSS nel pacchetto SYN ricevuto dal server da al client durante la creazione della connessione TCP.
L'MTU dell'interfaccia di rete del server, meno 40 byte. I 40 byte sottratti includono 20 byte per l'intestazione IP e 20 byte per l'intestazione TCP di base.
Limitazione MSS TCP
Il capping MSS TCP è un processo in cui un dispositivo di rete tra un client e un server cambia i valori MSS nei pacchetti SYN e SYN-ACK durante l'instradamento dei pacchetti tra il client e il server. Google Cloud utilizza il clamping MSS ogni volta che invia pacchetti a destinazioni esterne a un VPC Google Cloud.
Anche i tunnel Cloud VPN e i collegamenti VLAN di Cloud Interconnect con il blocco MSS. Per ulteriori informazioni, consulta la sezione Incapsulamento dei pacchetti elaborazione nella documentazione di Cloud VPN e Cloud Interconnect MTU.
Le reti VPC non eseguono il blocco MSS per i pacchetti instradati dal gli hop successivi all'interno di una rete VPC perché sufficienti.
Protocolli non TCP
Altri protocolli, come UDP, richiedono una particolare attenzione quando due diversi Sono coinvolte le MTU della rete VPC. È responsabilità del il sistema di invio per emettere i pacchetti che rientrano nella sua interfaccia di rete MTU, MTU dell'interfaccia di rete del sistema ricevente e la MTU di tutte le reti in tra di loro. Google Cloud non esegue la frammentazione IP per i pacchetti instradato dagli hop successivi all'interno di una rete VPC.
Quando un pacchetto IP è troppo grande per essere consegnato, ad esempio quando
di un pacchetto supera la MTU della rete VPC in cui
Il NIC della VM è stato individuato: Google Cloud elimina il pacchetto. Se il pacchetto
è impostato su DF
bit, Google Cloud invia anche una Fragmentation Requested (ICMP)
su IPv4) o un messaggio Packet Too Big (ICMPv6) al mittente.
Google Cloud invia una frammentazione necessaria o un pacchetto troppo grande
nelle seguenti circostanze, anche quando un bit di DF
è disattivato:
- Se l'MTU della rete VPC è inferiore a 1600 byte e il pacchetto inviato supera l'MTU della rete VPC.
- Se l'MTU della rete VPC è pari o superiore a 1600 byte e il pacchetto inviato supera i 1600 byte.
I messaggi ICMP Fragmentazione richiesta o Pacchetto troppo grande sono necessari per un VM che invia pacchetti per utilizzare il rilevamento della MTU del percorso (PMTUD). Per illustrare il funzionamento di PMTUD, prendi in considerazione il seguente esempio con due VM in reti VPC diverse connesse tramite peering di rete VPC:
- La VM di invio ha un NIC in una rete VPC la cui MTU è 8896 byte.
- La VM di destinazione ha una NIC in una rete VPC il cui MTU è di 1460 byte.
- La VM mittente emette un pacchetto IP di 8000 byte il cui bit Non frammenta (
DF
) è impostato. Poiché il pacchetto è troppo grande per essere consegnato alla VM di destinazione, Google Cloud invia un messaggio di frammentazione richiesta o pacchetto troppo grande alla VM di invio. Questo messaggio indica il pacchetto IP più grande possibile dimensioni che il mittente può utilizzare quando tenta di ritrasmettere i pacchetti per connessione. - Il sistema operativo della VM di invio utilizza queste informazioni per ridurre le dimensioni del pacchetto IP quando invia pacchetti successivi alla VM di ricezione.
PMTUD ha i seguenti requisiti aggiuntivi perché generato dal PMTUD Frammentazione necessaria o pacchetto troppo grande utilizzano il protocollo ICMP e hanno origini che corrispondono alla destinazione di un pacchetto originale:
- Devi configurare regole firewall VPC o regole nei criteri firewall di autorizzazione in entrata in modo che ICMP (per IPv4) o ICMPv6 (per IPv6) siano consentiti da origini corrispondenti alle destinazioni dei pacchetti originali. Per semplificare la configurazione del firewall, ti consigliamo di consentire ICMP e ICMPv6 da tutte le origini.
- Le regole di inoltro per il bilanciatore del carico di rete passthrough interno e per l'inoltro del protocollo interno devono utilizzare il protocollo
L3_DEFAULT
in modo da elaborare sia ICMP per PMTUD sia il protocollo utilizzato dal pacchetto originale.
Passaggi successivi
- Per verificare il funzionamento di una MTU diversa, consulta l'articolo Creare e verificare un MTU jumbo frame Google Cloud.
- Crea una rete VPC con un valore MTU specificato.
- Modificare l'impostazione MTU di una rete VPC.
Provalo
Se non conosci Google Cloud, crea un account per valutare le prestazioni di VPC in scenari reali. I nuovi clienti ricevono anche 300 $ di crediti gratuiti per l'esecuzione, il test e il deployment dei carichi di lavoro.
Prova VPC gratuitamente