Información general sobre la administración de spokes

En esta página se ofrece una descripción general desde la perspectiva de un administrador de una nube privada virtual (VPC) de tipo spoke.

Si el hub de Network Connectivity Center y la VPC de spoke están en el mismo proyecto, los administradores de la VPC de spoke deben tener las dos vinculaciones de Gestión de Identidades y Accesos (IAM) siguientes en ese proyecto:

• El rol Administrador de red de Compute (roles/compute.networkAdmin).

• El rol de administrador de spoke de Network Connectivity Center (roles/networkconnectivity.spokeAdmin).

Si el hub de Network Connectivity Center y la VPC de spoke están en proyectos diferentes, las políticas de IAM deben tener los siguientes enlaces.

• Los administradores de VPC de tipo spoke deben tener los dos enlaces de IAM siguientes en el proyecto que contiene la red de VPC (spoke):

  • El rol Administrador de red de Compute (roles/compute.networkAdmin).
  • El rol de administrador de spoke de Network Connectivity Center (roles/networkconnectivity.spokeAdmin).

• Los administradores de radios de VPC también deben tener los dos enlaces de IAM siguientes en el hub de Network Connectivity Center o en el proyecto que contiene el hub de Network Connectivity Center:

  • El rol de usuario de grupo de Network Connectivity Center (roles/networkconnectivity.groupUser).
  • El rol Visor de Hub y Spoke de Network Connectivity Center (roles/networkconnectivity.hubViewer).

También puedes usar roles personalizados, siempre que incluyan los mismos permisos que los roles predefinidos que se han indicado anteriormente.

Cuando una red de VPC y el hub de Network Connectivity Center se encuentran en proyectos diferentes, un administrador de un spoke de VPC debe crear una propuesta de spoke para solicitar que una red de VPC se una al hub. Un administrador del centro revisa la propuesta. Si el administrador del centro de conectividad acepta la propuesta, la red de VPC se conectará al centro de conectividad. Un administrador de centro también puede rechazar propuestas de radios. Los administradores de spokes pueden consultar el estado de una propuesta de spoke de VPC en cualquier momento.

Puedes proponer actualizaciones a una VPC de spoke para cambiar el conjunto de intervalos de subredes que se exportan a las tablas de rutas de la VPC de centro de conectividad.

Para obtener más información, consulta las siguientes secciones.

• Proponer una VPC de spoke en otro proyecto
• Consultar el estado de una VPC de radio
• Ver la tabla de rutas de la VPC
• Descripción general de las VPCs de radio
• Cambiar los intervalos de direcciones de subred exportados (Vista previa)

Unicidad de la ruta de subred

Al igual que el emparejamiento entre redes de VPC, Google Cloud prohíbe los conflictos de intervalos de direcciones IP de subredes entre los radios de VPC conectados a un hub de Network Connectivity Center. Un intervalo de direcciones IP de subred entra en conflicto con otro intervalo de direcciones IP de subred cuando se cumple una de las siguientes condiciones:

• Un intervalo de direcciones IP de subred de una red de VPC coincide exactamente con un intervalo de direcciones IP de subred de otra red de VPC.
• Un intervalo de direcciones IP de subred de una red de VPC se ajusta a un intervalo de direcciones IP de subred de otra red de VPC.
• Un intervalo de direcciones IP de subred de una red VPC contiene un intervalo de direcciones IP de subred de otra red VPC.

Los radios de VPC no pueden exportar intervalos de direcciones IP de subred en conflicto al mismo hub de Network Connectivity Center. Puede usar la exclude-export-ranges marca en la CLI de Google Cloud o el campo excludeExportRanges en la API para evitar que se comparta un intervalo de direcciones IP de una subred desde una VPC de radio a un centro de conectividad de red. Por ejemplo, supongamos que tienes dos redes de VPC que quieres conectar al mismo hub de Network Connectivity Center:

• La primera red de VPC tiene una subred cuyo intervalo de direcciones IPv4 interno principal es 100.64.0.0/16, lo que da como resultado una ruta de subred para 100.64.0.0/16.
• La segunda red de VPC tiene una subred con un intervalo de direcciones IPv4 internas secundarias de 100.64.0.0/24, lo que da como resultado una ruta de subred para 100.64.0.0/24.

Las dos rutas de subred tienen intervalos de direcciones IP de subred en conflicto porque 100.64.0.0/24 se ajusta a 100.64.0.0/16. No puedes conectar ambas redes como radios de VPC al mismo hub de Network Connectivity Center a menos que resuelvas el conflicto. Puedes usar una de las siguientes estrategias para resolver el conflicto:

• Excluye el intervalo de direcciones IP 100.64.0.0/16 cuando conectes la primera red de VPC al centro de conectividad o excluye el intervalo de direcciones IP 100.64.0.0/24 cuando conectes la segunda red de VPC al centro de conectividad.
• Excluye 100.64.0.0/16 o todo el espacio RFC 6598, 100.64.0.0/10, al adjuntar cada red de VPC.

Interacción con las rutas de subred de emparejamiento entre redes de VPC

Las rutas de subred de emparejamiento son las que se intercambian entre las redes de VPC conectadas mediante el emparejamiento entre redes de VPC. Aunque las rutas de subred de emparejamiento nunca se intercambian entre los spokes de VPC conectados a un hub de Network Connectivity Center, debes tenerlas en cuenta. Desde el punto de vista de cada VPC de radio, no puede haber conflictos entre las rutas de subred locales, las rutas de subred de emparejamiento importadas y las rutas de subred de Network Connectivity Center importadas.

Para ilustrar este concepto, veamos la siguiente configuración:

• La red de VPC net-a es un radio de VPC conectado a un hub de Network Connectivity Center.
• La red de VPC net-b es un radio de VPC conectado al mismo hub de Network Connectivity Center.
• Las redes de VPC net-b y net-c están conectadas entre sí mediante el emparejamiento entre redes de VPC.

Supongamos que existe un intervalo de direcciones IP de subred local para 100.64.0.0/24 en net-c. De esta forma, se crea una ruta de subred local en net-c y una ruta de subred de emparejamiento en net-b. Aunque la ruta de subred de peering del intervalo de direcciones IP 100.64.0.0/24 no se exporta al centro de conectividad de red, su existencia en net-b impide que net-b pueda importar una ruta del centro de conectividad de red cuyo destino coincida exactamente con 100.64.0.0/24, se ajuste a 100.64.0.0/24 o contenga 100.64.0.0/24. Por lo tanto, no puede haber subredes locales para 100.64.0.0/24, 100.64.0.0/25 ni 100.64.0.0/16 en net-a a menos que configure net-a para que no exporte el intervalo en conflicto.

Tablas de rutas que muestran las rutas de las subredes

Google Cloud muestra las rutas de subred de Network Connectivity Center importadas de los radios de VPC en dos tablas de rutas:

• La tabla de rutas del centro de conectividad de red.
• La tabla de rutas de la red de VPC de cada red de VPC (de radio).

Google Cloud actualiza automáticamente la tabla de rutas de la red de VPC de cada radio de VPC y la tabla de rutas del hub de Network Connectivity Center cuando se cumple una de las siguientes condiciones:

• Cuando realizas una actividad del ciclo de vida de una ruta de subred, como añadir o eliminar una subred.
• Cuando se añaden o se quitan VPCs de radio del centro de conectividad.

En las tablas de rutas de la red de VPC, cada ruta importada de otros radios de VPC aparece como una ruta de subred de Network Connectivity Center cuya siguiente parada es el hub de Network Connectivity Center. Estas rutas de subred de Network Connectivity Center tienen nombres que empiezan por el prefijo ncc-subnet-route-. Para ver el siguiente salto real de una ruta de subred de Network Connectivity Center importada, puedes consultar la tabla de rutas del hub de Network Connectivity Center o consultar la tabla de rutas de la red de VPC de la VPC de radio que exporta la ruta de subred al hub de Network Connectivity Center.

Para obtener más información sobre las rutas de VPC, consulta el artículo Rutas de la documentación de VPC.

Siguientes pasos

• Para crear ejes y radios, consulta Trabajar con ejes y radios.
• Para crear un radio en un proyecto distinto del del eje, consulta Proponer un radio de VPC en otro proyecto.
• Para ver una lista de los partners cuyas soluciones están integradas con Network Connectivity Center, consulta Partners de Network Connectivity Center.
• Para encontrar soluciones a problemas habituales, consulta la sección Solución de problemas.
• Para obtener información sobre los comandos de la API y gcloud, consulta APIs and reference (APIs y referencia).