Diese Seite wurde von der Cloud Translation API übersetzt.

Interconnect-Verbindung für mehrere Zonen konfigurieren

Auf dieser Seite wird die erforderliche Konfiguration beschrieben, die Sie in den vorhandenen Zonen einer Bereitstellung mit mehreren Zonen vornehmen müssen, wenn eine neue Zone der Bereitstellung hinzugefügt wird. Mit dieser Konfiguration können Sie Verbindungen zur neuen Zone herstellen.

1. Hinweise

Sie benötigen Folgendes, um die Multi-Zone-Verbindung in der Air-Gap-Umgebung von Google Distributed Cloud (GDC) zu konfigurieren:

Eine generierte kubeconfig-Datei und eine Umgebungsvariable. Weitere Informationen finden Sie im IAM-R0004-Runbook.
Ein Infrastrukturbetreiber mit temporärem Zugriff auf den Root-Administratorcluster. Weitere Informationen finden Sie im IAM-R0005-Runbook.

2. Interconnect-Verbindung für mehrere Zonen konfigurieren

Konfigurieren Sie eine MultiZoneNetworkConfig-Ressource in jeder Zone der Bereitstellung mit mehreren Zonen:
1. Suchen Sie den richtigen Cluster für die Interaktion. Wenn der Stammadministratorcluster ausgeführt wird, verwenden Sie kubeconfig für den Stammadministratorcluster. Andernfalls verwenden Sie kubeconfig für den Bootstrap-Kind-Cluster. Weitere Informationen finden Sie im IAM-R0004-Runbook. Geben Sie hier den kubeconfig-Pfad ein:
```
KUBECONFIG=KUBECONFIG_PATH
```
2. Erstellen Sie eine YAML-Datei mit dem Namen multizone_network_config.yaml.
3. Fügen Sie der Datei den folgenden Inhalt hinzu.
```
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
```
  Ersetzen Sie Folgendes:
  - CARRIER_TYPE: Der Typ des multizonalen Backbone-Carriers. Muss L2 oder L3 sein.
    
    Wichtig :Für den L2-Carrier-Typ empfiehlt Google dringend, nicht mehr als drei Zonen zu verwenden.
  - ZONE_1_ID: Die ID der ersten Zone in der GDC-Region.
  - ZONE_1_ASN: Die ASN (autonome Systemnummer) des BGP des Datennetzwerks der ersten Zone in der GDC-Region.
  - METERING_SUBNET_1: Das Subnetz mit Abrechnung nach Nutzung aus dieser Zone. In dieses Feld muss das Subnetz aus der zone-infra-cidr-Ressource CIDRClaim im Root-Administratorcluster der zugehörigen Zone eingetragen werden. Dieses Feld dient nur zu Abrechnungszwecken und hat keine Auswirkungen auf die Steuerung der Subnet-Ankündigung. Sie müssen dieses Feld mit den tatsächlich beworbenen Subnetzen synchronisieren. Wenn dieses Feld nicht angegeben ist, wird für diese Zone kein Traffic gemessen.
  - ZONE_2_ID: Die ID der zweiten Zone in der GDC-Region.
  - ZONE_2_ASN: Die BGP-ASN des Datennetzwerks der zweiten Zone in der GDC-Region.
  - METERING_SUBNET_2: Das Subnetz mit Abrechnung nach Nutzung aus dieser Zone. In dieses Feld muss das Subnetz aus der zone-infra-cidr-Ressource CIDRClaim im Root-Administratorcluster der zugehörigen Zone eingetragen werden. Dieses Feld dient nur zu Abrechnungszwecken und hat keine Auswirkungen auf die Steuerung der Subnet-Ankündigung. Sie müssen dieses Feld mit den tatsächlich beworbenen Subnetzen synchronisieren. Wenn dieses Feld nicht angegeben ist, wird für diese Zone kein Traffic gemessen.
  - PORT_1: Der erste Port, der an der Verbindung zwischen mehreren Zonen beteiligt ist. Weitere Informationen finden Sie unter Ports konfigurieren.
  - PORT_2: Der zweite Port, der an der Verbindung zwischen mehreren Zonen beteiligt ist . Weitere Informationen finden Sie unter Ports konfigurieren.
  - MTU: Der MTU-Wert, der auf alle Ports angewendet wird. Wenn keine Angabe erfolgt, beträgt der Standardwert 9.216.
  Achtung:Alle Zonen, einschließlich der aktuellen Zone, müssen im Feld zones enthalten sein.
  Hinweis:Die Zonen-ASNs müssen mit der dataASN der zugehörigen Zonen übereinstimmen.
  
  Beispiele für die Konfiguration mehrerer Zonen
4. Wenden Sie die Datei multizone_network_config.yaml auf den Cluster an:
```
kubectl apply -f multizone_network_config.yaml --kubeconfig=KUBECONFIG_PATH
```
5. Prüfen Sie, ob die MultiZonetNetworkConfig-Ressource erfolgreich erstellt wurde:
```
kubectl get multizonenetworkconfig -n gpc-system --kubeconfig=KUBECONFIG_PATH
```
  Das folgende Beispiel zeigt eine Ausgabe mit Interconnect-Verbindungen:
```
NAME                       AGE   READY
multizone-network-config   26h   True
```
6. Optional: Prüfen Sie die BGP-Konfiguration und den Status der Interconnect-Verbindung in der MultiZoneNetworkPeeringConfig-Ressource.
  
  Die eigentliche BGP-Konfiguration wird vom Netzwerk-Abstimmungsmodul festgelegt und in der MultiZoneNetworkPeeringConfig-Ressource gespeichert. Jede MultiZoneNetworkPeeringConfig-Ressource stellt alle BGP-Konfigurationen von einer Zone zur anderen dar. Beispiel:
  - Eine MultiZoneNetworkPeeringConfig-Ressource mit dem Namen zone-1-zone-2-peering-config könnte so aussehen:
```
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
```
  Der Status in diesem Beispiel enthält alle BGP-Sitzungskonfigurationen und die BGP-Sitzungsstatus von Zone 1 bis Zone 2.
  - Im L3-Carrier-Modus könnte eine MultiZoneNetworkPeeringConfig-Ressource mit dem Namen zone-1-ipv4-peering-config, die alle IPv4-BGP-Sitzungen von einer Zone zum L3-Carrier darstellt, so aussehen:
```
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 Ports konfigurieren

Die ports-Konfiguration hängt vom Typ des Mobilfunkanbieters ab. Beachten Sie beim Festlegen von ports die folgenden Regeln:

Wenn der Carrier-Typ L2 ist, müssen Sie n Ports in Spec.Ports angeben, wobei n der Anzahl der Zonen multipliziert mit zwei entspricht. Der erste Port muss mit dem ersten Border-Leaf-Switch (sortiert nach Switch-Name) der ersten Nachbarzone (sortiert nach Zonen-ID) verbunden sein. Der zweite Port muss mit dem zweiten Border-Leaf-Switch der ersten Nachbarzone verbunden sein. Der dritte Port wird mit dem ersten Border-Leaf-Switch der zweiten Nachbarzone verbunden. Weitere Verbindungen folgen diesem Muster. Eine Abbildung finden Sie unter L2-Carrier-Bereitstellung.

Wichtig :Für den L2-Carrier-Typ empfiehlt Google dringend, nicht mehr als drei Zonen zu verwenden.
Wenn der Carrier-Typ L3 ist, müssen Sie in Spec.Ports zwei Ports angeben. Beide Border-Leaf-Switches in der aktuellen Zone müssen den ersten Port verwenden, um sich einzeln mit dem ersten Provider Edge-Gerät zu verbinden, und den zweiten Port, um sich einzeln mit dem zweiten Provider Edge-Gerät zu verbinden. Weitere Informationen finden Sie unter L3-Bereitstellung durch Mobilfunkanbieter.

2.2. Beispiele für die Konfiguration mehrerer Zonen

Dieser Abschnitt enthält gängige Bereitstellungsbeispiele.

2.2.1. Bereitstellung von L2-Mobilfunkanbietern

Diese Bereitstellung hat die folgende Konfiguration:

Drei Zonen mit den ASNs 65501, 65502 und 65503
Ein L2-Carrier
Die logischen Verbindungen für diese Bereitstellung sind in diesem Diagramm dargestellt:

Wichtig :In diesem Beispiel wird ein L2-Carrier-Deployment mit drei Zonen veranschaulicht. Google empfiehlt dringend, für L2-Carrier-Typen nicht mehr als drei Zonen zu verwenden.

Hier ein Beispiel für eine MultiZoneNetworkConfig-YAML-Datei:

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

Diese Bereitstellung hat die folgende Konfiguration:

Drei Zonen mit den ASNs 65501, 65502 und 65503
L3-Carrier
Die logischen Verbindungen für diese Bereitstellung sind in diesem Diagramm dargestellt:

Hier ein Beispiel für eine MultiZoneNetworkConfig-YAML-Datei:

  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. Optional: BFD-Authentifizierung für mehrere Zonen konfigurieren

Bidirectional Forwarding Detection (BFD) ist für alle IPv4- und EVPN-Sitzungen mit mehreren Zonen konfiguriert. Standardmäßig ist BFD für einen einzelnen Hop konfiguriert. Folgen Sie der Anleitung in diesem Abschnitt, um Multi-Hop-BFD mit Authentifizierung bereitzustellen:

Aktivieren Sie die BFD-Authentifizierung (Bidirectional Forwarding Detection) für EVPN-BGP-Sitzungen mit mehreren Zonen. Damit BFD-Sitzungen eingerichtet und aktiviert werden können, müssen die gekoppelten BGP-Sitzungen in beiden Zonen mit derselben BFD-Authentifizierungsschlüssel-ID und demselben Schlüsselstring konfiguriert werden:

Definieren Sie den Schlüsseltyp. Wir empfehlen, diesen Befehl auf dem Bootstrapper-Computer auszuführen. Verwenden Sie aus Sicherheitsgründen mindestens SHA‑1 für den Schlüssel. Verwenden Sie bei Bedarf einen sichereren Schlüssel für Ihre Konfiguration:
```
export KEY_TYPE=SHA1
```
Legen Sie die Schlüssel-ID und den Schlüsselstring fest. Die Schlüssel-ID muss unter den gekoppelten Interconnect-Sitzungen in allen Zonen eindeutig sein. Legen Sie eine nicht verwendete Schlüssel-ID fest und weisen Sie sie der Variablen zu:
```
export KEY_ID=1
```

Generieren Sie mit chronyc keygen einen SHA‑1-Authentifizierungsschlüssel:

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

Beispielausgabe:

echo $CHRONY_OUTPUT
1 SHA1 HEX:887F1B88085BD0BDE4458EA7C2C4393C50A498EF

Extrahieren Sie den Authentifizierungsschlüssel und bestätigen Sie ihn:

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

echo $KEY_STR
887F1B88085BD0BDE4458EA7C2C4393C50A498EF

Wenden Sie die BFD-Authentifizierungsinformationen auf die ausgewählten Interconnect-Sitzungen an:

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}"'"
  }
}'

Prüfen Sie, ob die BFD-Sitzung ausgeführt wird:
```
switch# show bfd neighbors vrf default
```

Prüfen Sie, ob das Feld State den Wert Up und das Feld Type den Wert SH oder MH hat:

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 Optional: BGP-Passwort für mehrere Zonen konfigurieren

Es gibt zwei Arten von Border Gateway Protocol-Passwörtern (BGP): das IPv4-BGP-Sitzungspasswort und das EVPN-BGP-Sitzungspasswort.

Standardmäßig sind alle BGP-Passwörter leer. Folgen Sie der Anleitung in diesem Abschnitt, um die Passwörter zu aktualisieren.

2.4.1. IPv4-BGP-Passwort aktualisieren

Wenn ein L2-Carrier verwendet wird, aktualisieren Sie das IPv4-BGP-Passwort, das auf die IPv4-BGP-Sitzung zwischen einem Border-Leaf-Switch in der aktuellen Zone und einem anderen Border-Leaf-Switch in einer anderen Zone angewendet wird:

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"}}'

Ersetzen Sie Folgendes:

LOCAL_ZONE_ID: Die numerische ID der aktuellen Zone.
LOCAL_BLSW_ID: Die numerische ID des Border-Leaf-Switches der aktuellen Zone. Dieser Wert muss 1 oder 2 sein.
REMOTE_ZONE_ID: Die numerische ID der Remote-Zone.
REMOTE_BLSW_ID: Die numerische ID des Border-Leaf-Switches der Remote-Zone. Dieser Wert muss 1 oder 2 sein.
PASSWORD: Das BGP-Passwort, das auf die IPv4-BGP-Sitzung zwischen dem lokalen Border-Leaf-Switch und dem Remote-Border-Leaf-Switch angewendet wird.

Wenn ein L3-Netzbetreiber verwendet wird, aktualisieren Sie das IPv4-BGP-Passwort, das auf die IPv4-BGP-Sitzung zwischen einem Border-Leaf-Switch in der aktuellen Zone und einem Provider-Edge-Gerät im L3-Netzbetreiber angewendet wird:

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

Ersetzen Sie Folgendes:

LOCAL_ZONE_ID: Die numerische ID der aktuellen Zone.
LOCAL_BLSW_ID: Die numerische ID des Border-Leaf-Switches der aktuellen Zone. Dieser Wert muss 1 oder 2 sein.
PORT_ID: Der Index des Ethernet-Ports, der mit dem Provider Edge-Gerät verbunden ist.
PASSWORD: Das BGP-Passwort, das auf die IPv4-BGP-Sitzung zwischen dem lokalen Border-Leaf-Switch und dem Provider Edge-Gerät angewendet wird.

2.4.2. EVPN-BGP-Passwort aktualisieren

So aktualisieren Sie das EVPN-BGP-Passwort, das auf die EVPN-BGP-Sitzung zwischen einem Border-Leaf-Switch in der aktuellen Zone und einem anderen Border-Leaf-Switch in einer anderen Zone angewendet wird:

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

Ersetzen Sie Folgendes:

LOCAL_ZONE_ID: Die numerische ID der aktuellen Zone.
LOCAL_BLSW_ID: Die numerische ID des Border-Leaf-Switches der aktuellen Zone. Dieser Wert muss 1 oder 2 sein.
REMOTE_ZONE_ID: Die numerische ID der Remote-Zone.
REMOTE_BLSW_ID: Die numerische ID des Border-Leaf-Switches der Remote-Zone. Dieser Wert muss 1 oder 2 sein.
PASSWORD: Das BGP-Passwort, das auf die EVPN-BGP-Sitzung zwischen dem lokalen Border-Leaf-Switch und dem Remote-Border-Leaf-Switch angewendet wird.

3. Erweiterte Konfigurationsoptionen

In diesem Abschnitt werden erweiterte Konfigurationsoptionen vorgestellt, die von den Multi-Zone-Netzwerk-APIs bereitgestellt werden.

3.1 BGP-Konfigurationsüberschreibung für Mobilfunkanbieter konfigurieren

Standardmäßig stellen Border-Leaf-Switches BGP-Peering-Verbindungen zu PE-Geräten des Carriers über eine Standard-IP-Adresszuweisung her. Die verwendete BGP-Peering-IP-Adresse finden Sie in der MultiZoneNetworkPeeringConfig-Ressource zone-<ZONE_ID>-ipv4-peering-config. Beispiel:

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

Wenn Sie einen benutzerdefinierten IP-Adressplan verwenden möchten, überschreiben Sie die standardmäßige BGP-Konfiguration des Mobilfunkanbieters. Gehen Sie dazu so vor:

Führen Sie kubectl edit MultiZoneNetworkPeeringConfig zone-<ZONE_ID>-ipv4-peering-config -n gpc-system aus und fügen Sie den Abschnitt carrierBGPConfigOverride unter spec.Peerings hinzu. Beispiel:

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 diesem Beispiel wird durch die Angabe von carrierBGPConfigOverride.peeringIP das Peering-Subnetz auf 192.168.78.4/31 überschrieben.

3.2 Portüberschreibung konfigurieren

Google empfiehlt, dass alle Border-Leaf-Switches in allen Zonen dieselben Ports verwenden. Diese Portkonfiguration ist in Szenarien nützlich, in denen eine detaillierte Steuerung der Ports erforderlich ist.

Die lokale Zone ist die Zone, die Sie bereitstellen.

Die Remote-Zonen sind andere Zonen innerhalb desselben Multizonen-Universums.

Standardmäßig müssen Sie für die beiden Border-Leaf-Switches einer Zone dieselben Ports verwenden, um eine Verbindung zu einer anderen Zone oder zum Mobilfunkanbieter herzustellen. Sie können jedoch die Option zum Überschreiben des Ports aktivieren, um einen anderen Port für diese Verbindung zwischen Zonen anzugeben.

So konfigurieren Sie die Portüberschreibungsfunktion:

Aktivieren Sie die Funktion portOverride:

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

Identifizieren Sie den Leaf-Switch an der Grenze der lokalen Zone und den Leaf-Switch an der Grenze der Remote-Zone und ändern Sie den Port des Leaf-Switch an der Grenze der lokalen Zone:

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

Ersetzen Sie Folgendes:

ZONE_1_ID: Die kleinere Zonen-ID zwischen der lokalen Zonen-ID und der Remote-Zonen-ID. Wenn die lokale Zonen-ID beispielsweise 1 und die Remote-Zonen-ID 2 lautet, geben Sie hier den Wert 1 an.
ZONE_2_ID: Die größere Zonen-ID zwischen der lokalen Zonen-ID und der Remote-Zonen-ID.

Eine MultiZoneNetworkPeeringConfig-Ressource könnte so aussehen:

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

Sie müssen den Portwert eines der Border-Leaf-Switches aktualisieren, aus denen das Peering zwischen Zonen besteht. Suchen Sie im Feld Spec.peerings nach dem zonenübergreifenden Peering. Im Beispiel haben wir diese Peer-Verbindung zwischen Zone 2 und Zone 3:

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

Die Ausgabe zeigt zwei Border-Leaf-Switches, die durch blswID: 1 und blswID: 2 identifiziert werden. Aktualisieren Sie für den ersten Border-Leaf-Switch, der durch blswID: 1 identifiziert wird, den Port auf den neuen Wert 20:

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

Im Beispiel aktualisieren wir den Portwert des ersten Border-Leaf-Switches auf port: 20.