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

Configura la interconexión multizona

En esta página, se describe la configuración necesaria que debes realizar en las zonas existentes de una implementación multizona cuando una zona nueva se une a la implementación. Esta configuración te permite establecer conexiones con la zona nueva.

1. Antes de comenzar

Debes tener lo siguiente para configurar la interconexión multizona en Google Distributed Cloud (GDC) aislado:

Un archivo kubeconfig generado y una variable de entorno Para obtener más detalles, consulta el manual IAM-R0004.
Un operador de infraestructura (IO) con acceso temporal al clúster de administrador raíz Para obtener más detalles, consulta el manual IAM-R0005.

2. Configura la interconexión multizona

Configura un recurso MultiZoneNetworkConfig en cada zona de la implementación multizona:
1. Encuentra el clúster correcto con el que interactuar. Si el clúster de administrador raíz está en ejecución, usa kubeconfig para el clúster de administrador raíz. De lo contrario, usa kubeconfig para el clúster de arranque de tipo. Para obtener más detalles, consulta el manual IAM-R0004. Completa la ruta de acceso de kubeconfig aquí:
```
KUBECONFIG=KUBECONFIG_PATH
```
2. Crea un archivo YAML llamado multizone_network_config.yaml.
3. Agrega 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: MTU
```
  Reemplaza lo siguiente:
  - CARRIER_TYPE: Es el tipo de operador de red troncal de varias zonas. Debe ser L2 o L3.
    
    Importante: Para el tipo de operador L2, Google recomienda no exceder las tres zonas.
  - ZONE_1_ID: Es el ID de la primera zona de la región del GDC.
  - ZONE_1_ASN: Es el número del sistema autónomo (ASN) de BGP de la red de datos de la primera zona en la región del GDC.
  - METERING_SUBNET_1: Es la subred medida de esta zona. Este campo debe completarse con la subred del recurso zone-infra-cidr CIDRClaim en el clúster de administrador raíz de la zona asociada. Este campo solo se usa para fines de medición y no tiene efecto en el control de la publicación de la subred. Debes mantener este campo sincronizado con las subredes reales que se anuncian. Si no se especifica este campo, no se mide el tráfico para esta zona.
  - ZONE_2_ID: Es el ID de la segunda zona en la región del GDC.
  - ZONE_2_ASN: Es el ASN de BGP de la red de datos de la segunda zona en la región del GDC.
  - METERING_SUBNET_2: Es la subred medida de esta zona. Este campo debe completarse con la subred del recurso zone-infra-cidr CIDRClaim en el clúster de administrador raíz de la zona asociada. Este campo solo se usa para fines de medición y no tiene efecto en el control de la publicación de la subred. Debes mantener este campo sincronizado con las subredes reales que se anuncian. Si no se especifica este campo, no se mide el tráfico para esta zona.
  - PORT_1: Es el primer puerto que participa en la interconexión multizona. Consulta Cómo configurar los puertos para obtener más información.
  - PORT_2: Es el segundo puerto que participa en la interconexión multizona . Consulta Cómo configurar los puertos para obtener más información.
  - MTU: Es el valor de MTU aplicado a todos los puertos. Si no se especifica, el valor predeterminado es 9216.
  Precaución: Todas las zonas, incluida la actual, deben incluirse en el campo zones.
  Nota: Los ASN de la zona deben ser los mismos que los de dataASN de las zonas asociadas.
  
  Consulta Ejemplos de configuración multizona para ver ejemplos de implementación comunes.
4. Aplica el archivo multizone_network_config.yaml al clúster:
```
kubectl apply -f multizone_network_config.yaml --kubeconfig=KUBECONFIG_PATH
```
5. Verifica que la creación del recurso MultiZonetNetworkConfig se haya realizado correctamente:
```
kubectl get multizonenetworkconfig -n gpc-system --kubeconfig=KUBECONFIG_PATH
```
  En el siguiente ejemplo, se muestra un resultado con vínculos de interconexión:
```
NAME                       AGE   READY
multizone-network-config   26h   True
```
6. Opcional: Verifica el recurso MultiZoneNetworkPeeringConfig para conocer la configuración y el estado del BGP de la interconexión.
  
  El reconciliador de red establece la configuración de BGP real y la almacena en el recurso MultiZoneNetworkPeeringConfig. Cada recurso MultiZoneNetworkPeeringConfig representa todas las configuraciones de BGP de una zona a otra. Por ejemplo:
  - Un recurso MultiZoneNetworkPeeringConfig llamado zone-1-zone-2-peering-config podría verse de la siguiente manera:
```
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: 6
```
  El estado de este ejemplo contiene todas las configuraciones de la sesión de BGP y los estados de la sesión de BGP de la zona uno a la zona dos.
  - Para el modo de operador de nivel 3, un recurso MultiZoneNetworkPeeringConfig llamado zone-1-ipv4-peering-config que representa todas las sesiones de BGP IPv4 de una zona al operador de nivel 3 podría verse de la siguiente manera:
```
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
```

2.1. Configura los puertos

La configuración de ports depende del tipo de operador. Sigue estas reglas cuando configures tu ports:

Si el tipo de empresa de transporte es L2, debes especificar puertos n en Spec.Ports, donde n es igual a la cantidad de zonas multiplicada por dos. El primer puerto debe conectarse al primer conmutador de hoja de borde (ordenado por nombre de conmutador) de la primera zona adyacente (ordenada por ID de zona). El segundo puerto debe conectarse al segundo conmutador de hoja de borde de la primera zona adyacente. 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 Implementación de operador de L2 para obtener una ilustración.

Importante: Para el tipo de operador L2, Google recomienda no exceder las tres zonas.
Si el tipo de operador es L3, debes especificar dos puertos en Spec.Ports. Ambos conmutadores de hoja de borde de la zona actual deben usar el primer puerto para conectarse individualmente al primer dispositivo perimetral del proveedor y deben usar el segundo puerto para conectarse individualmente al segundo dispositivo perimetral del proveedor. Consulta la implementación de operadores de nivel 3 para obtener más detalles.

2.2. Ejemplos de configuración de varias zonas

En esta sección, se incluyen ejemplos de implementaciones comunes.

2.2.1. Implementación de operador de L2

Esta implementación tiene la siguiente configuración:

Tres zonas con los ASN 65501, 65502 y 65503
Una empresa de transporte de L2
En este diagrama, se muestran las conexiones lógicas para esta implementación:

Importante: En este ejemplo, se ilustra una implementación de operador de L2 de tres zonas. Google recomienda no exceder las tres zonas para los tipos de operador de nivel 2.

El siguiente es un ejemplo de un archivo YAML de 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 L3

Esta implementación tiene la siguiente configuración:

Tres zonas con los ASN 65501, 65502 y 65503
Operador de nivel 3
En este diagrama, se muestran las conexiones lógicas para esta implementación:

El siguiente es un ejemplo de un archivo YAML de 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: Configura la autenticación de BFD en varias zonas

La detección de reenvío bidireccional (BFD) se configura en todas las sesiones de IPv4 y EVPN de varias zonas. De forma predeterminada, se configura la BFD simple de salto único. 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 las sesiones de BGP de EVPN de varias zonas. Para establecer y activar sesiones de BFD, asegúrate de que las sesiones de BGP vinculadas en ambas zonas estén configuradas con el mismo ID de clave de autenticación y 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=SHA1
```
Establece el ID y la cadena de la clave. El ID de clave debe ser único entre las sesiones de interconexión vinculadas en todas las zonas. Determina un ID de clave sin usar y asígnalo a la variable:
```
export KEY_ID=1
```

Genera una clave de autenticación SHA-1 con chronyc keygen:

CHRONY_OUTPUT=$(chronyc keygen ${KEY_ID:?} ${KEY_TYPE:?})

Resultado de ejemplo:

echo $CHRONY_OUTPUT
1 SHA1 HEX:887F1B88085BD0BDE4458EA7C2C4393C50A498EF

Extrae la clave de autenticación y verifícala:

export KEY_STR=$(echo ${CHRONY_OUTPUT:?} | awk '{ split($3,key,":"); print key[2]}')

echo $KEY_STR
887F1B88085BD0BDE4458EA7C2C4393C50A498EF

Aplica parches a la información de autenticación de BFD en 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 default
```

Verifica que el campo State muestre un valor de Up y que el campo Type sea SH o MH:

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: Configura la contraseña de BGP multizona

Existen dos tipos de contraseñas del Protocolo de puerta de enlace de frontera (BGP): la contraseña de la sesión de BGP IPv4 y la contraseña de la 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. Actualiza la contraseña de BGP IPv4

Si se usa un operador de L2, actualiza la contraseña de BGP IPv4 aplicada a la sesión de BGP IPv4 entre un conmutador de hoja de borde en la zona actual y otro conmutador de hoja de borde en 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"}}'

Reemplaza lo siguiente:

LOCAL_ZONE_ID: Es el 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 ser 1 o 2.
REMOTE_ZONE_ID: ID numérico de la zona remota.
REMOTE_BLSW_ID: Es el ID numérico del conmutador de hoja de borde de la zona remota. Este valor debe ser 1 o 2.
PASSWORD: Es la contraseña de BGP que se aplica a la sesión de BGP IPv4 entre el conmutador de hoja de borde local y el conmutador de hoja de borde remoto.

Si se usa un operador de nivel 3, actualiza la contraseña de BGP IPv4 aplicada a la sesión de BGP IPv4 entre un conmutador de hoja de borde en la zona actual y un dispositivo perimetral del proveedor en el 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

Reemplaza lo siguiente:

LOCAL_ZONE_ID: Es el 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 ser 1 o 2:
PORT_ID: Es el índice del puerto Ethernet que se conecta al dispositivo perimetral del proveedor.
PASSWORD: Es la contraseña de BGP que se aplica a la sesión de BGP IPv4 entre el conmutador de hoja de borde local y el dispositivo perimetral del proveedor.

2.4.2. Actualiza 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 conmutador de hoja de borde en la zona actual y otro conmutador de hoja de borde en 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

Reemplaza lo siguiente:

LOCAL_ZONE_ID: Es el 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 ser 1 o 2:
REMOTE_ZONE_ID: ID numérico de la zona remota.
REMOTE_BLSW_ID: Es el ID numérico del conmutador de hoja de borde de la zona remota. Este valor debe ser 1 o 2:
PASSWORD: Contraseña de BGP aplicada a la sesión de BGP de EVPN entre el conmutador de hoja de borde local y el conmutador de hoja de borde remoto.

3. Opciones de configuración avanzada

En esta sección, se presentan las opciones de configuración avanzadas que proporcionan las APIs de redes multizona.

3.1. Configura la anulación de configuración de BGP del operador

De forma predeterminada, los conmutadores de hoja de borde establecen conexiones de intercambio de tráfico de BGP con dispositivos PE de operadores mediante una asignación de direcciones IP predeterminada. La dirección IP de intercambio de tráfico de BGP específica en uso se puede encontrar inspeccionando el zone-<ZONE_ID>-ipv4-peering-config del recurso MultiZoneNetworkPeeringConfig. 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 del BGP de la empresa de telecomunicaciones siguiendo el paso que se indica a continuación:

Ejecuta kubectl edit MultiZoneNetworkPeeringConfig zone-<ZONE_ID>-ipv4-peering-config -n gpc-system y agrega la sección carrierBGPConfigOverride en spec.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, especificar carrierBGPConfigOverride.peeringIP anula la subred de la conexión de intercambio de tráfico a 192.168.78.4/31.

3.2. Configura la anulación de puertos

Google recomienda que todos los conmutadores de hoja de borde en 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 detallado de los puertos.

La zona local es la zona en la que realizas la implementación.

Las zonas remotas son otras zonas dentro del mismo universo de varias zonas.

De forma predeterminada, debes usar los mismos puertos para los dos conmutadores de hoja de borde de una zona para conectarte a otra zona o al operador. Sin embargo, puedes habilitar la opción de anulación de puerto para especificar un puerto diferente que se usará para esta conexión entre zonas.

Para configurar la función de anulación de puertos, 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_PATH

Identifica el conmutador de hoja de borde de zona local y el conmutador de hoja de borde de zona remota, y modifica el puerto del conmutador de hoja de borde local:

kubectl edit MultiZoneNetworkPeeringConfig zone-ZONE_1_ID-zone-ZONE_2_ID -n gpc-system --kubeconfig=KUBECONFIG_PATH

Reemplaza lo siguiente:

ZONE_1_ID: Es el ID de zona más pequeño entre el ID de zona local y el ID de zona remota. Por ejemplo, si el ID de la zona local es 1 y el ID de la zona remota es 2, proporciona el valor 1 aquí.
ZONE_2_ID: Es el ID de la zona más grande entre el ID de la zona local y el ID de la zona remota.

Un recurso MultiZoneNetworkPeeringConfig podría verse de la siguiente manera:

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-key

Debes actualizar el valor del puerto de uno de los conmutadores de hoja de borde que componen la interconexión entre zonas. En el campo Spec.peerings, busca el peering que abarca varias zonas. En el ejemplo, tenemos esta conexión de intercambio de tráfico entre la zona dos y la zona tres:

peerA:
  blswID: 1
  port:
    port: 12
  zoneID: 2
peerB:
  blswID: 2
  port:
    port: 12
  zoneID: 3

El resultado muestra dos conmutadores de hoja de borde, identificados por blswID: 1 y blswID: 2. Para el primer conmutador de hoja de borde identificado por blswID: 1, actualiza el puerto al nuevo valor de 20:

peerA:
  blswID: 1
  port:
    port: 20
  zoneID: 2
peerB:
  blswID: 2
  port:
    port: 12
  zoneID: 3

En el ejemplo, actualizamos el valor del puerto del primer conmutador de hoja de borde a port: 20.