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 valide per le reti 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 e 8896 byte (inclusi). Le dimensioni MTU personalizzate comuni sono 1500 byte (Ethernet standard) o 8896 byte (il massimo possibile). Ti consigliamo di configurare la MTU per ogni interfaccia di rete (NIC) dell'istanza Compute Engine in modo che corrisponda alla MTU della rete VPC a cui è connessa. Per saperne di più, consulta Istanze di computing e impostazioni MTU.

Comunicazione tra le istanze di computing all'interno delle reti VPC

I pacchetti IP fino alla dimensione MTU possono essere inviati tra due istanze di computing, se si verificano le seguenti condizioni:

  • Sia l'istanza di invio sia quella di ricezione utilizzano la stessa rete VPC o reti VPC in peering che hanno MTU identiche.
  • Le interfacce di entrambe le istanze sono configurate per utilizzare la MTU della rete VPC.

Per evitare problemi di mancata corrispondenza della MTU, ti consigliamo di utilizzare la stessa MTU per tutte le reti VPC connesse. Sebbene sia la pratica consigliata, non sei obbligato a configurare MTU identiche sulle 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 un'istanza di invio, i percorsi verso le seguenti destinazioni rappresentano il traffico da istanza a istanza instradato all'interno di una rete VPC:

  • Un indirizzo IPv4 interno regionale in un intervallo di indirizzi IPv4 principali o secondari della subnet, 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 (NIC) dell'istanza di ricezione.
    • Un indirizzo IPv4 interno in un intervallo IP dell'alias della NIC dell'istanza 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 dell'intervallo di indirizzi IPv6 /96 assegnato alla NIC di un'istanza di ricezione.
    • Un indirizzo IPv6 dell'intervallo di indirizzi IPv6 /96 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 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 dell'intervallo di indirizzi IPv6 /96 assegnato alla NIC di un'istanza di ricezione.
    • Un indirizzo IPv6 dell'intervallo di indirizzi IPv6 /96 di una regola di forwarding esterna per il forwarding del protocollo o per un bilanciatore del carico di rete passthrough esterno regionale.

I seguenti percorsi da istanza a istanza vengono trattati allo stesso modo di Comunicazione verso destinazioni esterne a una rete VPC network:

  • Se la destinazione del pacchetto è un indirizzo IPv4 esterno della NIC di un'istanza di ricezione.
  • Se la destinazione del pacchetto è un indirizzo IPv4 esterno di un bilanciatore del carico di rete passthrough esterno regionale.
  • 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 un'istanza, di un bilanciatore del carico di rete passthrough esterno regionale o di una regola di forwarding per il forwarding del protocollo esterno e la route applicabile nella rete VPC utilizza un hop successivo del gateway internet predefinito. In questo scenario, le istanze di ricezione non si trovano nella stessa rete VPC dell'istanza di invio né in una rete VPC connessa alla rete VPC dell'istanza di invio tramite peering di rete VPC.

Comunicazione verso destinazioni esterne a una rete VPC

Google Cloud elabora i pacchetti inviati dalle istanze di computing a destinazioni esterne alla rete VPC dell'istanza di invio, come mostrato nella tabella seguente. Le destinazioni esterne alla rete VPC di un'istanza di invio includono indirizzi IP instradabili pubblicamente per le risorse esterne Google Cloud e indirizzi IP esterni utilizzabili dal cliente all'interno Google Cloud.

Poiché internet in genere utilizza una MTU di 1500 byte, mantenere la dimensione del pacchetto IP a 1500 byte o meno in genere evita la perdita di pacchetti correlata alla MTU.

Situazione Comportamento
Pacchetti TCP SYN e SYN-ACK Google Cloud esegue il blocco MSS, se necessario, modificando l' MSS per assicurarsi che i pacchetti rientrino nella MTU.
MTU del 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 di dimensioni maggiori 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 istanze di computing che utilizzano qualsiasi dimensione MTU di rete VPC valida possono inviare pacchetti ai servizi e alle API di Google, anche utilizzando l'accesso privato Google e Private Service Connect per le API di Google. I dettagli in questa sezione si applicano anche alle risorse on-premise che inviano pacchetti ai servizi e alle API di Google utilizzando l'accesso privato Google per gli host on-premise.

Il percorso del traffico verso i servizi e le API di Google descritto in questa sezione viene implementato dai Google Front End (GFE). Questi GFE utilizzano MTU fisse e non configurabili. Il traffico da Google Cloud a servizi e API di Google utilizza sempre il protocollo TCP: se un'istanza di computing si connette a servizi e API di Google da una rete VPC la cui MTU non corrisponde alla MTU 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 del pacchetto Destinazione del pacchetto

Qualsiasi indirizzo IPv4 interno: indirizzo IPv4 interno principale o indirizzo IPv4 interno da un intervallo IP dell'alias della NIC dell'istanza

Un indirizzo IPv4 esterno assegnato alla NIC dell'istanza utilizzando una configurazione di accesso NAT 1:1 : in questa situazione, Google Cloud esegue 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.
  • Indirizzi IPv4 dei servizi e delle API di 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 i servizi e le API di Google
Indirizzo IPv6 esterno o interno, per istanze a doppio stack o solo IPv6
  • Indirizzi IPv6 dei servizi e delle API di 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 una MTU del gateway per i pacchetti incapsulati sia una MTU del payload 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 Cloud Interconnect (VLAN)

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

Comunicazione tramite endpoint firewall

Se utilizzi gli endpoint firewall, configura una MTU appropriata per la tua rete VPC. Se l'impostazione MTU della rete VPC supera la dimensione del pacchetto supportata dall'endpoint firewall, Cloud Next Generation Firewall non può eseguire correttamente l'ispezione di livello 7. Per saperne di più, consulta Dimensioni dei pacchetti supportate.

Supporto per i frame jumbo

I frame jumbo hanno un payload di dimensioni maggiori di 1460 byte. La tabella seguente riassume il supporto per i frame jumbo per Google Cloud prodotti e funzionalità:

Prodotto o funzionalità Supporto per i frame jumbo
Compute Engine Sì
Cloud Interconnect Sì
Endpoint del firewall Sì
Cloud VPN No
API di Google No

Istanze di computing e impostazioni MTU

Come best practice, fai in modo che la MTU della NIC di un'istanza di computing corrisponda alla MTU della rete VPC a cui è connessa la NIC. La configurazione della MTU della NIC varia a seconda del sistema operativo e della configurazione:

  • Istanze Linux basate su un'immagine del sistema operativo pubblico: la MTU di ogni NIC viene impostata automaticamente sulla MTU della rete VPC corrispondente utilizzando l'opzione DHCP 26.

  • Istanze Windows basate su un'immagine del sistema operativo pubblico: per impostazione predefinita, la MTU di ogni NIC è configurata con una MTU fissa di 1,460 byte. Se modifichi la MTU di una rete VPC che contiene istanze Windows basate su immagini del sistema operativo pubblico, devi modificare l'impostazione MTU delle istanze Windows.

  • Immagini del sistema operativo guest personalizzate: devi configurare le MTU delle NIC o verificare che il sistema operativo guest accetti la MTU della rete VPC utilizzando l'opzione DHCP 26.

  • Istanze con più interfacce di rete: imposta la MTU di ogni NIC sulla MTU della rete VPC corrispondente.

Se la MTU di una NIC deve essere diversa dalla MTU della rete VPC, imposta la MTU della NIC su un valore inferiore alla MTU della rete VPC. La riduzione forzata della MTU della NIC è vantaggiosa per alcuni scenari di networking avanzati.

Modifica della MTU di una rete VPC

Per evitare problemi di connettività, prima di modificare la MTU della rete VPC, devi prima arrestare ogni istanza di computing. Il riavvio di un'istanza dal sistema operativo guest non aggiorna la relativa MTU. Se scegli di configurare le istanze con una MTU inferiore alla MTU della rete, il requisito di arrestare l'istanza prima di modificare la MTU rimane valido.

Per saperne di più sulla modifica della MTU della rete, consulta Modificare l'impostazione MTU di una rete VPC.

Impostazioni MTU e GKE

La 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 saperne di più, consulta Pod.

Il valore MTU dell'interfaccia Pod è 1460 o viene 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

Abilitato utilizzando --enable-network-policy.

Per informazioni dettagliate, consulta Controllare la comunicazione tra pod e servizi utilizzando i criteri di rete.
netd Ereditato Abilitato utilizzando uno dei seguenti:
GKE Dataplane V2 Ereditato

Abilitato utilizzando --enable-dataplane-v2.

Per informazioni dettagliate, consulta Utilizzare GKE Dataplane V2.

MTU non corrispondenti, blocco MSS, rilevamento MTU del percorso

Questa sezione descrive come i protocolli TCP e non TCP gestiscono le MTU non corrispondenti.

Protocollo TCP

Il protocollo TCP gestisce automaticamente le mancate corrispondenze della MTU. Sia il client sia il server calcolano individualmente i propri valori MSS (Maximum Segment Size) TCP effettivi ogni volta che viene aperta una connessione TCP. Il client e il server non devono concordare un valore MSS effettivo identico.

  • MSS (Maximum Segment Size) TCP effettivo 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.

    • 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.

  • MSS (Maximum Segment Size) TCP effettivo del server: la quantità massima 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.

    • 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 MSS TCP

Il blocco 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 mentre instrada i pacchetti tra il client e il server. Google Cloud utilizza il blocco MSS ogni volta che invia pacchetti a destinazioni esterne a una rete VPC.

Anche i tunnel Cloud VPN e i collegamenti VLAN Cloud Interconnect utilizzano il blocco MSS. Per saperne di più, consulta Incapsulamento ed elaborazione dei pacchetti nella documentazione di Cloud VPN e 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 MTU di rete VPC diverse. È responsabilità di un sistema di invio emettere pacchetti che rientrino nella MTU dell'interfaccia di rete, nella MTU dell'interfaccia di rete del sistema di ricezione e nella 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 inviato, ad esempio quando il pacchetto supera la MTU della rete VPC in cui si trova la NIC dell'istanza di computing di ricezione , Google Cloud elimina il pacchetto. Se il pacchetto ha il DF bit impostato, Google Cloud invia anche un messaggio Fragmentation Needed (ICMP su IPv4) o Packet Too Big (ICMPv6) a il mittente.

Google Cloud invia un messaggio Fragmentation Needed o Packet Too Big nelle seguenti circostanze, anche quando un bit DF è disattivato:

  • 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 è di 1600 byte o superiore e il pacchetto inviato supera i 1600 byte.

I messaggi ICMP Fragmentation Needed o Packet Too Big sono necessari per un' istanza di computing che invia pacchetti per utilizzare il rilevamento MTU del percorso (PMTUD). Per illustrare il funzionamento di PMTUD, considera il seguente esempio con due istanze di computing in reti VPC diverse connesse tramite peering di rete VPC:

  • L'istanza di invio ha una NIC in una rete VPC la cui MTU è di 8896 byte.
  • L'istanza di ricezione ha una NIC in una rete VPC la cui MTU è di 1460 byte.
  • L'istanza di invio emette un pacchetto IP di 8000 byte con il bit Don't Fragment (DF) impostato. Poiché il pacchetto è troppo grande per essere inviato all' istanza di ricezione, Google Cloud invia un messaggio Fragmentation Required o Packet Too Big all'istanza 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 dell'istanza di invio utilizza queste informazioni per ridurre la dimensione del pacchetto IP quando invia i pacchetti successivi all'istanza 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 di autorizzazione in entrata regole firewall VPC o regole nelle policy firewall 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 consentire ICMP e ICMPv6 da tutte le origini.
  • Le regole di forwarding per il bilanciatore del carico di rete passthrough interno e il forwarding 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

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 costi per l'esecuzione, il test e il deployment dei carichi di lavoro.

Prova VPC senza costi