Se usó la API de Cloud Translation para traducir esta página.

Subredes y direcciones IP en GDC

En esta página de descripción general, se explica el modelo operativo para las direcciones IP en un universo aislado de Google Distributed Cloud (GDC). Las direcciones IP se dividen en subredes para proporcionar segmentos administrables que puedes asignar a tus servicios. Puedes definir subredes con rangos de direcciones IP específicos o configurarlas para la asignación dinámica.

Esta página está dirigida a los administradores de redes dentro del grupo de administradores de la plataforma y a los desarrolladores de aplicaciones dentro del grupo de operadores de aplicaciones, que son responsables de administrar el tráfico de red de sus servicios en un universo de GDC. Para obtener más información, consulta Públicos de la documentación de Google Distributed Cloud aislado.

Redes en GDC

En una organización de GDC, hay dos tipos de redes distintos disponibles para los que puedes asignar direcciones IP:

Nube privada virtual (VPC): Es una red a la que se asignan direcciones IP internas a las que solo pueden acceder las cargas de trabajo dentro de tu organización.
Segmento de red externa: Es una red a la que se asignan direcciones IP externas a las que pueden acceder las redes externas conectadas a tu organización.

Puedes asignar subredes dentro de cada tipo de red para lograr objetivos específicos. Una subred es una subdivisión lógica de una red de direcciones IP, definida por rangos de enrutamiento entre dominios sin clases (CIDR). Los rangos CIDR te permiten representar direcciones IP y sus redes correspondientes para que las use un servicio. Cada red dentro de estos tipos de redes tiene un árbol de subredes independiente.

Se puede acceder a las subredes dentro de una VPC desde la red de GDC, pero no se puede acceder a ellas fuera de GDC. Las subredes de VPC están disponibles para asignar direcciones IP internas dentro de tu organización. Las subredes de segmentos de red se exponen a las redes externas conectadas a una organización y te permiten proporcionar direcciones IP externas disponibles para las redes fuera de tu organización.

Red de VPC

Una red de VPC usa direcciones IP internas a las que solo se puede acceder dentro de tu organización y a las que no pueden llegar las redes externas a tu organización.

Hay dos redes de VPC disponibles en tu universo de GDC:

VPC predeterminada: Es una VPC a la que se asignan direcciones IP para cargas de trabajo internas, como contenedores y máquinas virtuales (VM), dentro de varias zonas y entre ellas.
VPC de infraestructura: Es una VPC administrada por el sistema que aloja servicios de GDC aislados de Internet de origen, como Vertex AI, las APIs de Observability y la consola de GDC. Solo defines direcciones IP dentro de esta VPC cuando planificas la arquitectura de direcciones IP de tu organización.

Las direcciones IP dentro de la VPC predeterminada y la VPC de infraestructura no pueden superponerse entre sí dentro de la misma organización. Para obtener más información, consulta Uso y limitaciones de IPv4.

Crea una subred en una red de VPC para asignar direcciones IP adicionales a las cargas de trabajo internas.

Segmento de red externo

A un segmento de red externo se le asignan direcciones IP externas a las que pueden acceder las redes externas conectadas a tu organización. Los segmentos de red en GDC solo tienen asignadas direcciones IP externas.

GDC proporciona los siguientes segmentos de red aislados de forma lógica:

Segmento de red del administrador: Es una red a la que se asignan direcciones IP externas para los servicios administrativos durante la creación de la organización, como la consola de GDC y las APIs de administración. Solo defines direcciones IP dentro de este segmento de red cuando planificas la arquitectura de direcciones IP de tu organización.
Segmento de red de datos: Es una red a la que se asignan direcciones IP externas para servicios como la traducción de direcciones de red (NAT) de salida y los balanceadores de cargas externos.

Puedes usar interconexiones distintas para conectar segmentos de red a otras redes externas. Las direcciones IP dentro de los segmentos de red no pueden superponerse entre sí. Para obtener más información, consulta Uso y limitaciones de IPv4.

Crea una subred en un segmento de red para asignar direcciones IP externas adicionales a los servicios que deben conectarse a redes fuera de tu organización de GDC.

Jerarquía de subredes

Las subredes se clasifican según su tipo:

Raíz: Son las subredes de nivel superior a partir de las cuales se pueden derivar otras subredes. Se crea una subred raíz global en cada red durante el aprovisionamiento de tu organización.
Rama: Son subredes derivadas de una subred raíz o de otra rama, que se usan para subdividir aún más el espacio de direcciones IP.
Hoja: Es la subdivisión más pequeña y, por lo general, se usa para asignar direcciones IP a un servicio o recurso específico.

Puedes subdividir tus subredes para asignar direcciones IP a tus redes.

En este diagrama de ejemplo, se ilustra cómo se conectan los diferentes tipos de subredes entre sí:

Es una subred raíz de 10.0.0.0/16 que funciona como el bloque de nivel superior para las principales asignaciones de direcciones IP.
De la subred raíz, se derivan dos subredes de rama con valores de 10.0.1.0/24 y 10.0.2.0/24. Estas subredes de rama representan subdivisiones del espacio de direcciones de la raíz, destinadas a fines más específicos.
Las subredes de la rama se subdividen aún más en subredes hoja con valores como 10.0.1.10/32, 10.0.1.11/32 y 10.0.2.12/24. Por lo general, estas subredes de hoja son las subdivisiones más pequeñas y, a menudo, asignan direcciones IP únicas para servicios o recursos específicos.

Esta estructura jerárquica de subredes te permite delegar y organizar tu red de manera eficiente en las cargas de trabajo y los servicios que dependen de las direcciones IP dentro de tu red.

Subredes globales y zonales

En GDC, puedes aprovisionar subredes dentro de dos permisos diferentes: zonales y globales. Las subredes zonales y globales se definen y operan dentro de servidores de API distintos, y ofrecen diferentes capacidades.

Después de que se aprovisione tu organización, cada red tendrá una subred raíz global alojada en el servidor de la API global de tu organización. Para aprovisionar direcciones IP desde la subred raíz global, debes crear un recurso Subnet global en el servidor de la API global que aprovisione un bloque CIDR en una zona o en varias zonas. Dentro de la subred global, defines el campo propagationStrategy para indicar cómo deseas asignar tu bloque de CIDR en las zonas. Este rango de direcciones IP se aprovisiona en una zona como una subred raíz zonal.

Después de que una zona tenga su propia subred raíz zonal, puedes crear recursos Subnet zonales en el servidor de la API de administración de la zona para dividir aún más el rango de direcciones IP de la subred en subredes de rama adicionales dentro de la zona o subredes hoja que estén disponibles para cargas de trabajo y servicios individuales dentro de la zona.

Subredes globales

Debes crear una subred global para asignar direcciones IP desde la subred raíz alojada en el servidor de la API global a una o varias zonas de tu universo de GDC.

Las subredes globales se crean en el servidor de la API global con el grupo de APIs ipam.global.gdc.goog/v1 y, además, incluyen campos opcionales, como zone y propagationStrategy, para definir su interacción con zonas específicas.

Las subredes globales alojan un bloque CIDR como un rango de subred de rama que consumen las zonas en un universo de GDC. Para obtener más información sobre dónde crear tus subredes globales, consulta Redes en GDC.

Subredes zonales

Una subred zonal está vinculada a una zona operativa específica y, a menudo, incluye configuraciones de red directas. Las subredes zonales operan estrictamente dentro de una sola zona y se proporcionan principalmente para las cargas de trabajo de máquina virtual y contenedores dentro de esa zona. Una subred zonal asigna aún más direcciones IP que ya se aprovisionaron para que la zona las use en una subred global.

Para que la comunicación de VPC a VPC entre zonas funcione correctamente, se deben usar subredes que no se superpongan en cada zona.

Las subredes zonales se crean en el servidor de la API de administración con el grupo de APIs ipam.gdc.goog/v1 y, en su especificación, incluyen un campo networkSpec opcional, por lo que puedes definir elementos de red específicos de la zona, como puertas de enlace y IDs de VLAN.

Etiquetado de subredes

Existen cuatro tipos de etiquetas:

ipam.gdc.goog/vpc y ipam.gdc.goog/network-segment se usan para identificar la red a la que pertenece esta subred.
ipam.gdc.goog/usage refleja el propósito para el que se usará esta subred.
ipam.gdc.goog/subnet-group identifica el grupo de subredes al que pertenece esta subred. La función de grupos de subredes se presentará en la siguiente sección, Grupos de subredes.

En la siguiente tabla, se muestra la asignación entre las redes y las etiquetas de red:

Red	Etiqueta
VPC predeterminada	`ipam.gdc.goog/vpc: default-vpc`
VPC de infraestructura	`ipam.gdc.goog/vpc: infra-vpc`
Segmento de red del administrador	`ipam.gdc.goog/network-segment: admin`
Segmento de red de datos	`ipam.gdc.goog/network-segment: data`

Los rangos de CIDR de las cuatro redes se establecieron en tu organización como parte del proceso de arranque. Las cuatro subredes globales correspondientes residen en el servidor de la API global. Esas subredes globales son el rango de CIDR de nivel raíz para cada red en todas las zonas de una organización. Todas las subredes globales de nivel raíz tienen otra etiqueta ipam.gdc.goog/usage: network-root-range.

Para cada zona, inicialmente hay disponible una subred raíz de red zonal en el servidor de la API global que se origina en el aprovisionamiento de la organización. Puedes crear subredes raíz adicionales para expandir tu espacio de direcciones IP. Cada subred raíz aloja un rango CIDR para una red en la zona específica y, de forma lógica, funciona como la subred raíz con alcance zonal con la etiqueta ipam.gdc.goog/usage: zone-network-root-range. Esta subred raíz se debe crear inicialmente en el servidor de la API global y se propaga automáticamente a una zona especificada. Para obtener más información sobre los alcances de subredes, consulta Subredes globales y zonales.

Debes usar las etiquetas definidas cuando crees un recurso personalizado Subnet para aplicarlo a la red de GDC adecuada. En el siguiente diagrama, se ilustran las redes globales y zonales dentro de un universo de GDC:

Las subredes residen dentro de una zona y en el servidor de la API global.

En este diagrama, hay dos organizaciones que abarcan un universo multizonal. Cada organización define las redes de VPC y los segmentos de red externos. En este ejemplo, se usan direcciones IP de Anycast para enrutar el tráfico entre los segmentos de red externos zonales, de modo que la zona más cercana o con mejor rendimiento atienda la solicitud de red. Para obtener más información sobre las direcciones IP de difusión a varios destinatarios, consulta Direcciones IP en GDC.

Grupos de subredes

Un grupo de subredes es un conjunto de subredes con la misma etiqueta de grupo de subredes (p.ej., *ipam.gdc.goog/subnet-group: subnetgroup1). Organizar las subredes en un grupo proporciona los siguientes beneficios:

Un grupo de subredes simplifica el aumento de escala de los recursos de IP que pertenecen a la misma entidad o se usan para el mismo propósito. Una subred no se puede escalar por sí sola, pero un grupo de subredes sí se puede escalar si se le adjunta una subred nueva. Los usuarios pueden hacer referencia a un grupo de subredes como su recurso de IP y aprovechar su comodidad para aumentar la escala.
Cuando se crea una subred secundaria, los usuarios pueden hacer referencia a un grupo de subredes como principal en lugar de una sola subred. Si se usa un grupo de subredes de esta manera, los usuarios no necesitan buscar por sí mismos una subred principal que tenga espacio de IP disponible. En cambio, IPAM encontrará automáticamente una subred en el grupo de subredes con suficiente espacio de IP disponible como su principal.
Cuando se agotan los recursos de IP para un solo propósito o entidad, con el grupo de subredes como elemento superior, la información de error en la subred secundaria será más directa y reducirá el esfuerzo de verificar todas las subredes una por una.

Todas las funciones de los grupos de subredes se aplican tanto a las subredes globales como a las zonales.

Crea y aumenta la escala de un grupo de subredes

No hay API ni objeto para un grupo de subredes. En su lugar, un grupo de subredes se identifica con una etiqueta de grupo de subredes. Para crear un grupo de subredes o agregar una subred a uno, agrega una etiqueta de grupo de subredes a una subred existente o crea una subred nueva con una etiqueta de grupo de subredes.

Si el grupo de subredes aún no existe, se crea uno nuevo. Si ya hay otras subredes con la misma etiqueta de grupo de subred en el mismo espacio de nombres, la subred nueva se agregará al grupo de subred existente.

En el siguiente ejemplo, se muestra la definición de una subred que está adjunta a un grupo de subredes llamado default-vpc-us-east67-b-group.

apiVersion: ipam.gdc.goog/v1
kind: Subnet
metadata:
  ...
  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
  ...
spec:
  ipv4Request:
    cidr: 10.99.0.0/16
  parentReference:
    name: default-vpc-root-cidr
    namespace: platform
    type: SingleSubnet
  type: Branch

Reglas para crear y aumentar la escala de los grupos de subredes

Los grupos de subredes se definen por alcance de espacio de nombres. Las subredes con la misma etiqueta de grupo de subred, pero en dos espacios de nombres diferentes, se considerarán como parte de dos grupos de subredes diferentes.
Una subred no puede ser descendiente de otra subred en el mismo grupo.
Las subredes del mismo grupo deben pertenecer al mismo segmento de red o VPC.
Una subred solo se puede adjuntar a un grupo de subredes.

Usa un grupo de subredes como elemento superior

Cuando creas una subred secundaria, como alternativa a usar una sola subred como principal, el usuario puede hacer referencia a un grupo de subredes como principal. Para hacer referencia a un grupo de subredes como el grupo principal, deberás hacer lo siguiente:

Establece explícitamente spec.parentReference.type en SubnetGroup. Si se deja vacío, el valor predeterminado es SingleSubnet.
Si el grupo de subred principal se encuentra en un espacio de nombres diferente al de la subred secundaria, se debe especificar spec.parentReference.namespace para el espacio de nombres del grupo de subred principal.

Después de que se crea una subred secundaria a partir de un grupo de subredes, IPAM asignará un CIDR del grupo de subredes según la solicitud de la subred secundaria y la disponibilidad de las subredes en el grupo de subredes principal. Si se encuentra una subred principal adecuada, la subred secundaria obtendrá su CIDR de ella y se actualizará la referencia de la subred principal en el estado de la subred secundaria.

En el siguiente ejemplo, la subred solicita CIDR de default-vpc-zone1-group y se le asigna un platform/default-vpc-zone1-root-cidr principal en el estado.

apiVersion: ipam.gdc.goog/v1
kind: Subnet
metadata:
...
  labels:
    ipam.gdc.goog/vpc: default-vpc
  name: default-vpc-default-node-subnet
  namespace: platform
...
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
...

Reglas para hacer referencia a un grupo de subredes como elemento principal

Cuando se hace referencia a un grupo de subredes como principal, el creador de la subred secundaria debe tener permiso de "uso" en todas las subredes del grupo de subredes.
La subred secundaria debe estar en la misma VPC o segmento de red que el grupo de subredes.

Configuración de CIDR estática y dinámica

Cuando defines subredes, puedes usar una configuración estática o dinámica para asignar los bloques de CIDR.

La configuración estática de CIDR te permite especificar de forma explícita el bloque CIDR exacto para tu subred. Asigna tu bloque de CIDR de forma estática cuando necesites un control preciso sobre tu espacio de direcciones IP. Usa el campo spec.ipv4Request.cidr en el recurso personalizado Subnet para especificar el rango de direcciones IP exacto y predefinido.

La configuración dinámica de CIDR ofrece mayor flexibilidad, ya que permite que el sistema asigne automáticamente un bloque de CIDR para tu subred. En lugar de proporcionar un CIDR completo, especifica la longitud del prefijo requerida en el campo spec.ipv4Request.prefixLength. Asigna tu bloque CIDR de forma dinámica si prefieres que el sistema delegue automáticamente direcciones IP a tus subredes, lo que simplifica la planificación de la red y reduce el riesgo de conflictos de direcciones IP. El sistema selecciona un bloque CIDR disponible del tamaño especificado en la red principal.

Para obtener más información, consulta la API de SubnetRequest.

Direcciones IP en GDC

Los recursos, como las VMs y los balanceadores de cargas, tienen direcciones IP en GDC. Estas direcciones IP permiten que los recursos de GDC se comuniquen con otros recursos dentro de una organización o con redes externas conectadas a tu organización. Los siguientes tipos de direcciones IP están disponibles en un universo de GDC:

Dirección IP externa

Las direcciones IP externas se anuncian en las redes externas conectadas a una organización. Los recursos con direcciones IP externas, como los balanceadores de cargas y la NAT, pueden comunicarse con redes externas. Con GDC, puedes usar direcciones IP privadas o públicas como direcciones externas. Proporciona direcciones IPv4 externas para los recursos de las siguientes maneras:

Proporciona tus propias direcciones IP externas (BYOIP): Tú proporcionas estas direcciones IP externas para tu organización. Las direcciones IP externas de BYOIP pueden superponerse con las de otras organizaciones, siempre y cuando no se conecten a la misma red externa.
Direcciones IP externas proporcionadas por IO: Las organizaciones pueden usar las direcciones IP externas proporcionadas por el grupo de operadores de infraestructura cuando se conectan a una red externa. El grupo de operadores de infraestructura es el proveedor de la conectividad a esa red.

Dirección IP interna

No se puede acceder a las direcciones IP internas desde fuera de GDC directamente y no se pueden enrutar de forma pública. Las direcciones IP internas son locales a una red de VPC, una red de VPC conectada a través del intercambio de tráfico entre redes de VPC o una red local conectada a una red de VPC con Cloud VPN. Los recursos con direcciones IP internas se comunican con otros recursos como si estuvieran en la misma red privada.

Dirección IP Anycast

Las direcciones IP de Anycast son un tipo especial de dirección externa que siempre se limita a todo el universo de GDC. GDC aprovecha las direcciones IP de Anycast junto con el Protocolo de Puerta de Enlace Fronteriza (BGP) para enrutar el tráfico a la zona más cercana o con mejor rendimiento. Cada servicio global de capa 4 que se ejecuta en dos o más zonas recibe una dirección IP de difusión para todos desde la subred de difusión para todos, una subred externa. Cada zona anuncia la misma dirección IP de difusión a cualquier destino, pero tu red elige la mejor según sus reglas de enrutamiento. Si falla una zona, retira su dirección IP y tu red redirige automáticamente el tráfico a otra zona. Este enrutamiento automático proporciona conectividad sin interrupciones, incluso durante las interrupciones.

Dirección IP privada

Las direcciones IP privadas son direcciones que no se pueden enrutar en Internet. Para obtener una lista de rangos de IPv4 privados, consulta las entradas de los rangos de direcciones IP privadas en la tabla de Rangos IPv4 válidos.

Dirección IP pública

Las direcciones IP públicas son direcciones que se pueden enrutar por Internet. En GDC, las direcciones IP externas pueden ser públicas o privadas. También puedes usar direcciones IPv4 públicas como direcciones internas cuando configuras el rango de direcciones IPv4 principal de una subred en tu red de VPC. Estas direcciones se denominan direcciones IP públicas de uso privado.

Uso y limitaciones de IPv4

Cada red de tu universo de GDC tiene algunas limitaciones de uso del rango de direcciones IPv4 que debes tener en cuenta cuando asignes direcciones IP. Los rangos de direcciones IPv6 no son compatibles con la VPC predeterminada ni con el segmento de red de datos. Comunícate con tu grupo de operadores de infraestructura para conocer las posibilidades de rangos de IPv6 en otras redes.

Limitaciones para todas las subredes IPv4

Estas limitaciones se aplican a las subredes de redes de VPC y a las subredes de segmentos de redes externas.

Todas las subredes deben ser un bloque CIDR válido.
Después de crear una subred, no se puede aumentar su escala, reemplazarla ni reducirla.
GDC no aplica un límite en el tamaño del CIDR que se puede crear. Sin embargo, para la mayoría de los rangos de direcciones IP más grandes que /8, las validaciones adicionales evitan que crees una subred que sea tan grande. Por ejemplo, una subred no puede superponerse con una subred prohibida. Para minimizar la posibilidad de elegir una subred no válida, te recomendamos que limites el tamaño máximo de la subred a /8.
No puedes crear subredes que se superpongan con ninguna subred prohibida, ninguna otra subred en la misma red de VPC, ninguna subred en un segmento de red externa adjunto ni ninguna subred en una red de intercambio de tráfico. Debes trabajar con tu grupo de operadores de infraestructura para asegurarte de no crear subredes superpuestas en estos casos.

Nota: Una red con intercambio de tráfico es cualquier red que intercambia rutas de red entre sí. Esto incluye las redes externas de los clientes, los segmentos de redes externas de las organizaciones en un grupo de interconexión común y las redes de VPC interconectadas. Por ejemplo, la VPC de infraestructura y la VPC predeterminada son redes de intercambio de tráfico entre sí.
GDC crea las rutas correspondientes para las subredes. Las subredes de la red de VPC tienen rutas creadas en la pila de redes virtuales de tu organización, y las subredes del segmento de red externa tienen rutas creadas en la tabla de enrutamiento de tu red externa con intercambio de tráfico.
Verifica que las subredes no entren en conflicto con el direccionamiento IP local si conectaste tu red de VPC a otra red con una VPN administrada o una interconexión compartida o dedicada.
Las subredes no deben coincidir con un rango prohibido, ni ser más estrechas ni más amplias que uno de ellos. Por ejemplo, 169.0.0.0/8 no es una subred válida porque se superpone con el rango de vínculo local 169.254.0.0/16 (RFC 3927), que está restringido.
Las subredes no deben abarcar un rango de RFC, como se describe en Rangos de IPv4 válidos, ni un rango de direcciones IP públicas de uso privado. Por ejemplo, 172.0.0.0/10 no es una subred válida porque incluye el rango de direcciones IP privadas 172.16.0.0/12 y las direcciones IP públicas.
Las subredes no deben abarcar varios rangos de RFC. Por ejemplo, 192.0.0.0/8 no es una subred válida porque incluye 192.168.0.0/16 (RFC 1918) y 192.0.0.0/24 (RFC 6890). Sin embargo, puedes crear dos subredes, una con 192.168.0.0/16 y otra con 192.0.0.0/24.

Rangos de IPv4 válidos

En la siguiente tabla, se describen los rangos válidos.

Rango	Descripción
Rangos de direcciones IPv4 privados
`10.0.0.0/8` `172.16.0.0/12` `192.168.0.0/16`	Direcciones IP privadas de RFC 1918 Para obtener información sobre el uso de `172.17.0.0/16`, consulta Consideraciones adicionales.
`100.64.0.0/10`	Espacio de direcciones compartidas de RFC 6598
`192.0.0.0/24`	Asignaciones de protocolo IETF de 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)	Documentación de RFC 5737
`192.88.99.0/24`	Retransmisión de IPv6 a IPv4 (obsoleta) de RFC 7526
`198.18.0.0/15`	Pruebas comparativas de RFC 2544
`240.0.0.0/4`	Reservado para uso futuro (clase E) como se indica en RFC 5735 y RFC 1112. Algunos sistemas operativos no admiten el uso de este rango, por lo que debes verificar que tu SO lo admita antes de crear subredes que usen este rango.
Rangos de direcciones IP públicas de uso privado
Direcciones IPv4 públicas usadas de forma privada	Direcciones IPv4 públicas usadas de forma privada: Son direcciones IPv4 que se pueden enrutar de forma normal en Internet, pero que se usan de forma privada en una red de VPC. No debe pertenecer a un rango de subred prohibido. La versión aislada de GDC no supone conectividad a Internet. Como resultado, GDC con aislamiento físico anuncia cualquier rango de direcciones IP públicas como si fueran privadas para tu organización. Si las direcciones de trae tu propia IP (BYOIP) que importaste son rangos de direcciones IP públicas, debes verificar que no causen problemas de red en ninguna red externa. Tus direcciones BYOIP no deben superponerse con otras subredes de tu organización.

Subredes IPv4 prohibidas

Entre los rangos de subred prohibidos, se incluyen los rangos de RFC que se suelen reservar y las subredes reservadas de forma global en tu universo de GDC específico, como se describe en la siguiente tabla. Estos rangos no se pueden usar para subredes.

Rango	Descripción
Rango de infraestructura de GDC	Es un CIDR reservado de forma global que usa el sistema de GDC. Si no se especifica este rango para el campo `zone-infra-cidr` del cuestionario de admisión del cliente (CIQ), GDC usa `172.16.0.0/12` como el rango de infraestructura de GDC de forma predeterminada.
Rangos específicos del universo	Son los rangos adicionales reservados por el grupo de operadores de infraestructura.
`0.0.0.0/8`	Red actual (local) de RFC 1122
`127.0.0.0/8`	Host local de RFC 1122
`169.254.0.0/16`	Vínculo local de RFC 3927
`224.0.0.0/4`	Multidifusión (clase D) RFC 5771
`255.255.255.255/32`	Dirección de destino de transmisión limitada de RFC 8190 y RFC 919

Direcciones inutilizables en subredes IPv4

GDC usa las dos primeras y las dos últimas direcciones IPv4 de cada subred para alojarla.

Dirección IPv4 inutilizable	Descripción	Ejemplo
Dirección de red	Primera dirección en el rango IPv4 principal.	`10.1.2.0` del rango `10.1.2.0/24`
Dirección de puerta de enlace predeterminada	Segunda dirección en el rango IPv4 principal.	`10.1.2.1` del rango `10.1.2.0/24`
Penúltima dirección	Es la penúltima dirección en el rango IPv4 principal. Google Cloud reserva este rango para su posible uso en el futuro.	`10.1.2.254` del rango `10.1.2.0/24`
Dirección de broadcast	Es la última dirección en el rango IPv4 principal.	`10.1.2.255` del rango `10.1.2.0/24`

Consideraciones adicionales

Algunos productos de Google y de terceros usan 172.17.0.0/16 para el enrutamiento dentro del sistema operativo invitado. Por ejemplo, la red predeterminada del puente Docker usa este rango. Si dependes de un producto que usa 172.17.0.0/16, no lo uses como ningún rango de direcciones IPv4 de subred.

Permisos de IAM para subredes

Google Distributed Cloud aislado admite un amplio conjunto de permisos de IAM para administrar subredes.

Administrador de la organización de subredes (global): Administra varias subredes de zona dentro de la organización. Pídele al administrador de IAM de la organización que te otorgue el rol de clúster de administrador de subred de la organización (subnet-org-admin).
Administrador de la organización de subredes: Administra las subredes zonales dentro de la organización. Pídele al administrador de IAM de la organización que te otorgue el rol de clúster de administrador de subred de la organización (subnet-org-admin).
Administrador de proyectos de subred (global): Administra varias subredes de zona dentro de los proyectos. Pídele al administrador de IAM de la organización que te otorgue el rol de administrador de proyectos de subred (subnet-project-admin).
Administrador de proyectos de subred: Administra las subredes zonales dentro de los proyectos. Pídele al administrador de IAM de la organización que te otorgue el rol de administrador de proyecto de subred (subnet-project-admin).
- Este rol tiene permiso para leer todas las subredes en el espacio de nombres del proyecto y para crear, actualizar y borrar la mayoría de las subredes en los espacios de nombres del proyecto. Sin embargo, este rol no otorga permiso para crear, actualizar ni borrar las subredes de tipo raíz (subnet.Spec.Type == Root).
Operador de proyectos de subred: Administra las subredes asignadas automáticamente de tipo hoja dentro de los proyectos. Pídele al administrador de IAM de la organización que te otorgue el rol de operador de proyecto de subred (subnet-project-operator).
- Este rol tiene permiso para leer todas las subredes en el espacio de nombres del proyecto y para crear, actualizar o borrar solo las subredes hoja asignadas automáticamente en los espacios de nombres del proyecto. Este rol no otorga permiso para crear, actualizar ni borrar las siguientes subredes:
  - Subredes de tipo raíz o rama (subnet.Spec.Type == raíz || subnet.Spec.Type == rama)
  - Subredes de red (subnet.Spec.NetworkSpec != nil)
  - Subredes con CIDR dedicado (subnet.Spec.Ipv4Request.CIDR != nil || subnet.Spec.Ipv6Request.CIDR != nil)
Subnet Platform Viewer: Obtén subredes en el espacio de nombres platform. Pídele al administrador de IAM de la organización que te otorgue el rol de visualizador de la plataforma de subred (subnet-platform-viewer).
Para usar una subred compartida en el espacio de nombres de la plataforma como principal para asignar una subred dentro del proyecto, pídele a tu administrador de IAM de la organización que te otorgue el rol de shared-subnet-user.
Para otorgar una subred dedicada en el espacio de nombres de la plataforma para que se use como principal y asignar una subred dentro del proyecto, subnet-org-admin debe crear o actualizar una subred y establecer la anotación "ipam.gdc.goog/subnet-delegation-role": auto en ella. Luego, pídele al administrador de IAM de tu organización que le otorgue al usuario el rol de <subnetName>-user.
Para habilitar un grupo de subredes dentro del espacio de nombres de la plataforma para la asignación de subredes internas del proyecto, el subnet-org-admin debe crear o actualizar todas las subredes del grupo. Para cada subred, se debe configurar la anotación "ipam.gdc.goog/subnet-delegation-role": auto. Luego, pídele al administrador de IAM de la organización que otorgue el rol de <subnetName>-user para cada subred del grupo.