Configura l'interconnessione multizona

Questa pagina descrive la configurazione necessaria da eseguire sulle zone esistenti di un deployment multizona quando una nuova zona viene aggiunta al deployment. Questa configurazione ti consente di stabilire connessioni alla nuova zona.

1. Prima di iniziare

Per configurare l'interconnessione multizona su Google Distributed Cloud (GDC) air-gapped, devi disporre di quanto segue:

Un file kubeconfig generato e una variabile di ambiente. Per maggiori dettagli, consulta il runbook IAM-R0004.
Un operatore di infrastruttura (IO) con accesso temporaneo al cluster di amministrazione principale. Per maggiori dettagli, consulta il runbook IAM-R0005.

2. Configura l'interconnessione multizona

Configura una risorsa MultiZoneNetworkConfig in ogni zona del deployment multizona:
1. Trova il cluster corretto con cui interagire. Se il cluster di amministrazione principale è in esecuzione, utilizza kubeconfig per il cluster di amministrazione principale. Altrimenti, utilizza kubeconfig per il cluster bootstrap kind. Per maggiori dettagli, consulta il runbook IAM-R0004. Compila il percorso kubeconfig qui:
```
KUBECONFIG=KUBECONFIG_PATH
```
2. Crea un file YAML denominato multizone_network_config.yaml.
3. Aggiungi i seguenti contenuti al file:
```
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
```
  Sostituisci quanto segue:
  - CARRIER_TYPE: Il tipo di operatore di backbone multizona. Deve essere L2 o L3.
    
    Importante: per il tipo di operatore L2, Google consiglia vivamente di non superare le tre zone.
  - ZONE_1_ID: l'ID della prima zona nella regione GDC.
  - ZONE_1_ASN: il numero di sistema autonomo (ASN) BGP della rete di dati della prima zona nella regione GDC.
  - METERING_SUBNET_1: La subnet misurata di questa zona. Questo campo deve essere compilato con la subnet della risorsa zone-infra-cidr CIDRClaim nel cluster di amministrazione principale della zona associata. Questo campo è solo a scopo di misurazione e non ha alcun effetto sul controllo della pubblicità della subnet. Devi mantenere questo campo sincronizzato con le subnet effettive pubblicizzate. Se questo campo non viene specificato, non viene misurato alcun traffico per questa zona.
  - ZONE_2_ID: l'ID della seconda zona nella regione GDC.
  - ZONE_2_ASN: l'ASN BGP della rete di dati della seconda zona nella regione GDC.
  - METERING_SUBNET_2: La subnet misurata di questa zona. Questo campo deve essere compilato con la subnet della risorsa zone-infra-cidr CIDRClaim nel cluster di amministrazione principale della zona associata. Questo campo è solo a scopo di misurazione e non ha alcun effetto sul controllo della pubblicità della subnet. Devi mantenere questo campo sincronizzato con le subnet effettive pubblicizzate. Se questo campo non viene specificato, non viene misurato alcun traffico per questa zona.
  - PORT_1: La prima porta che partecipa all'interconnessione multizona. Per ulteriori informazioni, consulta Configurare le porte.
  - PORT_2: La seconda porta che partecipa all'interconnessione multizona . Per ulteriori informazioni, consulta Configurare le porte.
  - MTU: Il valore MTU applicato a tutte le porte. Se non specificato, il valore predefinito è 9216.
  Attenzione: tutte le zone, inclusa quella attuale, devono essere incluse nel campo zones.
  Nota: gli ASN della zona devono essere uguali a dataASN delle zone associate.
  
  Consulta Esempi di configurazione multizona per esempi di deployment comuni.
4. Applica il file multizone_network_config.yaml al cluster:
```
kubectl apply -f multizone_network_config.yaml --kubeconfig=KUBECONFIG_PATH
```
5. Verifica che la creazione della risorsa MultiZonetNetworkConfig sia riuscita:
```
kubectl get multizonenetworkconfig -n gpc-system --kubeconfig=KUBECONFIG_PATH
```
  Il seguente esempio mostra un output con link di interconnessione:
```
NAME                       AGE   READY
multizone-network-config   26h   True
```
6. (Facoltativo) Controlla la risorsa MultiZoneNetworkPeeringConfig per la configurazione e lo stato del BGP di interconnessione.
  
  La configurazione BGP effettiva viene impostata dal riconciliatore di rete e archiviata nella risorsa MultiZoneNetworkPeeringConfig. Ogni risorsa MultiZoneNetworkPeeringConfig rappresenta tutte le configurazioni BGP da una zona all'altra. Ad esempio:
  - Una risorsa MultiZoneNetworkPeeringConfig denominata zone-1-zone-2-peering-config potrebbe avere il seguente aspetto:
```
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
```
  Lo stato di questo esempio contiene tutte le configurazioni delle sessioni BGP e gli stati delle sessioni BGP dalla zona 1 alla zona 2.
  - Per la modalità operatore L3, una risorsa MultiZoneNetworkPeeringConfig denominata zone-1-ipv4-peering-config che rappresenta tutte le sessioni BGP IPv4 da una zona all'operatore L3 potrebbe avere il seguente aspetto:
```
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 le porte

La configurazione di ports dipende dal tipo di operatore. Segui queste regole quando imposti il tuo ports:

Se il tipo di operatore è L2, devi specificare le porte n in Spec.Ports, dove n è uguale al numero di zone moltiplicato per due. La prima porta deve connettersi al primo switch leaf di confine (ordinato per nome dello switch) della prima zona adiacente (ordinata per ID zona). La seconda porta deve connettersi al secondo switch leaf di confine della prima zona vicina. La terza porta si collega al primo switch leaf di confine della seconda zona vicina. Le connessioni successive seguono questo schema. Per un'illustrazione, consulta la sezione Deployment dell'operatore L2.

Importante: per il tipo di operatore L2, Google consiglia vivamente di non superare le tre zone.
Se il tipo di operatore è L3, devi specificare due porte in Spec.Ports. Entrambi gli switch di frontiera nella zona attuale devono utilizzare la prima porta per connettersi individualmente al primo dispositivo edge del fornitore e la seconda porta per connettersi individualmente al secondo dispositivo edge del fornitore. Per ulteriori dettagli, consulta Deployment dell'operatore L3.

2.2. Esempi di configurazione multizona

Questa sezione contiene esempi di implementazione comuni.

2.2.1. Deployment dell'operatore L2

Questo deployment ha la seguente configurazione:

Tre zone con ASN 65501, 65502, 65503
Un operatore L2
Le connessioni logiche per questo deployment sono mostrate in questo diagramma:

Importante: questo esempio illustra l'implementazione di un operatore L2 a tre zone. Google consiglia vivamente di non superare le tre zone per i tipi di corriere L2.

Di seguito è riportato un esempio di file 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. Deployment dell'operatore L3

Questo deployment ha la seguente configurazione:

Tre zone con ASN 65501, 65502, 65503
Operatore L3
Le connessioni logiche per questo deployment sono mostrate in questo diagramma:

Di seguito è riportato un esempio di file 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. (Facoltativo) Configura l'autenticazione BFD multizona

Bidirectional Forwarding Detection (BFD) è configurato su tutte le sessioni IPv4 e EVPN multizona. Per impostazione predefinita, è configurato il protocollo BFD semplice a singolo hop. Segui le istruzioni riportate in questa sezione per eseguire il deployment di BFD multihop con autenticazione:

Abilita l'autenticazione Bidirectional Forwarding Detection (BFD) per le sessioni BGP EVPN multizona. Per stabilire e attivare le sessioni BFD, assicurati che le sessioni BGP accoppiate in entrambe le zone siano configurate con lo stesso ID chiave di autenticazione BFD e la stessa stringa della chiave:

Definisci il tipo di chiave. Ti consigliamo di eseguire questo comando sulla macchina bootstrapper. Per motivi di sicurezza, utilizza almeno SHA-1 per la chiave. Se necessario, utilizza una chiave più sicura per la configurazione:
```
export KEY_TYPE=SHA1
```
Imposta l'ID chiave e la stringa della chiave. L'ID chiave deve essere univoco tra le sessioni di interconnessione accoppiate nelle zone. Determina un ID chiave non utilizzato e assegnalo alla variabile:
```
export KEY_ID=1
```

Genera una chiave di autenticazione SHA-1 utilizzando chronyc keygen:

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

Output di esempio:

echo $CHRONY_OUTPUT
1 SHA1 HEX:887F1B88085BD0BDE4458EA7C2C4393C50A498EF

Estrai la chiave di autenticazione e verificala:

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

echo $KEY_STR
887F1B88085BD0BDE4458EA7C2C4393C50A498EF

Applica una patch alle informazioni di autenticazione BFD alle sessioni di interconnessione selezionate:

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 che la sessione BFD sia in esecuzione:
```
switch# show bfd neighbors vrf default
```

Verifica che il campo State mostri un valore di Up e che il campo Type sia 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. (Facoltativo) Configura la password BGP multizona

Esistono due tipi di password Border Gateway Protocol (BGP): la password della sessione BGP IPv4 e la password della sessione BGP EVPN.

Per impostazione predefinita, tutte le password BGP sono vuote. Segui le istruzioni riportate in questa sezione per aggiornare le password.

2.4.1. Aggiorna la password BGP IPv4

Se viene utilizzato un operatore L2, aggiorna la password BGP IPv4 applicata alla sessione BGP IPv4 tra uno switch leaf di confine nella zona attuale e un altro switch leaf di confine in un'altra 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"}}'

Sostituisci quanto segue:

LOCAL_ZONE_ID: l'ID numerico della zona corrente.
LOCAL_BLSW_ID: l'ID numerico dello switch leaf di confine della zona corrente. Questo valore deve essere 1 o 2
REMOTE_ZONE_ID: l'ID numerico della zona remota.
REMOTE_BLSW_ID: l'ID numerico dello switch leaf di confine della zona remota. Questo valore deve essere 1 o 2
PASSWORD: la password BGP applicata alla sessione BGP IPv4 tra lo switch leaf di confine locale e lo switch leaf di confine remoto.

Se viene utilizzato un operatore L3, aggiorna la password BGP IPv4 applicata alla sessione BGP IPv4 tra uno switch leaf di confine nella zona corrente e un dispositivo edge del fornitore nell'operatore L3:

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

Sostituisci quanto segue:

LOCAL_ZONE_ID: l'ID numerico della zona corrente.
LOCAL_BLSW_ID: l'ID numerico dello switch leaf di confine della zona corrente. Questo valore deve essere 1 o 2.
PORT_ID: l'indice della porta Ethernet che si connette al dispositivo edge del provider.
PASSWORD: la password BGP applicata alla sessione BGP IPv4 tra lo switch leaf di confine locale e il dispositivo edge del provider.

2.4.2. Aggiorna la password BGP EVPN

Per aggiornare la password BGP EVPN applicata alla sessione BGP EVPN tra uno switch leaf di confine nella zona attuale e un altro switch leaf di confine in un'altra zona, esegui:

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

Sostituisci quanto segue:

LOCAL_ZONE_ID: l'ID numerico della zona corrente.
LOCAL_BLSW_ID: l'ID numerico dello switch leaf di confine della zona corrente. Questo valore deve essere 1 o 2.
REMOTE_ZONE_ID: l'ID numerico della zona remota.
REMOTE_BLSW_ID: l'ID numerico dello switch leaf di confine della zona remota. Questo valore deve essere 1 o 2.
PASSWORD: la password BGP applicata alla sessione BGP EVPN tra lo switch leaf di confine locale e lo switch leaf di confine remoto.

3. Opzioni di configurazione avanzate

Questa sezione introduce le opzioni di configurazione avanzate fornite dalle API di rete multizona.

3.1. Configura l'override della configurazione BGP dell'operatore

Per impostazione predefinita, gli switch leaf di confine stabiliscono connessioni di peering BGP con i dispositivi PE dell'operatore utilizzando un'allocazione di indirizzi IP predefinita. L'indirizzo IP di peering BGP specifico in uso può essere trovato esaminando la risorsa MultiZoneNetworkPeeringConfig zone-<ZONE_ID>-ipv4-peering-config. Ad esempio:

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

Per utilizzare un piano di indirizzi IP personalizzato, esegui l'override della configurazione BGP predefinita dell'operatore seguendo il passaggio riportato di seguito:

Esegui kubectl edit MultiZoneNetworkPeeringConfig zone-<ZONE_ID>-ipv4-peering-config -n gpc-system, aggiungendo la sezione carrierBGPConfigOverride sotto spec.Peerings. Esempio:

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

In questo esempio, la specifica di carrierBGPConfigOverride.peeringIP sostituisce la subnet di peering con 192.168.78.4/31.

3.2. Configura l'override della porta

Google consiglia di utilizzare lo stesso insieme di porte per tutti gli switch leaf di confine in tutte le zone. Questa configurazione delle porte è utile per gli scenari in cui è necessario un controllo granulare delle porte.

La zona locale è la zona di cui stai eseguendo il deployment.

Le zone remote sono altre zone all'interno dello stesso universo multizona.

Per impostazione predefinita, devi utilizzare le stesse porte per i due switch leaf di confine di una zona per connetterti a un'altra zona o all'operatore. Tuttavia, puoi attivare l'opzione di override della porta per specificare una porta diversa da utilizzare per questa connessione tra zone.

Per configurare la funzionalità di override della porta:

Attiva la funzionalità portOverride:

kubectl patch MultiZoneNetworkConfig multizone-network-config -n gpc-system --type='merge' -p '{"spec":{"enablePortOverride":true}}' --kubeconfig=KUBECONFIG_PATH

Identifica lo switch leaf di confine della zona locale e lo switch leaf di confine della zona remota, quindi modifica la porta dello switch leaf di confine locale:

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

Sostituisci quanto segue:

ZONE_1_ID: l'ID zona più piccolo tra l'ID zona locale e l'ID zona remota. Ad esempio, se l'ID zona locale è 1 e l'ID zona remota è 2, fornisci qui il valore 1.
ZONE_2_ID: l'ID zona più grande tra l'ID zona locale e l'ID zona remota.

Una risorsa MultiZoneNetworkPeeringConfig potrebbe avere il seguente aspetto:

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

Devi aggiornare il valore della porta di uno degli switch leaf di confine che costituiscono il peering tra zone. Nel campo Spec.peerings, cerca il peering che si estende su più zone. Nell'esempio, abbiamo questa connessione peer tra la zona 2 e la zona 3:

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

L'output mostra due switch foglia di confine, identificati da blswID: 1 e blswID: 2. Per il primo switch leaf di confine identificato da blswID: 1, aggiorna la porta al nuovo valore di 20:

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

Nell'esempio, aggiorniamo il valore della porta del primo switch leaf di confine a port: 20.

Configura l'interconnessione multizona Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

1. Prima di iniziare

2. Configura l'interconnessione multizona

2.1. Configura le porte

2.2. Esempi di configurazione multizona

2.2.1. Deployment dell'operatore L2

2.2.2. Deployment dell'operatore L3

2.3. (Facoltativo) Configura l'autenticazione BFD multizona

2.4. (Facoltativo) Configura la password BGP multizona

2.4.1. Aggiorna la password BGP IPv4

2.4.2. Aggiorna la password BGP EVPN

3. Opzioni di configurazione avanzate

3.1. Configura l'override della configurazione BGP dell'operatore

3.2. Configura l'override della porta

Configura l'interconnessione multizona