Configurar un balanceador de carga de red de paso a través interno como siguiente salto (con etiquetas)

En este tutorial se muestra un ejemplo para explicar cómo desplegar un balanceador de carga de red de pasarela interno como el siguiente salto al que se reenvían los paquetes en la ruta hacia su destino final. Las etiquetas de red se usan para configurar las instancias de cliente específicas a las que se aplica la ruta.

En esta guía se da por hecho que conoces el funcionamiento de un balanceador de carga de red de transferencia interno, sus componentes relacionados (como las reglas de cortafuegos y las comprobaciones del estado) y cómo se usan los balanceadores de carga de red de transferencia internos como siguientes saltos para reenviar paquetes en una ruta.

Con la función de balanceador de carga de red de paso a través interno como siguiente salto, puedes integrar aplicaciones de terceros de forma escalable y con alta disponibilidad. Para ello, debes configurar una ruta estática personalizada y definir el siguiente salto en el balanceador de carga, que distribuirá el tráfico del prefijo de destino al grupo de aplicaciones de VM de terceros con comprobación de estado. Tienes varias opciones al seleccionar los próximos saltos para admitir la alta disponibilidad de estos dispositivos de terceros:

• Especifica una dirección IP como siguiente salto: usa la dirección IP interna asociada a la regla de reenvío como siguiente salto. La dirección IP virtual de este balanceador de carga se puede conocer entre los peers sin tener que exportar la ruta personalizada a través de sus peers.
• Usar etiquetas de red: puede especificar una etiqueta de red para que la ruta de siguiente salto del balanceador de carga de red interno de transferencia solo se aplique a las instancias de cliente que se hayan configurado con la etiqueta. De esta forma, puedes seleccionar qué instancias de cliente se rellenan con qué balanceador de carga de red con paso a través interno etiquetado como ruta del siguiente salto y a qué conjunto de dispositivos se dirige el tráfico. No es necesario que separen las diferentes instancias de cliente en VPCs independientes, cada una de las cuales apunta a su balanceador de carga de red interno de tipo pasarela preferido que se encuentra delante de un conjunto de dispositivos. Las rutas etiquetadas no se exportan ni se importan mediante el emparejamiento entre redes de VPC.
• Configurar varias rutas al mismo prefijo de destino: con etiquetas, puede especificar varias rutas al mismo destino con diferentes balanceadores de carga internos como saltos siguientes. Aunque no se admite ECMP (mismo prefijo de destino, mismas etiquetas y diferentes saltos siguientes), puede usar diferentes etiquetas o prioridades para estas mismas rutas de destino.

Descripción general de la configuración

Los grupos de instancias gestionados que usan máquinas virtuales con una sola NIC se definen en regiones diferentes, con instancias de Linux configuradas para traducir con SNAT todo el tráfico saliente a Internet (flujo de tráfico saliente de norte a sur). La conmutación por error regional se activa manualmente. En este tutorial también se muestra la conectividad este-oeste con el hash simétrico mediante un balanceador de carga de red pasarela interno como salto siguiente.

En los pasos de esta sección se describe cómo configurar lo siguiente:

1. Redes de VPC de ejemplo con subredes personalizadas
2. Reglas de cortafuegos que permiten las conexiones entrantes a las VMs de backend
3. Grupos de instancias gestionados de backend que despliegan pasarelas NAT
4. Máquinas virtuales cliente para probar las conexiones
5. Los siguientes componentes del balanceador de carga de red de paso a través interno:
   • Una comprobación del estado del servicio de backend
   • Un servicio de backend interno
   • Una regla de reenvío interna y una dirección IP para el frontend del balanceador de carga

La arquitectura de este ejemplo es la siguiente:

Configuración del balanceador de carga de red de paso a través interno como siguiente salto (haz clic en la imagen para ampliarla)

A medida que sigas los pasos de este tutorial, sustituye REGION_A y REGION_B por las regiones que quieras usar en este ejemplo.

Crear las redes y subredes de VPC

1. Crea una red de VPC llamada hub-vpc.

   gcloud compute networks create hub-vpc --subnet-mode custom
   

2. Crea una subred en hub-vpc en REGION_A.

   gcloud compute networks subnets create hub-subnet-a \
       --network hub-vpc \
       --range 10.0.0.0/24 \
       --region REGION_A
   

3. Crea una subred en hub-vpc en region B.

   gcloud compute networks subnets create hub-subnet-b \
       --network hub-vpc \
       --range 10.0.1.0/24 \
       --region REGION_B
   

4. Crea una red de VPC llamada spoke1-vpc.

   gcloud compute networks create spoke1-vpc --subnet-mode custom
   

5. Crea una subred en spoke1-vpc.

   gcloud compute networks subnets create spoke1-subnet1 \
       --network spoke1-vpc \
       --range 192.168.0.0/24 \
       --region REGION_A
   

6. Crea una red de VPC llamada spoke2-vpc.

   gcloud compute networks create spoke2-vpc --subnet-mode custom
   

7. Crea una subred en spoke2-vpc.

   gcloud compute networks subnets create spoke2-subnet1 \
       --network spoke2-vpc \
       --range 192.168.1.0/24 \
       --region REGION_A
   

Configurar reglas de cortafuegos

1. Configura las siguientes reglas de cortafuegos para permitir que el tráfico TCP, UDP e ICMP llegue a las instancias desde los intervalos de origen especificados.

   gcloud compute firewall-rules create hub-vpc-web-ping-dns \
       --network hub-vpc \
       --allow tcp:80,tcp:443,icmp,udp:53 \
       --source-ranges 10.0.0.0/24,10.0.1.0/24,192.168.0.0/24,192.168.1.0/24
   

   gcloud compute firewall-rules create spoke1-vpc-web-ping-dns \
       --network spoke1-vpc \
       --allow tcp:80,tcp:443,icmp,udp:53 \
       --source-ranges 10.0.0.0/24,10.0.1.0/24,192.168.0.0/24,192.168.1.0/24
   

   gcloud compute firewall-rules create spoke2-vpc-web-ping-dns \
       --network spoke2-vpc \
       --allow tcp:80,tcp:443,icmp,udp:53 \
       --source-ranges 10.0.0.0/24,10.0.1.0/24,192.168.0.0/24,192.168.1.0/24
   

2. Crea una regla de cortafuegos para permitir que los verificadores de comprobación del estado accedan a las instancias en hub-vpc.

   gcloud compute firewall-rules create hub-vpc-health-checks \
       --network hub-vpc \
       --allow tcp:80 \
       --target-tags natgw \
       --source-ranges 130.211.0.0/22,35.191.0.0/16
   

3. Crea reglas de cortafuegos para permitir el acceso SSH a las instancias de todas las subredes. Si prefieres usar Identity-Aware Proxy para el reenvío de TCP (opción recomendada), sigue estos pasos para habilitar SSH.

   gcloud compute firewall-rules create hub-vpc-allow-ssh \
       --network hub-vpc \
       --allow tcp:22
   

   gcloud compute firewall-rules create spoke1-vpc-allow-ssh \
       --network spoke1-vpc \
       --allow tcp:22
   

   gcloud compute firewall-rules create spoke2-vpc-allow-ssh \
       --network spoke2-vpc \
       --allow tcp:22
   

Configurar el emparejamiento entre redes de VPC

1. Crea un intercambio de tráfico entre hub-vpc y spoke1-vpc.

   gcloud compute networks peerings create hub-to-spoke1 \
       --network hub-vpc \
       --peer-network spoke1-vpc \
       --peer-project PROJECT_ID \
       --export-custom-routes
       

2. Crea un intercambio de tráfico entre spoke1-vpc y hub-vpc.

   gcloud compute networks peerings create spoke1-to-hub \
       --network spoke1-vpc \
       --peer-network hub-vpc \
       --peer-project PROJECT_ID \
       --import-custom-routes
   

3. Crea un intercambio de tráfico entre hub-vpc y spoke2-vpc.

   gcloud compute networks peerings create hub-to-spoke2 \
       --network hub-vpc \
       --peer-network spoke2-vpc \
       --peer-project PROJECT_ID \
       --export-custom-routes
   

4. Crea un intercambio de tráfico entre spoke2-vpc y hub-vpc.

   gcloud compute networks peerings create spoke2-to-hub \
       --network spoke2-vpc \
       --peer-network hub-vpc \
       --peer-project PROJECT_ID \
       --import-custom-routes
   

Crear VMs de pasarela NAT y recursos de balanceo de carga en la región A

Crea el backend del grupo de instancias gestionado en REGION_A. A continuación, cree los recursos de balanceo de carga y las rutas de siguiente salto.

Crear un grupo de instancias gestionado

1. Crea una plantilla de instancia para desplegar una pasarela NAT en region A.

   gcloud compute instance-templates create hub-natgw-region-a-template \
       --network hub-vpc \
       --subnet hub-subnet-a \
       --region REGION_A \
       --machine-type n1-standard-2 \
       --can-ip-forward \
       --tags natgw \
       --metadata startup-script='#! /bin/bash
   # Enable IP forwarding:
   echo 1 > /proc/sys/net/ipv4/ip_forward
   echo "net.ipv4.ip_forward=1" > /etc/sysctl.d/20-iptables.conf
   # iptables configuration
   iptables -t nat -F
   sudo iptables -t nat -A POSTROUTING ! -d 192.168.0.0/16 -j MASQUERADE
   iptables-save
   # Use a web server to pass the health check for this example.
   # You should use a more complete test in production.
   apt-get update
   apt-get install apache2 tcpdump -y
   a2ensite default-ssl
   a2enmod ssl
   echo "Example web page to pass health check" | \
   tee /var/www/html/index.html \
   systemctl restart apache2'
   

2. Crea el grupo de instancias en REGION_A.

   gcloud compute instance-groups managed create hub-natgw-region-a-mig \
       --region REGION_A \
       --size=2 \
       --template=hub-natgw-region-a-template
   

Crear el balanceador de carga

Sigue estos pasos para crear un balanceador de carga en REGION_A.

1. Crea una comprobación del estado.

   gcloud compute health-checks create http natgw-ilbnhop-health-check \
       --port=80
   

2. Crea el servicio de backend.

   gcloud compute backend-services create hub-natgw-region-a-be \
       --load-balancing-scheme=internal \
       --protocol tcp \
       --region REGION_A\
       --health-checks=natgw-ilbnhop-health-check
   

3. Añade el grupo de instancias gestionado como backend.

   gcloud compute backend-services add-backend hub-natgw-region-a-be \
       --instance-group=hub-natgw-region-a-mig \
       --instance-group-region=REGION_A
   

4. Crea la regla de reenvío.

   gcloud compute forwarding-rules create hub-natgw-region-a \
       --load-balancing-scheme=internal \
       --network=hub-vpc \
       --subnet=hub-subnet-a \
       --address=10.0.0.10 \
       --ip-protocol=TCP \
       --ports=all \
       --allow-global-access \
       --backend-service=hub-natgw-region-a-be \
       --backend-service-region=REGION_A
   

Crea las rutas de siguiente salto

Crea el balanceador de carga de red de paso a través interno como rutas de siguiente salto con la etiqueta de red predefinida ilbanh-region-a.

gcloud compute routes create spoke1-natgw-region-a \
    --network=spoke1-vpc \
    --destination-range=0.0.0.0/0 \
    --next-hop-ilb=10.0.0.10 \
    --tags=ilbanh-region-a \
    --priority 800

gcloud compute routes create spoke2-natgw-region-a \
    --network=spoke2-vpc \
    --destination-range=0.0.0.0/0 \
    --next-hop-ilb=10.0.0.10 \
    --tags=ilbanh-region-a \
    --priority 800

Probar la conectividad

Crea instancias de cliente para probar la conectividad.

1. Crea una instancia de cliente de prueba en spoke1-vpc.

   gcloud compute instances create spoke1-client \
       --subnet=spoke1-subnet1 --no-address --zone ZONE_A \
       --tags=ilbanh-region-a \
       --metadata startup-script='#! /bin/bash
   apt-get update
   apt-get install tcpdump -y'
   

2. Crea una instancia de cliente de prueba en spoke2-vpc.

   gcloud compute instances create spoke2-client \
       --subnet=spoke2-subnet1 --no-address --zone ZONE_A \
       --tags=ilbanh-region-a \
       --metadata startup-script='#! /bin/bash
   apt-get update
   apt-get install tcpdump -y'
   

Validar los flujos de tráfico norte-sur y este-oeste

1. Asegúrate de que las VMs de la pasarela NAT estén en ejecución y anota las direcciones IP externas asignadas:

   gcloud compute instances list --filter="status:RUNNING AND name~natgw"
   

2. Confirma que el balanceador de carga está en buen estado y que las rutas se han creado como se esperaba:

   gcloud compute backend-services get-health hub-natgw-region-a-be --region REGION_A
   

   backend: https://www.googleapis.com/compute/v1/projects/<PROJECT_ID>/regions/us-central1/instanceGroups/hub-natgw-region-a-mig
   status:
     healthStatus:
     - forwardingRule: https://www.googleapis.com/compute/v1/projects/<PROJECT_ID>/regions/us-central1/forwardingRules/hub-natgw-region-a
       forwardingRuleIp: 10.0.0.10
       healthState: HEALTHY
       instance: https://www.googleapis.com/compute/v1/projects/<PROJECT_ID>/zones/us-central1-b/instances/<INSTANCE_NAME>
       ipAddress: 10.0.0.5
       port: 80
     - forwardingRule: https://www.googleapis.com/compute/v1/projects/<PROJECT_ID>/regions/us-central1/forwardingRules/hub-natgw-region-a
       forwardingRuleIp: 10.0.0.10
       healthState: HEALTHY
       instance: https://www.googleapis.com/compute/v1/projects/<PROJECT_ID>/zones/us-central1-f/instances/<INSTANCE_NAME>
       ipAddress: 10.0.0.6
       port: 80
     kind: compute#backendServiceGroupHealth
   

3. Verifica que los balanceadores de carga de red de paso a través internos como rutas de siguiente salto se hayan añadido a las VPCs de spoke con la prioridad esperada y que estén orientados a la dirección IP del balanceador de carga de red de paso a través interno:

   gcloud compute routes list --filter="name~natgw"
   

4. Ve a la Google Cloud consola y establece conexiones SSH con las VMs de la puerta de enlace NAT en diferentes pestañas.

5. Inicia tcpdump en cada una de esas sesiones SSH con el siguiente comando:

   sudo tcpdump -n net 192.168.0.0/16
   

6. Ve a la Google Cloud consola y establece una nueva conexión SSH con la máquina virtual spoke1-client. A continuación, usa el siguiente comando para hacer ping a la spoke2-client dirección IP interna.

   ping SPOKE2_CLIENT_INTERNAL_IP
   

7. Cambia a las ventanas SSH de la puerta de enlace NAT y comprueba que puedes ver los paquetes ICMP de la siguiente manera:

   16:51:28.411260 IP 192.168.0.2 > 192.168.1.2: ICMP echo request, id 1684, seq 492, length 64
   16:51:28.411676 IP 192.168.1.2 > 192.168.0.2: ICMP echo reply, id 1684, seq 492, length 64
   

   Deberías poder hacer ping a la VM del cliente, lo que demuestra lo siguiente:

   • El tráfico este-oeste se habilita a través de las pasarelas de NAT. Ten en cuenta que no se admite el peering transitivo entre VPCs de radio.
   • El hash simétrico está habilitado y funciona correctamente, ya que los clientes pueden comunicarse mediante sus direcciones IP de origen sin necesidad de traducción SNAT.
   • Todos los protocolos se admiten con el balanceador de carga de red de paso a través interno como próximo salto.

8. Detén las salidas de tcpdump en las VMs de NAT Gateway y consulta las estadísticas de iptables:

   watch sudo iptables -t nat -nvL
   

9. Vuelve a la máquina virtual spoke1-client y ejecuta el siguiente comando varias veces. En la salida se muestra la dirección IP de origen pública que se usa para conectarse al sitio web.

   curl ifconfig.io
   

   Deberías ver las direcciones IP de ambas VMs de pasarela NAT como direcciones IP de origen. Esto demuestra que el balanceador de carga de red de paso a través interno distribuye el tráfico en función de la afinidad predeterminada (hash de 5 tuplas).

10. Vuelve a la VM de la puerta de enlace NAT para confirmar que los contadores de paquetes han aumentado.

    Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
     pkts bytes target     prot opt in     out     source               destination
    
    Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
     pkts bytes target     prot opt in     out     source               destination
    
    Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
     pkts bytes target     prot opt in     out     source               destination
      105 11442 MASQUERADE  all  --  *      *       0.0.0.0/0           !192.168.0.0/16
    
    Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
     pkts bytes target     prot opt in     out     source               destination
    

Crear VMs de pasarela NAT y recursos de balanceo de carga en la región B

Crea el backend del grupo de instancias gestionado en region B. A continuación, cree los recursos de balanceo de carga y las rutas de siguiente salto.

Crear un grupo de instancias gestionado

1. Crea una plantilla de instancia para desplegar una pasarela NAT en region B.

   gcloud compute instance-templates create hub-natgw-region-b-template \
       --network hub-vpc \
       --subnet hub-subnet-b --region REGION_B \
       --machine-type n1-standard-2 --can-ip-forward \
       --tags natgw \
       --metadata startup-script='#! /bin/bash
   # Enable IP forwarding:
   echo 1 > /proc/sys/net/ipv4/ip_forward
   echo "net.ipv4.ip_forward=1" > /etc/sysctl.d/20-iptables.conf
   # iptables configuration
   iptables -t nat -F
   sudo iptables -t nat -A POSTROUTING ! -d 192.168.0.0/16 -j MASQUERADE
   iptables-save
   # Use a web server to pass the health check for this example.
   # You should use a more complete test in production.
   apt-get update
   apt-get install apache2 tcpdump -y
   a2ensite default-ssl
   a2enmod ssl
   echo "Example web page to pass health check" | \
   tee /var/www/html/index.html \
   systemctl restart apache2'
   

2. Crea el grupo de instancias en region B.

   gcloud compute instance-groups managed create hub-natgw-region-b-mig \
       --region REGION_B \
       --size=2 \
       --template=hub-natgw-region-b-template
   

Crear el balanceador de carga

Sigue estos pasos para crear un balanceador de carga en la región B.

1. Crea el servicio de backend.

   gcloud compute backend-services create hub-natgw-region-b-be \
       --load-balancing-scheme=internal \
       --protocol tcp \
       --region REGION_B\
       --health-checks=natgw-ilbnhop-health-check
   

2. Añade el grupo de instancias gestionado como backend.

   gcloud compute backend-services add-backend hub-natgw-region-b-be \
       --instance-group=hub-natgw-region-b-mig \
       --instance-group-region=REGION_B
   

3. Crea la regla de reenvío.

   gcloud compute forwarding-rules create hub-natgw-region-b \
       --load-balancing-scheme=internal \
       --network=hub-vpc \
       --subnet=hub-subnet-b \
       --address=10.0.1.10 \
       --ip-protocol=TCP \
       --ports=all \
       --allow-global-access \
       --backend-service=hub-natgw-region-b-be \
       --backend-service-region=REGION_B
   

Crea las rutas de siguiente salto

Crea el balanceador de carga de red de paso a través interno como rutas de siguiente salto con la etiqueta de red predefinida ilbanh-region-a.

gcloud compute routes create spoke1-natgw-region-b \
    --network=spoke1-vpc \
    --destination-range=0.0.0.0/0 \
    --next-hop-ilb=10.0.1.10 \
    --tags=ilbanh-region-a \
    --priority 900

gcloud compute routes create spoke2-natgw-region-b \
    --network=spoke2-vpc \
    --destination-range=0.0.0.0/0 \
    --next-hop-ilb=10.0.1.10 \
    --tags=ilbanh-region-a \
    --priority 900

Validar la conmutación por error regional

1. Asegúrate de que las VMs de la pasarela NAT estén en ejecución y anota las IPs externas asignadas:

   gcloud compute instances list --filter="status:RUNNING AND name~natgw"
   

2. Confirma que el balanceador de carga está en buen estado y que las rutas se han creado correctamente:

   gcloud compute backend-services get-health hub-natgw-region-b-be --region REGION_B
   

   backend: https://www.googleapis.com/compute/v1/projects/<PROJECT_ID>/regions/us-west2/instanceGroups/hub-natgw-region-b-mig
   status:
     healthStatus:
     - forwardingRule: https://www.googleapis.com/compute/v1/projects/<PROJECT_ID>/regions/us-west2/forwardingRules/hub-natgw-region-b
       forwardingRuleIp: 10.0.1.10
       healthState: HEALTHY
       instance: https://www.googleapis.com/compute/v1/projects/<PROJECT_ID>/zones/us-west2-a/instances/<INSTANCE_NAME>
       ipAddress: 10.0.1.3
       port: 80
     - forwardingRule: https://www.googleapis.com/compute/v1/projects/<PROJECT_ID>/regions/us-west2/forwardingRules/hub-natgw-region-b
       forwardingRuleIp: 10.0.1.10
       healthState: HEALTHY
       instance: https://www.googleapis.com/compute/v1/projects/<PROJECT_ID>/zones/us-west2-b/instances/<INSTANCE_NAME>
       ipAddress: 10.0.1.2
       port: 80
     kind: compute#backendServiceGroupHealth
   

3. Verifica que los balanceadores de carga de red de paso a través internos como rutas de siguiente salto se hayan añadido a las VPCs de spoke con la prioridad esperada y que estén orientados a la dirección IP del balanceador de carga de red de paso a través interno:

   gcloud compute routes list --filter="name~natgw"
   

4. Ahora puede validar la conmutación por error regional eliminando las rutas de alta prioridad y tomando nota de lo que ocurre. Cambia a la VM spoke1-client y ejecuta el siguiente comando para enviar una solicitud curl cada segundo. Este comando también indica la dirección IP externa que se está usando:

   while true; do echo -n `date` && echo -n ' - ' && curl ifconfig.io --connect-timeout 1; done
   

   Solo se deben mostrar las direcciones IP externas asignadas a las pasarelas de NAT en region A, ya que es la ruta de alta prioridad. Deja el comando curl en ejecución y cambia a Cloud Shell para eliminar la ruta al balanceador de carga de red de paso a través interno en region A y verificar el resultado:

   gcloud -q compute routes delete spoke1-natgw-region-a
   

   En region B, aparecen las direcciones IP externas asignadas a las VMs de la pasarela de NAT, probablemente con un tiempo de inactividad mínimo, lo que demuestra que la conmutación por error regional se ha realizado correctamente.

Nota: Una ruta no se elimina automáticamente aunque todos los back-ends no estén en buen estado. Puedes usar Cloud Run Functions para automatizar este proceso.

Eliminar los recursos

1. Quita el balanceador de carga de red de paso a través interno como ruta de siguiente salto:

   gcloud -q compute routes delete spoke1-natgw-region-b
   
   gcloud -q compute routes delete spoke2-natgw-region-a
   
   gcloud -q compute routes delete spoke2-natgw-region-b
   

2. Elimina los recursos y los backends del balanceador de carga de red de paso a través interno:

   gcloud -q compute forwarding-rules delete hub-natgw-region-a \
     --region REGION_A
   
   gcloud -q compute backend-services delete hub-natgw-region-a-be \
     --region REGION_A
   
   gcloud -q compute instance-groups managed delete hub-natgw-region-a-mig \
     --region REGION_A
   
   gcloud -q compute instance-templates delete hub-natgw-region-a-template
   
   gcloud -q compute forwarding-rules delete hub-natgw-region-b \
     --region REGION_B
   
   gcloud -q compute backend-services delete hub-natgw-region-b-be \
     --region REGION_B
   
   gcloud -q compute instance-groups managed delete hub-natgw-region-b-mig \
     --region REGION_B
   
   gcloud -q compute instance-templates delete hub-natgw-region-b-template
   
   gcloud -q compute health-checks delete natgw-ilbnhop-health-check
   

3. Elimina las VMs del cliente:

   gcloud -q compute instances delete spoke1-client \
     --zone=ZONE_A
   
   gcloud -q compute instances delete spoke2-client \
     --zone=ZONE_A
   

4. Elimina los emparejamientos de redes de VPC, las reglas de cortafuegos, las subredes y las VPCs:

   gcloud -q compute networks peerings delete spoke2-to-hub \
     --network spoke2-vpc
   
   gcloud -q compute networks peerings delete spoke1-to-hub \
     --network spoke1-vpc
   
   gcloud -q compute networks peerings delete hub-to-spoke1 \
     --network hub-vpc
   
   gcloud -q compute networks peerings delete hub-to-spoke2 \
     --network hub-vpc
   
   gcloud -q compute firewall-rules delete spoke2-vpc-web-ping-dns
   
   gcloud -q compute firewall-rules delete spoke1-vpc-web-ping-dns
   
   gcloud -q compute firewall-rules delete hub-vpc-web-ping-dns
   
   gcloud -q compute firewall-rules delete hub-vpc-health-checks
   
   gcloud -q compute firewall-rules delete hub-vpc-allow-ssh
   
   gcloud -q compute firewall-rules delete spoke1-vpc-allow-ssh
   
   gcloud -q compute firewall-rules delete spoke2-vpc-allow-ssh
   
   gcloud -q compute networks subnets delete spoke1-subnet1 \
     --region REGION_A
   
   gcloud -q compute networks subnets delete spoke2-subnet1 \
     --region REGION_A
   
   gcloud -q compute networks subnets delete hub-subnet-a \
     --region REGION_A
   
   gcloud -q compute networks subnets delete hub-subnet-b \
     --region REGION_B
   
   gcloud -q compute networks delete spoke1-vpc
   
   gcloud -q compute networks delete spoke2-vpc
   
   gcloud -q compute networks delete hub-vpc
   

Siguientes pasos

• Consulta Conceptos de conmutación por error para los balanceadores de carga de red de paso a través internos para obtener información importante sobre la conmutación por error.
• Consulta Registro y monitorización del balanceador de carga de red de paso a través interno para obtener información sobre cómo configurar el registro y la monitorización del balanceador de carga de red de paso a través interno.
• Consulta Balanceadores de carga de red de paso a través internos y redes conectadas para obtener información sobre cómo acceder a balanceadores de carga de red de paso a través internos desde redes peer conectadas a tu red de VPC.
• Consulta el artículo Solucionar problemas de balanceadores de carga de red de paso a través internos para obtener información sobre cómo solucionar problemas con tu balanceador de carga de red de paso a través interno.