Configurar una interconexión multizona

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

  1. Configura un recurso MultiZoneNetworkConfig en cada zona del despliegue multizona:

    1. Busca el clúster correcto con el que interactuar. Si el clúster de administrador raíz está en ejecución, usa el kubeconfig del clúster de administrador raíz. De lo contrario, usa kubeconfig para 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_PATH
      
    2. Crea un archivo YAML llamado multizone_network_config.yaml.

    3. 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: MTU
      

      Haz los cambios siguientes:

      • CARRIER_TYPE: el tipo de operador troncal multizona. Debe ser L2 o L3.

      • 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 recurso zone-infra-cidr CIDRClaim del 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 recurso zone-infra-cidr CIDRClaim del 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.

    4. Aplica el archivo multizone_network_config.yaml al clúster:

      kubectl apply -f multizone_network_config.yaml --kubeconfig=KUBECONFIG_PATH
      
    5. Comprueba que el recurso MultiZonetNetworkConfig se haya creado correctamente:

      kubectl get multizonenetworkconfig -n gpc-system --kubeconfig=KUBECONFIG_PATH
      

      En el siguiente ejemplo se muestra un resultado con enlaces de interconexión:

      NAME                       AGE   READY
      multizone-network-config   26h   True
      
    6. Opcional: Consulta el recurso MultiZoneNetworkPeeringConfig para 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 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 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: 6
      

      El 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 MultiZoneNetworkPeeringConfig llamado zone-1-ipv4-peering-config que 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
      

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 especificar n puertos en Spec.Ports, donde n es 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 en Spec.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:

    multizone-pnet-l2-carrier-topology

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:

    multizone-pnet-l3-carrier-topology

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:

  1. 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:

    1. 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
      
    2. Define 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=1
      
    3. Genera 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:887F1B88085BD0BDE4458EA7C2C4393C50A498EF
      
    4. 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
      
    5. Aplica 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}"'"
        }
      }'
      
    6. Verifica que la sesión de BFD se esté ejecutando:

      switch# show bfd neighbors vrf default
      
    7. Comprueba que el campo State tenga el valor 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: 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 ser 1 o 2.
  • 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 ser 1 o 2.
  • 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 ser 1 o 2.
  • 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 ser 1 o 2.
  • 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 ser 1 o 2.
  • 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:

  1. Ejecuta kubectl edit MultiZoneNetworkPeeringConfig zone-<ZONE_ID>-ipv4-peering-config -n gpc-system y añade 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, 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:

  1. Habilita la función portOverride:

    kubectl patch MultiZoneNetworkConfig multizone-network-config -n gpc-system --type='merge' -p '{"spec":{"enablePortOverride":true}}' --kubeconfig=KUBECONFIG_PATH
    
  2. Identifica 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_PATH
    

    Haz 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 es 1 y el ID de la zona remota es 2, indica el valor 1 aquí.
    • ZONE_2_ID: el ID de zona más grande entre el ID de zona local y el ID de zona remota.

    Un recurso MultiZoneNetworkPeeringConfig podrí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-key
    

    Debes 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: 3
    

    El resultado muestra dos conmutadores de hoja de borde, identificados por blswID: 1 y blswID: 2. En el primer switch de hoja de borde identificado por blswID: 1, actualiza el puerto al nuevo valor 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 switch de hoja de borde a port: 20.