En esta página se describe la configuración necesaria que debe realizar en las zonas de una implementación multizona cuando se une una nueva zona a la implementación. Esta configuración te permite establecer conexiones con la nueva zona.
1. Antes de empezar
Para configurar la interconexión multizona en Google Distributed Cloud (GDC) con air gap, debes tener lo siguiente:
- Un archivo kubeconfig generado y una variable de entorno. Para obtener más información, consulta el runbook IAM-R0004.
- Un operador de infraestructura (IO) con acceso temporal al clúster de administrador raíz. Para obtener más información, consulta el runbook IAM-R0005.
2. Configurar una interconexión multizona
Configura un recurso
MultiZoneNetworkConfigen cada zona del despliegue multizona:Busca el clúster correcto con el que interactuar. Si el clúster de administrador raíz está en ejecución, usa el
kubeconfigdel clúster de administrador raíz. De lo contrario, usakubeconfigpara el clúster de tipo bootstrap. Para obtener más información, consulta el runbook IAM-R0004. Rellena la ruta de kubeconfig aquí:KUBECONFIG=KUBECONFIG_PATHCrea un archivo YAML llamado
multizone_network_config.yaml.Añade el siguiente contenido al archivo:
apiVersion: system.private.gdc.goog/v1alpha1 kind: MultiZoneNetworkConfig metadata: name: multizone-network-config namespace: gpc-system spec: carrierType: CARRIER_TYPE zones: - zoneID: ZONE_1_ID asn: ZONE_1_ASN externalSubnets: - METERING_SUBNET_1 - zoneID: ZONE_2_ID asn: ZONE_2_ASN externalSubnets: - METERING_SUBNET_2 ports: - port: PORT_1 - port: PORT_2 portSetting: mtu: MTUHaz los cambios siguientes:
CARRIER_TYPE: el tipo de operador troncal multizona. Debe serL2oL3.ZONE_1_ID: ID de la primera zona de la región de GDC.ZONE_1_ASN: número de sistema autónomo (ASN) de BGP de la red de datos de la primera zona de la región de GDC.METERING_SUBNET_1: la subred medida de esta zona. Este campo debe rellenarse con la subred del recursozone-infra-cidrCIDRClaimdel clúster de administrador raíz de la zona asociada. Este campo solo se usa para la medición y no tiene ningún efecto en el control de la publicidad de la subred. Debe mantener este campo sincronizado con las subredes reales que se anuncian. Si no se especifica este campo, no se medirá el tráfico de esta zona.ZONE_2_ID: ID de la segunda zona de la región de GDC.ZONE_2_ASN: el ASN de BGP de la red de datos de la segunda zona de la región del GDC.METERING_SUBNET_2: la subred medida de esta zona. Este campo debe rellenarse con la subred del recursozone-infra-cidrCIDRClaimdel clúster de administrador raíz de la zona asociada. Este campo solo se usa para la medición y no tiene ningún efecto en el control de la publicidad de la subred. Debe mantener este campo sincronizado con las subredes reales que se anuncian. Si no se especifica este campo, no se medirá el tráfico de esta zona.PORT_1: el primer puerto que participa en la interconexión multizona. Para obtener más información, consulta Configurar los puertos.PORT_2: el segundo puerto que participa en la interconexión multizona . Para obtener más información, consulta Configurar los puertos.MTU: valor de MTU aplicado a todos los puertos. Si no se especifica, el valor predeterminado es 9216.
Consulta Ejemplos de configuración multizona para ver ejemplos de implementaciones habituales.
Aplica el archivo
multizone_network_config.yamlal clúster:kubectl apply -f multizone_network_config.yaml --kubeconfig=KUBECONFIG_PATHComprueba que el recurso
MultiZonetNetworkConfigse haya creado correctamente:kubectl get multizonenetworkconfig -n gpc-system --kubeconfig=KUBECONFIG_PATHEn el siguiente ejemplo se muestra un resultado con enlaces de interconexión:
NAME AGE READY multizone-network-config 26h TrueOpcional: Consulta el recurso
MultiZoneNetworkPeeringConfigpara ver la configuración y el estado de BGP de la interconexión.El reconciliador de red define la configuración de BGP real y la almacena en el recurso
MultiZoneNetworkPeeringConfig. Cada recursoMultiZoneNetworkPeeringConfigrepresenta todas las configuraciones de BGP de una zona a otra. Por ejemplo:- Un recurso
MultiZoneNetworkPeeringConfigllamadozone-1-zone-2-peering-configpodría tener el siguiente aspecto:
apiVersion: system.private.gdc.goog/v1alpha1 kind: MultiZoneNetworkPeeringConfig metadata: name: zone-1-zone-2-peering-config namespace: gpc-system spec: ... status: borderLeafSwitches: - blswID: 1 blswName: aa-aa-blsw01 evpnBGPSessions: - bgpSessionConfig: addressFamily: EVPN bfdConfig: bfdMode: MultiHopBFD localASN: 65501 localIP: 192.168.201.65/32 md5SecretRef: name: zone-1-blsw-1-zone-2-blsw-1-evpn-bgp-password namespace: gpc-system peerASN: 65502 peerIP: 192.168.202.65 sourceInterface: loopback2 bgpSessionStatus: prefixCounters: received: 4 sent: 23 sessionStatus: Up uptime: P6DT20H26M59S ipv4BGPSessions: - bgpSessionConfig: addressFamily: IPv4 bfdConfig: bfdMode: PlainBFD localASN: 65501 localIP: 192.168.208.0/31 md5SecretRef: name: zone-1-blsw-1-zone-2-blsw-1-ipv4-bgp-password namespace: gpc-system peerASN: 65502 peerIP: 192.168.208.1 bgpSessionStatus: prefixCounters: received: 11 sent: 11 sessionStatus: Up uptime: P6DT20H27M1S port: port: 6El estado de este ejemplo contiene todas las configuraciones de las sesiones de BGP y los estados de las sesiones de BGP de la zona 1 a la zona 2.
- En el modo de operador de nivel 3, un recurso
MultiZoneNetworkPeeringConfigllamadozone-1-ipv4-peering-configque representa todas las sesiones BGP IPv4 de una zona al operador de nivel 3 podría tener el siguiente aspecto:
apiVersion: system.private.gdc.goog/v1alpha1 kind: MultiZoneNetworkPeeringConfig metadata: name: zone-1-ipv4-peering-config namespace: gpc-system spec: ... status: borderLeafSwitches: - blswID: 1 blswName: aa-aa-blsw01 ipv4BGPSessions: - bgpSessionConfig: addressFamily: IPv4 bfdConfig: bfdMode: PlainBFD localASN: 65501 localIP: 192.168.208.0/31 md5SecretRef: name: zone-1-blsw-1-port-6-ipv4-bgp-password namespace: gpc-system peerASN: 65502 peerIP: 192.168.208.1 bgpSessionStatus: prefixCounters: received: 11 sent: 11 sessionStatus: Up uptime: P6DT20H27M1S port: port: 6- Un recurso
2.1. Configurar los puertos
La configuración de ports depende del tipo de operador. Sigue estas reglas al configurar tu ports:
Si el tipo de operador es
L2, debe especificarnpuertos enSpec.Ports, dondenes igual al número de zonas multiplicado por dos. El primer puerto debe conectarse al primer switch de hoja de borde (ordenado por nombre de switch) de la primera zona vecina (ordenada por ID de zona). El segundo puerto debe conectarse al segundo conmutador de hoja de borde de la primera zona vecina. El tercer puerto se conecta al primer conmutador de hoja de borde de la segunda zona vecina. Las demás conexiones siguen este patrón. Consulta la implementación de la capa 2 de la empresa de transporte para ver una ilustración.Si el tipo de operador es
L3, debe especificar dos puertos enSpec.Ports. Ambos switches de hoja de borde de la zona actual deben usar el primer puerto para conectarse individualmente al primer dispositivo de borde del proveedor y el segundo puerto para conectarse individualmente al segundo dispositivo de borde del proveedor. Consulta más información sobre la implementación de operadores de nivel 3.
2.2. Ejemplos de configuración multizona
En esta sección se incluyen algunos ejemplos de implementaciones habituales.
2.2.1. Despliegue de operador L2
Esta implementación tiene la siguiente configuración:
- Tres zonas con los ASN 65501, 65502 y 65503
- Una portadora L2
En este diagrama se muestran las conexiones lógicas de esta implementación:

A continuación, se muestra un ejemplo de un archivo YAML MultiZoneNetworkConfig:
apiVersion: system.private.gdc.goog/v1alpha1
kind: MultiZoneNetworkConfig
metadata:
name: multizone-network-config
namespace: gpc-system
spec:
carrierType: L2
zones:
- zoneID: 1
asn: 65501
- zoneID: 2
asn: 65502
- zoneID: 3
asn: 65503
ports:
- port: 10
- port: 11
- port: 12
- port: 13
2.2.2. Implementación de operador de nivel 3
Esta implementación tiene la siguiente configuración:
- Tres zonas con los ASN 65501, 65502 y 65503
- Portadora L3
En este diagrama se muestran las conexiones lógicas de esta implementación:

A continuación, se muestra un ejemplo de un archivo YAML MultiZoneNetworkConfig:
apiVersion: system.private.gdc.goog/v1alpha1
kind: MultiZoneNetworkConfig
metadata:
name: multizone-network-config
namespace: gpc-system
spec:
carrierType: L3
zones:
- zoneID: 1
asn: 65501
carrierASN: 60010
- zoneID: 2
asn: 65502
carrierASN: 60010
- zoneID: 3
asn: 65503
carrierASN: 60010
ports:
- port: 10
- port: 11
2.3. Opcional: Configurar la autenticación BFD multizona
La detección de reenvío bidireccional (BFD) se configura en todas las sesiones IPv4 y EVPN multizona. De forma predeterminada, se configura BFD simple de un solo salto. Sigue las instrucciones de esta sección para implementar BFD de varios saltos con autenticación:
Habilita la autenticación de detección de reenvío bidireccional (BFD) para sesiones de BGP de EVPN multizona. Para establecer y activar sesiones de BFD, asegúrate de que las sesiones de BGP emparejadas de ambas zonas estén configuradas con el mismo ID de clave de autenticación y la misma cadena de clave de BFD:
Define el tipo de clave. Te recomendamos que ejecutes este comando en la máquina de arranque. Usa al menos SHA-1 para la clave por motivos de seguridad. Si es necesario, usa una clave más segura para tu configuración:
export KEY_TYPE=SHA1Define el ID y la cadena de la clave. El ID de clave debe ser único entre las sesiones de interconexión emparejadas de todas las zonas. Determina un ID de clave que no se esté usando y asígnalo a la variable:
export KEY_ID=1Genera una clave de autenticación SHA-1 con
chronyc keygen:CHRONY_OUTPUT=$(chronyc keygen ${KEY_ID:?} ${KEY_TYPE:?})Ejemplo:
echo $CHRONY_OUTPUT 1 SHA1 HEX:887F1B88085BD0BDE4458EA7C2C4393C50A498EFExtrae la clave de autenticación y verifícala:
export KEY_STR=$(echo ${CHRONY_OUTPUT:?} | awk '{ split($3,key,":"); print key[2]}')echo $KEY_STR 887F1B88085BD0BDE4458EA7C2C4393C50A498EFAplica la información de autenticación de BFD a las sesiones de interconexión seleccionadas:
kubectl --kubeconfig=KUBECONFIG_PATH patch secret zone-LOCAL_ZONE_ID-blsw-LOCAL_BLSW_ID-zone-REMOTE_ZONE_ID-blsw-REMOTE_BLSWID-bfd-auth-key -n gpc-system -p='{ "stringData": { "bfdKeyID": "'"${KEY_ID}"'", "bfdKeyValue": "'"${KEY_STR}"'" } }'Verifica que la sesión de BFD se esté ejecutando:
switch# show bfd neighbors vrf defaultComprueba que el campo
Statetenga el valorUpy que el campoTypeseaSHoMH:OurAddr NeighAddr LD/RD RH/RS Holdown(mult) State Int Vrf Type BSID 192.168.208.31 192.168.208.30 1090519041/1090519042 Up 5237(3) Up Eth1/11 default SH N/A 192.168.208.91 192.168.208.90 1090519042/1090519042 Up 5624(3) Up Eth1/12 default SH N/A 192.168.202.66 192.168.201.65 1090519071/1090519060 Up 629(3) Up Lo2 default MH N/A 192.168.202.66 192.168.201.66 1090519072/1090519061 Up 545(3) Up Lo2 default MH N/A
2.4. Opcional: Configurar la contraseña de BGP multizona
Hay dos tipos de contraseñas de protocolo de pasarela fronteriza (BGP): la contraseña de sesión de BGP IPv4 y la contraseña de sesión de BGP EVPN.
De forma predeterminada, todas las contraseñas de BGP están vacías. Sigue las instrucciones de esta sección para actualizar las contraseñas.
2.4.1. Actualizar la contraseña de BGP IPv4
Si se usa un operador de nivel 2, actualiza la contraseña de BGP IPv4 aplicada a la sesión de BGP IPv4 entre un switch de hoja de borde de la zona actual y otro switch de hoja de borde de otra zona:
kubectl patch secret zone-LOCAL_ZONE_ID-blsw-LOCAL_BLSW_ID-zone-REMOTE_ZONE_ID-blsw-REMOTE_BLSWID-ipv4-bgp-password -p='{"stringData":{"password":"PASSWORD"}}'
Haz los cambios siguientes:
LOCAL_ZONE_ID: ID numérico de la zona actual.LOCAL_BLSW_ID: ID numérico del interruptor de hoja de borde de la zona actual. Este valor debe ser1o2.REMOTE_ZONE_ID: ID numérico de la zona remota.REMOTE_BLSW_ID: ID numérico del interruptor de hoja de borde de la zona remota. Este valor debe ser1o2.PASSWORD: contraseña de BGP aplicada a la sesión de BGP IPv4 entre el switch de hoja de frontera local y el switch de hoja de frontera remoto.
Si se utiliza un operador de nivel 3, actualiza la contraseña de BGP IPv4 aplicada a la sesión de BGP IPv4 entre un switch de hoja de borde de la zona actual y un dispositivo de borde del proveedor del operador de nivel 3:
kubectl patch secret zone-LOCAL_ZONE_ID-blsw-LOCAL_BLSW_ID-port-PORT_ID-ipv4-bgp-password -p='{"stringData":{"password":"PASSWORD"}}' -n gpc-system --kubeconfig=KUBECONFIG_PATH
Haz los cambios siguientes:
LOCAL_ZONE_ID: ID numérico de la zona actual.LOCAL_BLSW_ID: ID numérico del interruptor de hoja de borde de la zona actual. El valor debe ser1o2.PORT_ID: índice del puerto Ethernet que se conecta al dispositivo de extremo del proveedor.PASSWORD: contraseña de BGP aplicada a la sesión de BGP IPv4 entre el switch de hoja de frontera local y el dispositivo de borde del proveedor.
2.4.2. Actualizar la contraseña de BGP de EVPN
Para actualizar la contraseña de BGP de EVPN aplicada a la sesión de BGP de EVPN entre un switch de hoja de borde de la zona actual y otro switch de hoja de borde de otra zona, ejecuta el siguiente comando:
kubectl patch secret zone-LOCAL_ZONE_ID-blsw-LOCAL_BLSW_ID-zone-REMOTE_ZONE_ID-blsw-REMOTE_BLSWID-evpn-bgp-password -p='{"stringData":{"password":"PASSWORD"}}' -n gpc-system --kubeconfig=KUBECONFIG_PATH
Haz los cambios siguientes:
LOCAL_ZONE_ID: ID numérico de la zona actual.LOCAL_BLSW_ID: ID numérico del interruptor de hoja de borde de la zona actual. El valor debe ser1o2.REMOTE_ZONE_ID: ID numérico de la zona remota.REMOTE_BLSW_ID: ID numérico del interruptor de hoja de borde de la zona remota. El valor debe ser1o2.PASSWORD: contraseña de BGP aplicada a la sesión de BGP de EVPN entre el switch de hoja de borde local y el switch de hoja de borde remoto.
3. Opciones de configuración avanzada
En esta sección se presentan las opciones de configuración avanzadas que ofrecen las APIs de redes multizona.
3.1. Configurar la anulación de la configuración de BGP de la operadora
De forma predeterminada, los switches de hoja de borde establecen conexiones de emparejamiento BGP con dispositivos PE de operadores mediante una asignación de direcciones IP predeterminada. La dirección IP de emparejamiento BGP específica que se está usando se puede encontrar inspeccionando el recurso MultiZoneNetworkPeeringConfig zone-<ZONE_ID>-ipv4-peering-config. Por ejemplo:
apiVersion: system.private.gdc.goog/v1alpha1
kind: MultiZoneNetworkPeeringConfig
metadata:
name: zone-1-ipv4-peering-config
namespace: gpc-system
spec: ...
status:
borderLeafSwitches:
- blswID: 1
blswName: aa-aa-blsw01
ipv4BGPSessions:
- bgpSessionConfig:
addressFamily: IPv4
bfdConfig:
bfdMode: PlainBFD
localASN: 65501
localIP: 192.168.208.0/31
md5SecretRef:
name: zone-1-blsw-1-port-6-ipv4-bgp-password
namespace: gpc-system
peerASN: 65502
peerIP: 192.168.208.1
...
Para usar un plan de direcciones IP personalizado, anula la configuración predeterminada de BGP de la operadora siguiendo el paso que se indica a continuación:
- Ejecuta
kubectl edit MultiZoneNetworkPeeringConfig zone-<ZONE_ID>-ipv4-peering-config -n gpc-systemy añade la seccióncarrierBGPConfigOverrideenspec.Peerings. Ejemplo:
apiVersion: system.private.gdc.goog/v1alpha1
kind: MultiZoneNetworkPeeringConfig
metadata:
name: zone-1-ipv4-peering-config
namespace: gpc-system
...
spec:
peeringConfigType: L3-IPv4
peerings:
- carrierBGPConfigOverride:
peeringIP:
localIP: 192.168.78.5/31
peerIP: 192.168.78.4
peerA:
blswID: 1
port:
port: 11
zoneID: 1
...
En este ejemplo, al especificar carrierBGPConfigOverride.peeringIP, se anula la subred de emparejamiento y se asigna 192.168.78.4/31.
3.2. Configurar la anulación de puertos
Google recomienda que todos los conmutadores de hoja de borde de todas las zonas usen el mismo conjunto de puertos. Esta configuración de puertos es útil en situaciones en las que se requiere un control pormenorizado de los puertos.
La zona local es la zona en la que vas a implementar.
Las zonas remotas son otras zonas del mismo universo multizona.
De forma predeterminada, debe usar los mismos puertos para los dos conmutadores de hoja de borde de una zona para conectarse a otra zona o a la empresa de transporte. Sin embargo, puedes habilitar la opción de anulación de puerto para especificar un puerto diferente que se usará en esta conexión entre zonas.
Para configurar la función de anulación de puerto, sigue estos pasos:
Habilita la función
portOverride:kubectl patch MultiZoneNetworkConfig multizone-network-config -n gpc-system --type='merge' -p '{"spec":{"enablePortOverride":true}}' --kubeconfig=KUBECONFIG_PATHIdentifica el interruptor de hoja de borde de zona local y el interruptor de hoja de borde de zona remota. A continuación, modifica el puerto del interruptor de hoja de borde local:
kubectl edit MultiZoneNetworkPeeringConfig zone-ZONE_1_ID-zone-ZONE_2_ID -n gpc-system --kubeconfig=KUBECONFIG_PATHHaz los cambios siguientes:
ZONE_1_ID: el ID de zona más pequeño entre el ID de zona local y el ID de zona remoto. Por ejemplo, si el ID de la zona local es1y el ID de la zona remota es2, indica el valor1aquí.ZONE_2_ID: el ID de zona más grande entre el ID de zona local y el ID de zona remota.
Un recurso
MultiZoneNetworkPeeringConfigpodría tener el siguiente aspecto:apiVersion: system.private.gdc.goog/v1alpha1 kind: MultiZoneNetworkPeeringConfig metadata: name: zone-2-zone-3-peering-config namespace: gpc-system spec: peeringConfigType: L2 peerings: - peerA: blswID: 1 port: port: 12 zoneID: 2 peerB: blswID: 1 port: port: 12 zoneID: 3 secrets: - secretRef: name: zone-2-blsw-1-zone-3-blsw-1-ipv4-bgp-password namespace: gpc-system type: ipv4-bgp-password - secretRef: name: zone-2-blsw-1-zone-3-blsw-1-evpn-bgp-password namespace: gpc-system type: evpn-bgp-password - secretRef: name: zone-2-blsw-1-zone-3-blsw-1-bfd-auth-key namespace: gpc-system type: bfd-auth-key - peerA: blswID: 1 port: port: 12 zoneID: 2 peerB: blswID: 2 port: port: 12 zoneID: 3 secrets: - secretRef: name: zone-2-blsw-2-zone-3-blsw-2-ipv4-bgp-password namespace: gpc-system type: ipv4-bgp-password - secretRef: name: zone-2-blsw-2-zone-3-blsw-2-evpn-bgp-password namespace: gpc-system type: evpn-bgp-password - secretRef: name: zone-2-blsw-2-zone-3-blsw-2-bfd-auth-key namespace: gpc-system type: bfd-auth-keyDebes actualizar el valor del puerto de uno de los switches de hoja de borde que componen el peering entre zonas. En el campo
Spec.peerings, busca el peering que abarca varias zonas. En el ejemplo, tenemos esta conexión entre la zona dos y la zona tres:peerA: blswID: 1 port: port: 12 zoneID: 2 peerB: blswID: 2 port: port: 12 zoneID: 3El resultado muestra dos conmutadores de hoja de borde, identificados por
blswID: 1yblswID: 2. En el primer switch de hoja de borde identificado porblswID: 1, actualiza el puerto al nuevo valor20:peerA: blswID: 1 port: port: 20 zoneID: 2 peerB: blswID: 2 port: port: 12 zoneID: 3En el ejemplo, actualizamos el valor del puerto del primer switch de hoja de borde a
port: 20.