Le subnet sono suddivisioni logiche di una rete di indirizzi IP che forniscono segmenti gestibili per i tuoi servizi. Puoi definire subnet con intervalli di indirizzi IP specifici o configurarle per l'allocazione dinamica in Google Distributed Cloud (GDC) air-gapped.
Questo documento è destinato agli amministratori di rete all'interno del gruppo di amministratori della piattaforma e agli sviluppatori di applicazioni all'interno del gruppo di operatori delle applicazioni responsabili della gestione del traffico di rete per i propri servizi. Per saperne di più, consulta la documentazione relativa ai segmenti di pubblico per GDC air-gapped.
Reti in GDC
In un'organizzazione GDC sono disponibili due tipi di rete distinti per i quali puoi allocare indirizzi IP:
- Virtual Private Cloud (VPC): una rete a cui vengono allocati indirizzi IP interni accessibili solo dai carichi di lavoro all'interno della tua organizzazione.
- Segmento di rete esterno: una rete a cui vengono allocati indirizzi IP esterni accessibili da reti esterne connesse alla tua organizzazione.
Puoi allocare subnet all'interno di ogni tipo di rete per raggiungere obiettivi specifici. Una subnet è una suddivisione logica di una rete di indirizzi IP, definita da intervalli CIDR (Classless Inter-Domain Routing). Gli intervalli CIDR consentono di rappresentare gli indirizzi IP e le relative reti da utilizzare per un servizio. Ogni rete all'interno di questi tipi di rete ha un albero di subnet indipendente.
Le subnet all'interno di un VPC sono accessibili dalla rete GDC e non possono essere raggiunte al di fuori di GDC. Le subnet VPC sono disponibili per allocare indirizzi IP interni all'interno della tua organizzazione. Le subnet del segmento di rete sono esposte alle reti esterne connesse a un'organizzazione e ti consentono di fornire indirizzi IP esterni disponibili per le reti esterne alla tua organizzazione.
Rete VPC
Una rete VPC utilizza indirizzi IP interni accessibili solo all'interno della tua organizzazione e non raggiungibili da reti esterne alla tua organizzazione.
Nel tuo universo GDC sono disponibili due reti VPC:
- VPC predefinita: una rete VPC a cui vengono allocati indirizzi IP per carichi di lavoro interni, come container e macchine virtuali (VM), all'interno e tra più zone.
- VPC dell'infrastruttura: una VPC gestita dal sistema che ospita servizi GDC con air gap proprietari, come Vertex AI, API di osservabilità e la console GDC. Definisci gli indirizzi IP all'interno di questo VPC solo quando pianifichi l'architettura degli indirizzi IP della tua organizzazione.
Gli indirizzi IP all'interno di VPC predefinito e VPC dell'infrastruttura non possono sovrapporsi tra loro all'interno della stessa organizzazione. Per saperne di più, vedi Utilizzo e limitazioni di IPv4.
Crea una subnet in una rete VPC per allocare indirizzi IP aggiuntivi per i carichi di lavoro interni.
Segmento di rete esterno
A un segmento di rete esterno vengono allocati indirizzi IP esterni accessibili dalle reti esterne connesse alla tua organizzazione. Ai segmenti di rete in GDC vengono allocati solo indirizzi IP esterni.
GDC fornisce i seguenti segmenti di rete isolati logicamente:
- Segmento di rete amministrativa: una rete a cui vengono assegnati indirizzi IP esterni per i servizi amministrativi durante la creazione dell'organizzazione, ad esempio la console GDC e le API di gestione. Definisci gli indirizzi IP all'interno di questo segmento di rete solo quando pianifichi l'architettura degli indirizzi IP della tua organizzazione.
- Segmento di rete di dati: una rete a cui vengono allocati indirizzi IP esterni per servizi come Network Address Translation (NAT) in uscita e bilanciatori del carico esterni.
Puoi utilizzare interconnessioni distinte per connettere segmenti di rete ad altre reti esterne. Gli indirizzi IP all'interno dei segmenti di rete non possono sovrapporsi. Per saperne di più, vedi Utilizzo e limitazioni di IPv4.
Crea una subnet in un segmento di rete per allocare indirizzi IP esterni aggiuntivi per i servizi che devono connettersi a reti esterne alla tua organizzazione GDC.
Gerarchia delle subnet
Le subnet sono classificate in base al tipo:
- Radice: le subnet di primo livello da cui possono essere derivate altre subnet. Durante il provisioning della tua organizzazione, in ogni rete viene creata una subnet root globale.
- Ramo: subnet derivate da una subnet radice o da un altro ramo, utilizzate per suddividere ulteriormente lo spazio degli indirizzi IP.
- Foglia: la suddivisione più piccola, in genere utilizzata per allocare indirizzi IP per un servizio o una risorsa specifica.

Questo diagramma di esempio mostra come si connettono tra loro i diversi tipi di subnet:
- Una subnet radice di
10.0.0.0/16che funge da blocco di primo livello per le principali allocazioni di indirizzi IP. - Dalla subnet radice vengono derivate due subnet secondarie con valori
10.0.1.0/24e10.0.2.0/24. Queste subnet di diramazione rappresentano suddivisioni dello spazio di indirizzi della radice, destinate a scopi più specifici. - Le subnet dei rami sono ulteriormente suddivise in subnet foglia con valori come
10.0.1.10/32,10.0.1.11/32e10.0.2.12/24. Queste subnet foglia sono in genere le suddivisioni più piccole, spesso assegnando singoli indirizzi IP per servizi o risorse specifici.
Questa struttura gerarchica delle subnet ti consente di delegare e organizzare la rete in modo efficiente tra i workload e i servizi che si basano sugli indirizzi IP all'interno della rete.
Subnet globali e di zona
In GDC, puoi eseguire il provisioning delle subnet all'interno di due ambiti diversi: di zona e globale. Le subnet zonali e globali sono definite e operano all'interno di server API distinti e offrono funzionalità diverse.
Dopo il provisioning dell'organizzazione, ogni rete ha una subnet radice globale
ospitata nel server API globale della tua organizzazione. Per eseguire il provisioning degli indirizzi IP dalla subnet root globale, devi creare una risorsa Subnet globale nel server API globale che esegue il provisioning di un blocco CIDR in una zona o in più zone. All'interno della subnet globale, definisci il campo
propagationStrategy
per indicare come vuoi allocare il blocco CIDR nelle zone. Questo intervallo di indirizzi IP viene sottoposto a provisioning in una zona come subnet radice zonale.
Dopo che una zona ha la propria subnet root zonale, puoi creare risorse Subnet zonali nel server API di gestione della zona per dividere ulteriormente l'intervallo di indirizzi IP della subnet in subnet di diramazione aggiuntive all'interno della zona o in subnet foglia disponibili per singoli carichi di lavoro e servizi all'interno della zona.
Subnet globali
Devi creare una subnet globale per allocare indirizzi IP dalla subnet radice ospitata nel server API globale a una o più zone nel tuo universo GDC.
Le subnet globali vengono create nel server API globale utilizzando il gruppo di API ipam.global.gdc.goog/v1 e includono campi facoltativi come zone e propagationStrategy per definire la loro interazione con zone specifiche.
Le subnet globali ospitano un blocco CIDR come intervallo di subnet di ramo utilizzato dalle zone in un universo GDC. Per saperne di più su dove creare le subnet globali, consulta Reti in GDC.
Subnet zonali
Una subnet zonale è collegata a una zona operativa specifica, spesso incluse configurazioni di rete dirette. Le subnet di zona operano rigorosamente all'interno di una singola zona e vengono fornite principalmente per i carichi di lavoro di macchine virtuali e container all'interno di quella zona. Una subnet zonale alloca ulteriormente gli indirizzi IP già provisionati per la zona da utilizzare da una subnet globale.
Affinché la comunicazione da VPC a VPC tra le zone funzioni correttamente, in ogni zona devono essere utilizzate subnet non sovrapposte.
Le subnet di zona vengono create nel server API di gestione utilizzando il gruppo di API ipam.gdc.goog/v1 e includono un campo networkSpec facoltativo nella loro specifica, in modo da poter definire elementi di rete specifici della zona come gateway e ID VLAN.
Etichettatura delle subnet
Esistono quattro tipi di etichette di subnet:
ipam.gdc.goog/vpc: Specifica la rete della subnet come VPC.ipam.gdc.goog/network-segment: specifica la rete della subnet come segmento di rete.ipam.gdc.goog/usage: specifica lo scopo della subnet.ipam.gdc.goog/subnet-group: Specifica il gruppo di subnet a cui appartiene la subnet. Per saperne di più, consulta Gruppi di subnet.
La tabella seguente mostra la mappatura tra le reti e le etichette di rete:
| Rete | Etichetta |
|---|---|
| VPC predefinito | ipam.gdc.goog/vpc: default-vpc |
| VPC dell'infrastruttura | ipam.gdc.goog/vpc: infra-vpc |
| Segmento di rete amministratore | ipam.gdc.goog/network-segment: admin |
| Segmento di rete di dati | ipam.gdc.goog/network-segment: data |
Gli intervalli CIDR delle quattro reti vengono impostati nella tua organizzazione nell'ambito della procedura di bootstrap. Le quattro subnet globali corrispondenti si trovano nel server API globale.
Queste subnet globali sono l'intervallo CIDR di primo livello per ogni rete in tutte le zone di un'organizzazione. Tutte le subnet globali di primo livello hanno un'altra
etichetta ipam.gdc.goog/usage: network-root-range.
Per ogni zona, una subnet radice di rete zonale è inizialmente disponibile nel server API globale che ha origine dal provisioning dell'organizzazione. Puoi creare
subnet radice aggiuntive per espandere lo spazio degli indirizzi IP. Ogni subnet radice ospita
un intervallo CIDR per una rete nella zona specifica e funge logicamente da
subnet radice con ambito di zona con l'etichetta ipam.gdc.goog/usage: zone-network-root-range.
Questa subnet radice deve essere creata inizialmente nel server API globale e viene propagata automaticamente a una zona specificata. Per saperne di più sugli ambiti delle subnet, consulta Subnet globali e di zona.
Devi utilizzare le etichette definite quando crei una risorsa personalizzata Subnet per
applicarla alla rete GDC appropriata.
Il seguente diagramma illustra le reti globali e di zona all'interno di un universo GDC:

In questo diagramma, ci sono due organizzazioni che si estendono su un universo multizona. Ogni organizzazione definisce le reti VPC e i segmenti di rete esterni. In questo esempio, gli indirizzi IP anycast vengono utilizzati per instradare il traffico tra i segmenti di rete esterni zonali, in modo che la zona più vicina o con le prestazioni migliori gestisca la richiesta di rete. Per saperne di più sugli indirizzi IP anycast, consulta Indirizzi IP in GDC.
Gruppi di subnet
Un gruppo di subnet è un insieme di subnet con la stessa etichetta di gruppo di subnet, ad esempio
ipam.gdc.goog/subnet-group: subnetgroup1. L'organizzazione delle subnet in un gruppo
offre i seguenti vantaggi:
- Un gruppo di subnet semplifica lo scale up delle risorse di indirizzi IP di proprietà della stessa entità o utilizzate per lo stesso scopo. Una subnet non può essere scalata da sola, ma puoi scalare un gruppo di subnet collegandovi una nuova subnet. Gli utenti possono fare riferimento a un gruppo di subnet come risorsa di indirizzi IP e sfruttarne la comodità di scalabilità.
- Quando creano una subnet secondaria, gli utenti possono fare riferimento a un gruppo di subnet come elemento principale anziché a una singola subnet. Utilizzando un gruppo di subnet in questo modo, gli utenti non devono trovare autonomamente una subnet principale con spazio di indirizzi IP disponibile. GDC trova automaticamente una subnet nel gruppo di subnet con spazio di indirizzi IP disponibile sufficiente come subnet principale.
- Quando le risorse di indirizzi IP per un singolo scopo o entità vengono esaurite, con il gruppo di subnet come elemento principale, le informazioni sugli errori nella subnet secondaria sono più semplici e riducono il lavoro di controllo di ogni subnet.
Tutte le funzionalità del gruppo di subnet si applicano sia alle subnet globali sia a quelle di zona.
Creazione e scalabilità dei gruppi di subnet
Non esiste un oggetto API per un gruppo di subnet. Un gruppo di subnet è invece identificato da un'etichetta. Per creare o aggiungere un gruppo di subnet, aggiungi un'etichetta di gruppo di subnet a una subnet esistente o crea una nuova subnet con un'etichetta di gruppo di subnet.
Se il gruppo di subnet non esiste ancora, ne viene creato uno nuovo. Se nello stesso spazio dei nomi sono presenti altre subnet con la stessa etichetta del gruppo di subnet, la nuova subnet viene aggiunta al gruppo di subnet esistente.
L'esempio seguente mostra la definizione di una subnet collegata a un
gruppo di subnet denominato default-vpc-us-east67-b-group:
apiVersion: ipam.gdc.goog/v1
kind: Subnet
metadata:
# Several lines of code are omitted here.
labels:
ipam.gdc.goog/subnet-group: default-vpc-us-east67-b-group
ipam.gdc.goog/usage: zone-network-root-range
ipam.gdc.goog/vpc: default-vpc
name: default-vpc-us-east67-b-root-cidr
namespace: platform
# Several lines of code are omitted here.
spec:
ipv4Request:
cidr: 10.99.0.0/16
parentReference:
name: default-vpc-root-cidr
namespace: platform
type: SingleSubnet
type: Branch
Regole per la creazione e lo scaling dei gruppi di subnet
Quando crei un gruppo di subnet, tieni presente le seguenti regole:
- I gruppi di subnet sono definiti per ambito dello spazio dei nomi. Le subnet con la stessa etichetta del gruppo di subnet, ma in due spazi dei nomi diversi, sono considerate parte di due gruppi di subnet diversi.
- Una subnet non può essere discendente di un'altra subnet dello stesso gruppo.
- Le subnet dello stesso gruppo devono appartenere allo stesso segmento di rete o VPC.
- Una subnet può essere collegata a un solo gruppo di subnet.
Gruppi di subnet come gruppo principale
Quando crei una subnet secondaria, in alternativa all'utilizzo di una singola subnet come subnet principale, puoi fare riferimento a un gruppo di subnet come subnet principale. Per fare riferimento a un gruppo di subnet come elemento principale, devi completare i seguenti passaggi:
- Imposta esplicitamente
spec.parentReference.typesuSubnetGroup. Se lasciato vuoto, il valore predefinito èSingleSubnet. - Se il gruppo di subnet principale si trova in uno spazio dei nomi diverso dalla subnet secondaria,
devi specificare il campo
spec.parentReference.namespacecome spazio dei nomi del gruppo di subnet principale.
Dopo la creazione di una subnet secondaria da un gruppo di subnet, GDC alloca un blocco CIDR dal gruppo di subnet in base alla richiesta della subnet secondaria e alla disponibilità delle subnet nel gruppo di subnet principale. Se viene trovata una subnet principale adatta, la subnet secondaria riceve il blocco CIDR dalla subnet principale e il riferimento della subnet principale viene aggiornato nello stato della subnet secondaria.
La subnet nell'esempio seguente richiede un blocco CIDR dal
gruppo di subnet default-vpc-zone1-group e le viene assegnato un blocco CIDR
platform/default-vpc-zone1-root-cidr principale nello stato:
apiVersion: ipam.gdc.goog/v1
kind: Subnet
metadata:
# Several lines of code are omitted here.
labels:
ipam.gdc.goog/vpc: default-vpc
name: default-vpc-default-node-subnet
namespace: platform
# Several lines of code are omitted here.
spec:
ipv4Request:
prefixLength: 23
networkSpec:
enableGateway: true
enableVLANID: false
parentReference:
name: default-vpc-zone1-group
namespace: platform
type: SubnetGroup
type: Branch
status:
allocatedParent:
name: default-vpc-zone1-root-cidr
namespace: platform
type: SingleSubnet
# Several lines of code are omitted here.
Regole per fare riferimento a un gruppo di subnet come elemento principale
Quando fai riferimento a un gruppo di subnet come gruppo principale, tieni presente le seguenti regole:
- Il creatore della subnet secondaria deve disporre dell'autorizzazione per utilizzare tutte le subnet nel gruppo di subnet.
- La subnet secondaria deve trovarsi nello stesso VPC o segmento di rete del gruppo di subnet.
Configurazione CIDR statica e dinamica
Quando definisci le subnet, puoi utilizzare una configurazione statica o dinamica per assegnare i blocchi CIDR.
La configurazione CIDR statica consente di specificare in modo esplicito il blocco CIDR esatto per la subnet. Alloca staticamente il blocco CIDR quando hai bisogno di un controllo preciso
sul tuo spazio di indirizzi IP. Utilizza il campo spec.ipv4Request.cidr nella risorsa personalizzata Subnet per specificare l'intervallo di indirizzi IP esatto e predefinito.
La configurazione CIDR dinamica offre una maggiore flessibilità consentendo al sistema di
allocare automaticamente un blocco CIDR per la subnet. Anziché fornire un CIDR completo, specifica la lunghezza del prefisso richiesta nel campo spec.ipv4Request.prefixLength. Alloca dinamicamente il blocco CIDR se
preferisci che il sistema deleghi automaticamente gli indirizzi IP alle tue subnet,
semplificando la pianificazione della rete e riducendo il rischio di conflitti di indirizzi IP. Il sistema seleziona un blocco CIDR disponibile delle dimensioni specificate dalla rete principale.
Per saperne di più, consulta l'API
SubnetRequest.
Indirizzi IP in GDC
Risorse come VM e bilanciatori del carico hanno indirizzi IP in GDC. Questi indirizzi IP consentono alle risorse GDC di comunicare con altre risorse all'interno di un'organizzazione o con reti esterne connesse alla tua organizzazione. In un universo GDC sono disponibili i seguenti tipi di indirizzi IP:
- Indirizzo IP esterno
Gli indirizzi IP esterni vengono pubblicizzati alle reti esterne connesse a un'organizzazione. Le risorse con indirizzi IP esterni, come i bilanciatori del carico e NAT, possono comunicare con reti esterne. Con GDC, puoi utilizzare indirizzi IP privati o pubblici come indirizzi esterni. Fornisci indirizzi IPv4 esterni per le risorse nei seguenti modi:
- Bring Your Own IP (BYOIP): fornisci questi indirizzi IP esterni per la tua organizzazione. Gli indirizzi IP esterni BYOIP possono sovrapporsi a quelli di altre organizzazioni, a condizione che non si connettano alla stessa rete esterna.
- Indirizzi IP esterni forniti dall'IO: le organizzazioni possono utilizzare gli indirizzi IP esterni forniti dal gruppo di operatori dell'infrastruttura quando si connettono a una rete esterna. Il gruppo di operatori di infrastrutture è il fornitore della connettività a quella rete.
- Indirizzo IP interno
Gli indirizzi IP interni non sono raggiungibili direttamente dall'esterno di GDC e non sono instradabili pubblicamente. Gli indirizzi IP interni sono locali a una rete VPC, a una rete VPC connessa tramite peering di rete VPC o a una rete on-premise connessa a una rete VPC tramite Cloud VPN. Le risorse con indirizzi IP interni comunicano con altre risorse come se si trovassero tutte sulla stessa rete privata.
- Indirizzo IP anycast
Gli indirizzi IP Anycast sono un tipo speciale di indirizzo esterno che è sempre limitato all'intero universo GDC. GDC utilizza indirizzi IP anycast insieme al protocollo BGP (Border Gateway Protocol) per instradare il traffico alla zona più vicina o con il rendimento migliore. Ogni servizio globale di livello 4 in esecuzione in due o più zone riceve un indirizzo IP anycast dalla subnet anycast, una subnet esterna. Ogni zona pubblicizza lo stesso indirizzo IP anycast, ma la tua rete sceglie quello migliore in base alle regole di routing. Se una zona non funziona, ritira il suo indirizzo IP e la tua rete reindirizza automaticamente il traffico a un'altra zona. Questo routing automatico garantisce una connettività perfetta anche durante le interruzioni.
- Indirizzo IP privato
Gli indirizzi IP privati sono indirizzi che non possono essere instradati su internet. Per un elenco di intervalli IPv4 privati, consulta le voci relative agli intervalli di indirizzi IP privati nella tabella Intervalli IPv4 validi.
- Indirizzo IP pubblico
Gli indirizzi IP pubblici sono indirizzi instradabili su internet. In GDC, gli indirizzi IP esterni possono essere pubblici o privati. Puoi anche utilizzare indirizzi IPv4 pubblici come indirizzi interni quando configuri l'intervallo di indirizzi IPv4 principale di una subnet nella tua rete VPC. Questi indirizzi sono chiamati indirizzi IP pubblici utilizzati privatamente.
Utilizzo e limitazioni di IPv4
Ogni rete nel tuo universo GDC ha alcune limitazioni di utilizzo dell'intervallo di indirizzi IPv4 che devi considerare quando allochi gli indirizzi IP. Gli intervalli di indirizzi IPv6 non sono supportati nel segmento di rete VPC predefinito e dati. Contatta il tuo gruppo di operatori dell'infrastruttura per conoscere le possibilità di intervalli IPv6 in altre reti.
Limitazioni per tutte le subnet IPv4
Queste limitazioni si applicano alle subnet di rete VPC e alle subnet di segmenti di rete esterni.
- Tutte le subnet devono essere un blocco CIDR valido univoco.
- Una volta creata, una subnet non può essere aumentata, sostituita o ridotta.
- GDC non impone un limite alle dimensioni di un blocco CIDR
che può essere creato. Tuttavia, per la maggior parte degli intervalli di indirizzi IP superiori a
/8, ulteriori convalide impediscono di creare una subnet così grande. Ad esempio, una subnet non può sovrapporsi a una subnet vietata. Per ridurre al minimo la possibilità di scegliere una subnet non valida, ti consigliamo di limitare le dimensioni massime della subnet a/8. Non puoi creare subnet che si sovrappongano a subnet vietate, a qualsiasi altra subnet nella stessa rete VPC, a qualsiasi subnet in un segmento di rete esterno collegato o a qualsiasi subnet in una rete in peering. Devi collaborare con il tuo gruppo di operatori dell'infrastruttura per assicurarti di non creare subnet sovrapposte in questi scenari.
GDC crea le route corrispondenti per le subnet. Le subnet di rete VPC hanno route create nello stack di rete virtuale della tua organizzazione, mentre le subnet di segmenti di rete esterni hanno route create nella tabella di routing della rete in peering esterna.
Verifica che le subnet non siano in conflitto con l'indirizzamento IP on-premise se hai connesso la tua rete VPC a un'altra rete utilizzando una VPN gestita o un interconnect condiviso o dedicato.
Le subnet non devono corrispondere, essere più ristrette o più ampie di un intervallo vietato. Ad esempio,
169.0.0.0/8non è una subnet valida perché si sovrappone all'intervallo link-local169.254.0.0/16(RFC 3927), che è limitato.Le subnet non devono coprire un intervallo RFC, come descritto in Intervalli IPv4 validi, e un intervallo di indirizzi IP pubblico utilizzato privatamente. Ad esempio,
172.0.0.0/10non è una subnet valida perché include sia l'intervallo di indirizzi IP privati172.16.0.0/12sia indirizzi IP pubblici.Le subnet non devono coprire più intervalli RFC. Ad esempio,
192.0.0.0/8non è una subnet valida perché include sia192.168.0.0/16(RFC 1918) sia192.0.0.0/24(RFC 6890). Tuttavia, puoi creare due subnet, una con192.168.0.0/16e una con192.0.0.0/24.
Intervalli IPv4 validi
La tabella seguente descrive gli intervalli validi.
| Intervallo | Descrizione |
|---|---|
| Intervalli di indirizzi IPv4 privati | |
10.0.0.0/8172.16.0.0/12192.168.0.0/16
|
Indirizzi IP privati RFC 1918 Per informazioni sull'utilizzo di |
100.64.0.0/10 |
Spazio di indirizzi condiviso RFC 6598 |
192.0.0.0/24 |
Assegnazioni di protocollo IETF RFC 6890 |
192.0.2.0/24 (TEST-NET-1)198.51.100.0/24 (TEST-NET-2)203.0.113.0/24 (TEST-NET-3) |
Documentazione RFC 5737 |
192.88.99.0/24 |
Relay da IPv6 a IPv4 (ritirato) RFC 7526 |
198.18.0.0/15 |
Test di benchmark RFC 2544 |
240.0.0.0/4 |
Riservato per uso futuro (classe E) come indicato in RFC 5735 e RFC 1112. Alcuni sistemi operativi non supportano l'utilizzo di questo intervallo, quindi verifica che il tuo sistema operativo lo supporti prima di creare subnet che lo utilizzano. |
| Intervalli di indirizzi IP pubblici utilizzati privatamente | |
| Indirizzi IPv4 pubblici utilizzati privatamente |
Indirizzi IPv4 pubblici utilizzati privatamente:
GDC air-gapped non presuppone la connettività a internet. Di conseguenza, GDC air-gapped pubblicizza tutti gli intervalli di indirizzi IP pubblici come se fossero privati per la tua organizzazione. Se gli indirizzi Bring Your Own IP (BYOIP) importati sono intervalli di indirizzi IP pubblici, devi verificare che non causino problemi di rete in reti esterne. I tuoi indirizzi BYOIP non devono sovrapporsi ad altre subnet della tua organizzazione. |
Subnet IPv4 vietate
Gli intervalli di subnet vietati includono intervalli RFC normalmente riservati e qualsiasi subnet riservata a livello globale nel tuo universo GDC specifico, come descritto nella tabella seguente. Questi intervalli non possono essere utilizzati per le subnet.
| Intervallo | Descrizione |
|---|---|
| Intervallo di infrastruttura GDC |
Un blocco CIDR riservato a livello globale utilizzato dal sistema GDC. Se questo intervallo non è specificato per il campo zone-infra-cidr del questionario di acquisizione del cliente (CIQ), GDC utilizza 172.16.0.0/12 come intervallo dell'infrastruttura GDC per impostazione predefinita. |
| Intervalli specifici per universo | Intervalli aggiuntivi riservati dal gruppo dell'operatore dell'infrastruttura. |
0.0.0.0/8
|
Rete attuale (locale) RFC 1122 |
127.0.0.0/8
|
Host locale RFC 1122 |
169.254.0.0/16
|
Link-local RFC 3927 |
224.0.0.0/4
|
Multicast (classe D) RFC 5771 |
255.255.255.255/32
|
Indirizzo di destinazione di trasmissione limitata RFC 8190 e RFC 919 |
Indirizzi inutilizzabili nelle subnet IPv4
GDC utilizza i primi due e gli ultimi due indirizzi IPv4 in ogni subnet per ospitare la subnet.
| Indirizzo IPv4 inutilizzabile | Descrizione | Esempio |
|---|---|---|
| Indirizzo di rete | Il primo indirizzo nell'intervallo IPv4 principale. | 10.1.2.0 dall'intervallo 10.1.2.0/24 |
| Indirizzo del gateway predefinito | Il secondo indirizzo nell'intervallo IPv4 principale. | 10.1.2.1 dall'intervallo 10.1.2.0/24 |
| Penultimo indirizzo | Il penultimo indirizzo nell'intervallo IPv4 principale.
Questo intervallo è riservato da Google Cloud per un potenziale utilizzo futuro. |
10.1.2.254 dall'intervallo 10.1.2.0/24 |
| Indirizzo di broadcast | L'ultimo indirizzo nell'intervallo IPv4 principale. | 10.1.2.255 dall'intervallo 10.1.2.0/24 |
Ulteriori considerazioni
Alcuni prodotti Google e di terze parti utilizzano 172.17.0.0/16 per il routing all'interno del
sistema operativo guest. Ad esempio, la rete bridge Docker predefinita utilizza questo
intervallo. Se utilizzi un prodotto che utilizza 172.17.0.0/16, non utilizzarlo come intervallo di indirizzi IPv4 di una subnet.
Passaggi successivi
- Panoramica del networking
- Provisioning di indirizzi IP per i workload
- Integrazione degli indirizzi IP esterni
- Panoramica di più zone