Unità massima di trasmissione
L'unità di trasmissione massima (MTU) è la dimensione, in byte, del pacchetto IP più grande possibile, comprese le intestazioni IP, le intestazioni del protocollo di livello 4 e i dati di livello 4, che possono essere inseriti all'interno di un frame Ethernet.
Dimensioni MTU valide per la rete VPC
Le reti Virtual Private Cloud (VPC) utilizzano una MTU predefinita di 1460 byte. Puoi impostare la MTU di una rete VPC su qualsiasi valore compreso tra 1300 byte e 8896 byte (inclusi). Le dimensioni comuni delle MTU personalizzate sono 1500 byte (Ethernet standard) o 8896 byte (il massimo possibile). Google consiglia di configurare la MTU per ogni interfaccia di rete (NIC) di istanze di macchine virtuali (VM) in modo che corrisponda alla MTU della rete VPC a cui è connessa. Per saperne di più, consulta Impostazioni relative a VM e MTU.
Comunicazione tra le VM Google Cloud all'interno di reti VPC
Quando l'invio e la ricezione delle VM utilizzano la stessa rete VPC o le stesse reti VPC in peering che hanno MTU identiche, i pacchetti IP fino alla dimensione MTU possono essere inviati tra le due VM, se le interfacce di entrambe le VM sono configurate per utilizzare la MTU della rete VPC.
Per evitare problemi di MTU non corrispondenti, Google consiglia di utilizzare la stessa MTU per tutte le reti VPC connesse. Sebbene questa sia la pratica consigliata, non devi avere MTU identiche tra le reti VPC connesse. Per informazioni dettagliate su come i protocolli gestiscono le situazioni in cui esiste una mancata corrispondenza delle MTU tra le reti VPC, consulta la pagina MTU non corrispondenti, blocco MSS, rilevamento del percorso di MTU.
Dal punto di vista di una VM di invio, i percorsi alle seguenti destinazioni rappresentano il traffico da VM a VM instradato all'interno di una rete VPC:
- Un indirizzo IPv4 interno a livello di regione in un intervallo di indirizzi IPv4 principali della subnet o della subnet, inclusi intervalli di indirizzi IPv4 privati e intervalli di indirizzi IPv4 pubblici utilizzati privatamente, utilizzati da queste risorse di destinazione:
- L'indirizzo IPv4 interno principale dell'interfaccia di rete (NIC) di una VM ricevente.
- Un indirizzo IPv4 interno in un intervallo IP alias del NIC della VM ricevente.
- Un indirizzo IPv4 interno di una regola di forwarding interno per l'inoltro di protocollo 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
/96assegnato al NIC della VM a doppio stack. - Un indirizzo IPv6 dall'intervallo di indirizzi IPv6
/96di una regola di forwarding interno per l'inoltro 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
/96assegnato al NIC della VM a doppio stack. - Un indirizzo IPv6 dell'intervallo di indirizzi IPv6
/96di una regola di forwarding 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 da VM a VM vengono trattati allo stesso modo della comunicazione con destinazioni al di fuori di una rete VPC:
- Se la destinazione del pacchetto è un indirizzo IPv4 esterno del NIC della VM Google Cloud di destinazione.
- 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 l'inoltro del protocollo
- Se la destinazione del pacchetto è un indirizzo IPv6 esterno del NIC di una VM Google Cloud, un bilanciatore del carico di rete passthrough esterno o una regola di forwarding per l'inoltro del protocollo esterno, e la route applicabile nella rete VPC utilizza un hop successivo del gateway internet predefinito. In questo scenario, le VM riceventi non si trovano né nella stessa rete VPC della VM di invio, né in una rete VPC connessa alla rete VPC della VM di invio tramite peering di rete VPC.
Comunicazione con destinazioni al di fuori di una rete VPC
Google Cloud elabora i pacchetti inviati a destinazioni al di fuori della rete VPC della VM di invio, come mostrato nella seguente tabella. Le destinazioni al di fuori della rete VPC di una VM di invio includono indirizzi IP instradabili pubblicamente per risorse esterne a Google Cloud e indirizzi IP esterni utilizzabili dal cliente all'interno di Google Cloud.
Poiché internet in genere utilizza una MTU di 1500 byte, mantenere le dimensioni dei pacchetti IP a 1500 byte o meno spesso evita la perdita di pacchetti correlata all'MTU.
| Situazione | Comportamento |
|---|---|
| Pacchetti TCP SYN e SYN-ACK | Google Cloud esegue il blocco MSS, se necessario, modificando il servizio MSS per garantire che i pacchetti rientrino nell'MTU. |
| MTU del pacchetto IP tra 1300 e 1600 byte (inclusi) | Google Cloud non apporta modifiche al pacchetto, ad eccezione dei pacchetti SYN e SYN-ACK, come descritto nella prima riga. |
| Pacchetto IP di dimensioni superiori a 1600 byte | Google Cloud ignora il pacchetto e invia un messaggio relativo alla Fragmentazione ICMP richiesta sia quando il bit DF è attivo e anche quando il bit DF è disattivato. |
Comunicazione con i servizi e le API di Google
Le VM che utilizzano qualsiasi dimensione MTU della rete VPC valida possono inviare pacchetti alle API e ai servizi Google, incluso l'utilizzo dell'accesso privato Google e di Private Service Connect per le API di Google. I dettagli 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 descritti in questa sezione è implementato dai Google Front End (GFE). Questi GFE utilizzano MTU fisse non configurabili. 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 la cui MTU non corrisponde alla MTU del GFE, le dimensioni del segmento vengono negoziate utilizzando l'annuncio MSS TCP come descritto in MTU non corrispondenti, blocco MSS, rilevamento del percorso di MTU.
| Origine pacchetto | Destinazione pacchetto |
|---|---|
Qualsiasi indirizzo IPv4 interno: indirizzo IPv4 interno principale o indirizzo IPv4 interno da un intervallo IP alias del NIC della VM Un indirizzo IPv4 esterno assegnato al NIC della VM utilizzando una configurazione dell'accesso NAT 1-1. In questa situazione, Google Cloud esegue un NAT 1-1 sul traffico in uscita, convertendo un indirizzo IPv4 interno principale di origine originale in un indirizzo IPv4 esterno di origine specificato nella configurazione dell'accesso. |
|
| Indirizzo IPv6 esterno o interno, per VM a doppio stack |
|
Comunicazione tramite tunnel Cloud VPN
Cloud VPN dispone sia di una MTU di gateway per i pacchetti incapsulati sia di una MTU di payload per i pacchetti prima e dopo l'incapsulamento.
Per valori precisi della MTU del payload e altre informazioni sulle MTU di Cloud VPN, consulta le considerazioni sulle MTU nella documentazione di Cloud VPN.
Comunicazione tramite collegamenti di Cloud Interconnect (VLAN)
Google consiglia di utilizzare lo stesso MTU per tutti i collegamenti VLAN collegati alla stessa rete VPC e di impostare l'MTU della rete VPC sullo stesso valore. Per maggiori dettagli sulle MTU collegamento VLAN di Cloud Interconnect, consulta MTU di Cloud Interconnect.
Supporto di Jumbo frame
La seguente tabella riassume il supporto dei frame jumbo tra i prodotti e le funzionalità Google Cloud:
| Prodotto o funzionalità | Supporto di Jumbo frame |
|---|---|
| Compute Engine | Sì |
| Cloud Interconnect | Sì |
| Cloud VPN | No |
| API di Google servizi supportati | No |
Impostazioni VM e MTU
Come best practice, associa la MTU NIC di una VM all'MTU della rete VPC a cui è connesso il NIC:
Ogni MTU NIC per una VM Linux basata su un'immagine del sistema operativo fornita da Google viene impostata automaticamente sulla rispettiva MTU della rete VPC utilizzando l'opzione DHCP 26.
Ogni MTU NIC per una VM Windows basata su un'immagine del sistema operativo fornita da Google è configurata con una MTU fissa di
1,460byte. Se modifichi l'MTU di una rete VPC che contiene VM Windows basate su immagini sistema operativo fornite da Google, devi modificare l'MTU della VM Windows.Se utilizzi immagini di sistema operativo guest personalizzate, devi configurare le MTU 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 ogni MTU NIC sulla rispettiva MTU della rete VPC.
Se una MTU NIC deve essere diversa dalla MTU della rete VPC, imposta la MTU NIC su un valore inferiore alla MTU della rete VPC. La riduzione forzata della MTU NIC è vantaggiosa per alcuni scenari di networking avanzati.
Modifica della MTU di una rete VPC
Se modifichi la MTU di una rete VPC con VM in esecuzione, tieni presente quanto segue:
Se riduci la MTU della rete VPC, devi arrestare e avviare ogni VM. Il riavvio di una VM dall'interno del sistema operativo guest non ne comporta l'aggiornamento della MTU.
Se aumenti la MTU della rete VPC, le VM in esecuzione che utilizzano la rete VPC non sfrutteranno l'aumento della MTU della rete VPC finché le VM non saranno state arrestate e avviate. Finché ogni VM non viene arrestata e riavviata, la VM continua a utilizzare il valore MTU precedente (inferiore).
Per le istruzioni, consulta Modificare l'impostazione MTU di una rete VPC.
Impostazioni GKE e MTU
La MTU selezionata per l'interfaccia di un pod dipende dall'interfaccia di rete del container (CNI) utilizzata dai nodi del cluster e dall'impostazione MTU VPC sottostante. Per ulteriori informazioni, consulta la sezione Pod.
Il valore MTU dell'interfaccia del pod è 1460 o ereditato dall'interfaccia
principale del nodo.
| CNI | MTU | GKE Standard |
|---|---|---|
| Kubernetes | 1460 | Predefinito |
|
kubenet (GKE versione 1.26.1 e successive) |
Ereditato | Predefinito |
| Calico | 1460 |
Attivazione tramite Per maggiori dettagli, consulta Controllare la comunicazione tra pod e servizi utilizzando i criteri di rete. |
| netd | Ereditato | L'attivazione avviene tramite: |
| GKE Dataplane V2 | Ereditato |
Attivazione tramite Per maggiori dettagli, consulta Utilizzo di GKE Dataplane V2. |
MTU non corrispondenti, blocco 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 mancate corrispondenze delle MTU. Sia il client che il server calcolano singolarmente i propri valori di dimensione massima del segmento (MSS) TCP effettivi ogni volta che viene aperta una connessione TCP. Il client e il server non devono essere concordi con lo stesso valore effettivo di MSS.
Dimensione massima del segmento (MSS) TCP effettiva del client: la maggiore quantità di dati trasmissibili in un segmento TCP inviato da un client a un server è la minima dei due valori seguenti:
Il valore del campo MSS nel pacchetto SYN-ACK ricevuto dal client dal server durante la creazione 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 maggiore quantità di dati trasmissibili in un segmento TCP inviato da un server a un client è la minima dei due valori seguenti:
Il valore del campo MSS nel pacchetto SYN ricevuto dal server dal client durante la creazione della connessione TCP.
La 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.
blocco TCP MSS
Il blocco TCP MSS è un processo in cui un dispositivo di rete tra un client e un server modifica i valori MSS nei pacchetti SYN e SYN-ACK durante il routing dei pacchetti tra il client e il server. Google Cloud utilizza il blocco MSS ogni volta che invia pacchetti a destinazioni al di fuori di una rete VPC.
Anche i tunnel Cloud VPN e i collegamenti VLAN di Cloud Interconnect utilizzano il blocco MSS. Per ulteriori informazioni, consulta Incapsulamento ed elaborazione dei pacchetti nella documentazione di Cloud VPN e sulla MTU di Cloud Interconnect.
Le reti VPC non eseguono il blocco MSS per i pacchetti instradati dagli hop successivi all'interno di una rete VPC perché il protocollo TCP stesso è sufficiente.
Protocolli non TCP
Altri protocolli, come UDP, richiedono particolare attenzione quando sono coinvolte due diverse MTU di rete VPC. È responsabilità del sistema di invio emettere i pacchetti che rientrano nella MTU della sua interfaccia di rete, la MTU dell'interfaccia di rete del sistema ricevente e la MTU di tutte le reti intermedie. Google Cloud non esegue la frammentazione IP per i pacchetti instradati dagli hop successivi all'interno di una rete VPC.
Quando un pacchetto IP è troppo grande per essere consegnato, ad esempio quando supera la MTU della rete VPC in cui si trova il NIC della VM ricevente, Google Cloud ignora il pacchetto. Se per il pacchetto è impostato il bit DF, Google Cloud invia al mittente anche un messaggio Fragmentation Needed (ICMP su IPv4) o Packet Too Big (ICMPv6).
Google Cloud invia un messaggio Frammentazione necessaria o Pacchetto troppo grande nelle seguenti circostanze, anche quando un bit DF non è impostato:
- Se la MTU della rete VPC è inferiore a 1600 byte e il pacchetto inviato supera la MTU della rete VPC.
- Se la MTU della rete VPC è pari o superiore a 1600 byte e il pacchetto inviato supera i 1600 byte.
Per una VM che invia pacchetti per utilizzare il rilevamento MTU del percorso (PMTUD) sono necessari messaggi di frammentazione ICMP necessaria o pacchetti di dimensioni troppo grandi. Per illustrare il funzionamento di PMTUD, considera l'esempio seguente con due VM in reti VPC diverse collegate tramite peering di rete VPC:
- La VM di invio ha un NIC in una rete VPC la cui MTU è di 8896 byte.
- La VM ricevente ha un NIC in una rete VPC la cui MTU è di 1460 byte.
- La VM di invio emette un pacchetto IP da 8000 byte per cui è impostato il bit
DF(Don't Fragment). Poiché il pacchetto è troppo grande per essere consegnato alla VM ricevente, Google Cloud invia un messaggio relativo alla frammentazione richiesta o al pacchetto troppo grande alla VM di invio. Questo messaggio indica la dimensione massima del pacchetto IP che il mittente può utilizzare quando tenta di ritrasmettere i pacchetti per la connessione. - Il sistema operativo della VM di invio utilizza queste informazioni per ridurre la dimensione dei pacchetti IP durante l'invio di pacchetti successivi alla VM ricevente.
PMTUD ha i seguenti requisiti aggiuntivi perché i pacchetti Frammentazione necessaria generata da PMTUD o Pacchetti troppo grandi utilizzano il protocollo ICMP e hanno origini che corrispondono alla destinazione di un pacchetto originale:
- Devi configurare l'autorizzazione delle regole firewall VPC o delle regole dei criteri firewall in entrata in modo che ICMP (per IPv4) o ICMPv6 (per IPv6) siano consentiti da origini che corrispondono alle destinazioni dei pacchetti originali. Per semplificare la configurazione del firewall, valuta la possibilità di autorizzare ICMP e ICMPv6 da tutte le origini.
- Le regole di forwarding per il bilanciatore del carico di rete passthrough interno e l'inoltro del protocollo interno devono utilizzare il protocollo
L3_DEFAULTin modo che elaborino sia l'ICMP per il PMTUD sia il protocollo utilizzato dal pacchetto originale.
Passaggi successivi
- Per controllare il funzionamento di una MTU diversa, consulta Creare e verificare una rete MTU di frame jumbo.
- Crea una rete VPC con una MTU specificata.
- Modificare l'impostazione MTU di una rete VPC.
Provalo
Se non hai mai utilizzato 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