Unità massima di trasmissione

L'unità massima di trasmissione (MTU) è la dimensione in byte del pacchetto IP più grande possibile, inclusi intestazioni IP, intestazioni del protocollo di livello 4 e dati di livello 4, che può essere inserito in un frame Ethernet.

Dimensioni MTU della rete VPC valide

Le reti Virtual Private Cloud (VPC) utilizzano un valore MTU predefinito di 1460 byte. Puoi impostare l'MTU di una rete VPC su un valore compreso tra 1300 byte e 8896 byte (inclusi). Le dimensioni MTU personalizzate comuni sono 1500 byte (Ethernet standard) o 8896 byte (il massimo possibile). Ti consigliamo di configurare l'MTU per ogni interfaccia di rete (NIC) della macchina virtuale (VM) in modo che corrisponda all'MTU della rete VPC a cui è connessa. Per saperne di più, consulta VM e impostazioni MTU.

Comunicazione tra Google Cloud VM all'interno delle reti VPC

Quando le VM di invio e ricezione utilizzano la stessa rete VPC o reti VPC con peering con MTU identiche, i pacchetti IP fino alle dimensioni MTU possono essere inviati tra le due VM, se le interfacce di entrambe le VM sono configurate per utilizzare l'MTU della rete VPC.

Per evitare problemi di mancata corrispondenza MTU, ti consigliamo di utilizzare lo stesso MTU per tutte le reti VPC connesse. Sebbene questa sia la prassi consigliata, non sei obbligato ad avere MTU identiche tra le reti VPC connesse. Per informazioni dettagliate su come i protocolli gestiscono le situazioni in cui si verifica una mancata corrispondenza della MTU tra le reti VPC, consulta MTU non corrispondenti, blocco MSS, rilevamento MTU del percorso.

Dal punto di vista di una VM di invio, i percorsi verso le seguenti destinazioni rappresentano il traffico da VM a VM instradato all'interno di una rete VPC:

  • Un indirizzo IPv4 interno regionale in un intervallo di indirizzi IPv4 primari o secondari della subnet, inclusi gli intervalli di indirizzi IPv4 privati e gli intervalli di indirizzi IPv4 pubblici utilizzati privatamente, utilizzati dalle seguenti risorse di destinazione:
    • L'indirizzo IPv4 interno principale dell'interfaccia di rete (NIC) di una VM di ricezione.
    • Un indirizzo IPv4 interno in un intervallo IP alias della NIC di una VM di ricezione.
    • Un indirizzo IPv4 interno di una regola di forwarding interna per il forwarding del 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 /96 assegnato alla NIC di una VM di ricezione.
    • Un indirizzo IPv6 dall'intervallo di indirizzi IPv6 /96 di una regola di forwarding interno per il forwarding del protocollo o per un bilanciatore del carico di rete passthrough interno.
  • 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 in peering all'interno della rete VPC:
    • Un indirizzo IPv6 dall'intervallo di indirizzi IPv6 /96 assegnato alla NIC di una VM di ricezione.
    • Un indirizzo IPv6 dall'intervallo di indirizzi IPv6 /96 di una regola di forwarding esterno per il forwarding del protocollo o per un bilanciatore del carico di rete passthrough esterno.

I seguenti percorsi da VM a VM vengono trattati allo stesso modo di Comunicazione con destinazioni al di fuori di una rete VPC:

  • Se la destinazione del pacchetto è un indirizzo IPv4 esterno della NIC della VMGoogle Cloud di ricezione.
  • 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 di una NIC VM, di un bilanciatore del carico di rete passthrough esterno o di una regola di forwarding per il forwarding di protocollo esterno e la route applicabile nella rete VPC utilizza un hop successivo del gateway internet predefinito. Google CloudIn questo scenario, le VM riceventi non si trovano nella stessa rete VPC della VM mittente né in una rete VPC connessa alla rete VPC della VM mittente utilizzando il peering di rete VPC.

Comunicazione con destinazioni esterne a una rete VPC

Google Cloud elabora i pacchetti inviati a destinazioni al di fuori della rete VPC della VM di invio come mostrato nella tabella seguente. Le destinazioni al di fuori della rete VPC di una VM di invio includono indirizzi IP instradabili pubblicamente per le risorse al di fuori di Google Cloud e indirizzi IP esterni utilizzabili dal cliente all'interno di Google Cloud.

Poiché internet in genere utilizza un MTU di 1500 byte, mantenere le dimensioni dei pacchetti IP a 1500 byte o meno di solito evita la perdita di pacchetti correlata a MTU.

Situazione Comportamento
Pacchetti TCP SYN e SYN-ACK Google Cloud esegue il clamping MSS, se necessario, modificando l'MSS per garantire che i pacchetti rientrino nell'MTU.
MTU pacchetto IP compresa 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 più grande di 1600 byte Google Cloud elimina il pacchetto e invia un messaggio Fragmentation Needed (ICMP su IPv4) o Packet Too Big (ICMPv6) sia quando il bit DF è attivo sia quando è disattivato.

Comunicazione con i servizi e le API di Google

Le VM che utilizzano qualsiasi dimensione MTU di rete VPC valida possono inviare pacchetti ad API e servizi Google, incluso l'utilizzo dell'accesso privato Google e di Private Service Connect per le API Google. I dettagli di 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 è implementato dai Google Front End (GFE). Questi GFE utilizzano MTU fisse e 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 a quella del GFE, la dimensione del segmento viene negoziata utilizzando l'annuncio MSS TCP come descritto in MTU non corrispondenti, blocco MSS, rilevamento MTU del percorso.

Origine pacchetto 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 la NAT 1:1 in uscita, convertendo un indirizzo IPv4 interno principale di origine in un indirizzo IPv4 esterno di origine specificato nella configurazione di accesso.
  • Indirizzi IPv4 delle API e dei servizi Google per i domini predefiniti
  • 199.36.153.4/30 (restricted.googleapis.com)
  • 199.36.153.8/30 (private.googleapis.com)
  • Endpoint Private Service Connect per le API e i servizi Google
Indirizzo IPv6 esterno o interno, per VM dual-stack o solo IPv6 (anteprima)
  • Indirizzi IPv6 delle API e dei servizi Google per i domini predefiniti
  • 2600:2d00:0002:1000::/64 (restricted.googleapis.com)
  • 2600:2d00:0002:2000::/64 (private.googleapis.com)

Comunicazione tramite tunnel Cloud VPN

Cloud VPN ha sia un MTU del gateway per i pacchetti incapsulati sia un MTU del payload per i pacchetti prima e dopo l'incapsulamento.

Per valori MTU del payload precisi e altre informazioni sull'MTU di Cloud VPN, consulta Considerazioni sull'MTU nella documentazione di Cloud VPN.

Comunicazione tramite i collegamenti Cloud Interconnect (VLAN)

Ti consigliamo di utilizzare lo stesso MTU per tutti i collegamenti VLAN connessi alla stessa rete VPC e di impostare l'MTU della rete VPC sullo stesso valore. Per informazioni dettagliate sulle MTU collegamento VLAN Cloud Interconnect, consulta MTU di Cloud Interconnect.

Supporto dei jumbo frame

La seguente tabella riepiloga il supporto dei jumbo frame tra Google Cloud prodotti e funzionalità:

Prodotto o funzionalità Supporto dei jumbo frame
Compute Engine Sì
Cloud Interconnect Sì
Cloud VPN No
API di Google No

VM e impostazioni MTU

Come best practice, associa l'MTU della NIC di una VM all'MTU della rete VPC a cui è connessa la NIC:

  • L'MTU di ogni NIC per una VM Linux basata su un'immagine del sistema operativo pubblico viene impostata automaticamente sull'MTU della rete VPC corrispondente utilizzando l'opzione DHCP 26.

  • L'MTU di ogni NIC per una VM Windows basata su un'immagine sistema operativo pubblica è configurata con un'MTU fissa di 1,460 byte. Se modifichi l'MTU di una rete VPC che contiene VM Windows basate su immagini sistema operativo pubbliche, devi modificare l'impostazione MTU di una VM Windows.

  • Se utilizzi immagini del 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 l'MTU di ogni NIC sull'MTU della rispettiva rete VPC.

  • Se l'MTU di una NIC deve essere diverso dall'MTU della rete VPC, imposta l'MTU della NIC su un valore inferiore all'MTU della rete VPC. La riduzione forzata dell'MTU della NIC è vantaggiosa per alcuni scenari di rete avanzati.

Modificare la MTU di una rete VPC

Se modifichi l'MTU di una rete VPC con VM in esecuzione, tieni presente quanto segue:

  • Se riduci l'MTU della rete VPC, devi arrestare e avviare ogni VM. Il riavvio di una VM dal sistema operativo guest non aggiorna la relativa MTU.

  • Se aumenti l'MTU della rete VPC, le VM in esecuzione che utilizzano la rete VPC non sfruttano l'MTU della rete VPC aumentata finché non vengono arrestate e avviate. Finché ogni VM non viene arrestata e riavviata, la VM continua a utilizzare il valore MTU precedente (inferiore).

Per istruzioni, vedi Modificare l'impostazione MTU di una rete VPC.

Impostazioni GKE e MTU

L'MTU selezionata per un'interfaccia pod dipende dall'interfaccia di rete 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
kubenet 1460 Predefinito
kubenet
(GKE versione 1.26.1 e successive) 		Ereditato Predefinito
Calico 1460

Attivata tramite --enable-network-policy.

Per maggiori dettagli, vedi Controllare la comunicazione tra pod e servizi utilizzando i criteri di rete.
netd Ereditato Attivata utilizzando uno dei seguenti metodi:
GKE Dataplane V2 Ereditato

Attivata tramite --enable-dataplane-v2.

Per i dettagli, consulta Utilizzo di GKE Dataplane V2.

MTU non corrispondenti, blocco MSS, Path MTU Discovery

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 MTU. Sia il client sia il server calcolano individualmente 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 concordare un valore MSS effettivo identico.

  • Dimensione massima del segmento (MSS) TCP effettiva del client: la quantità massima di dati trasmissibili in un segmento TCP inviato da un client a un server è il minimo dei due valori seguenti:

    • Il valore del campo MSS nel pacchetto SYN-ACK ricevuto dal client dal server durante la creazione della connessione TCP.

    • L'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 TCP (MSS) effettiva del server: la quantità più grande 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 dal 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.

Blocco MSS TCP

Il clamping MSS TCP è 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 clamping 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 saperne di più, consulta Incapsulamento e elaborazione dei pacchetti nella documentazione di Cloud VPN e MTU di Cloud Interconnect.

Le reti VPC non eseguono il clamping 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 MTU di rete VPC diverse. È responsabilità di un sistema di invio emettere pacchetti che rientrano nell'MTU dell'interfaccia di rete, nell'MTU dell'interfaccia di rete del sistema di ricezione e nell'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 recapitato, ad esempio quando il pacchetto supera l'MTU della rete VPC in cui si trova la NIC della VM ricevente, Google Cloud elimina il pacchetto. Se il pacchetto ha il bit DF impostato, Google Cloud invia anche un messaggio Frammentazione necessaria (ICMP su IPv4) o Pacchetto troppo grande (ICMPv6) al mittente.

Google Cloud invia un messaggio Frammentazione necessaria o Pacchetto troppo grande nelle seguenti circostanze, anche quando il bit 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 è di 1600 byte o più e il pacchetto inviato supera i 1600 byte.

I messaggi ICMP Fragmentation Needed o Packet Too Big sono necessari per una VM che invia pacchetti per utilizzare Path MTU Discovery (PMTUD). Per illustrare il funzionamento di PMTUD, considera il seguente esempio con due VM in reti VPC diverse connesse tramite peering di rete VPC:

  • La VM di invio ha una NIC in una rete VPC la cui MTU è di 8896 byte.
  • La VM di ricezione ha una NIC in una rete VPC il cui MTU è 1460 byte.
  • La VM di invio emette un pacchetto IP di 8000 byte il cui bit Don't Fragment (DF) è impostato. Poiché il pacchetto è troppo grande per essere recapitato alla VM di ricezione, Google Cloud invia un messaggio di frammentazione richiesta o pacchetto troppo grande alla VM di invio. Questo messaggio indica la dimensione massima possibile 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 le dimensioni del pacchetto IP quando invia i pacchetti successivi alla VM di ricezione.

PMTUD ha i seguenti requisiti aggiuntivi perché i pacchetti Fragmentation Needed o Packet Too Big generati da PMTUD utilizzano il protocollo ICMP e hanno origini che corrispondono alla destinazione di un pacchetto originale:

  • Devi configurare le regole firewall VPC o le regole nelle policy del firewall in modo che ICMP (per IPv4) o ICMPv6 (per IPv6) siano consentiti dalle origini che corrispondono alle destinazioni dei pacchetti originali. Per semplificare la configurazione del firewall, valuta la possibilità di consentire ICMP e ICMPv6 da tutte le origini.
  • Le regole di forwarding per il bilanciatore del carico di rete passthrough interno e l'inoltro di 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

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 senza addebiti per l'esecuzione, il test e il deployment dei workload.

Prova VPC gratuitamente