Traffic-Verwaltung für regionale externe Application Load Balancer einrichten

Dieses Dokument enthält für bestimmte Anwendungsfälle Beispiele für die Verwendung der Trafficverwaltung. Darüber hinaus sind noch weitere Anwendungsfälle möglich.

Das Dokument enthält Beispiele für globale externe Application Load Balancer. Globale externe Application Load Balancer verwenden das Load-Balancing-Schema EXTERNAL_MANAGED und globale Load-Balancing-Komponenten wie Weiterleitungsregel, URL-Zuordnung und Backend-Dienst.

Informationen zur Traffic-Verwaltung mit einem klassischen Application Load Balancer finden Sie in der Übersicht zur Traffic-Verwaltung für einen klassischen Application Load Balancer.

Informationen zur Traffic-Verwaltung mit globalen externen Application Load Balancern finden Sie in der Übersicht zur Traffic-Verwaltung für globale externe Application Load Balancer.

Zusätzlich zu den auf dieser Seite beschriebenen erweiterten Routingfunktionen sind bestimmte Anwendungs-Load-Balancer in Diensterweiterungen eingebunden, damit Sie benutzerdefinierte Logik in den Load-Balancing-Datenpfad einfügen können, indem Sie Dienst-Erweiterungs-Callouts konfigurieren.

Hinweise

Machen Sie sich mit der Funktionsweise der Trafficverwaltung vertraut. Weitere Informationen finden Sie in der Übersicht zur Traffic-Verwaltung für globale externe Application Load Balancer.

Traffic-Verwaltung konfigurieren und testen

In der ausgewählten Konfigurationsumgebung richten Sie die Trafficverwaltung mithilfe von YAML-Konfigurationen ein. Eine URL-Zuordnung und ein Backend-Dienst haben jeweils eine eigene YAML-Datei. Je nach gewünschter Funktion muss entweder eine YAML-Datei für eine URL-Zuordnung, eine YAML-Datei für einen Backend-Dienst oder beides geschrieben werden.

Wenn Sie Hilfe beim Schreiben dieser YAML-Dateien benötigen, können Sie die Beispiele auf dieser Seite und die Cloud Load Balancing API-Dokumentation verwenden.

Die Google Cloud Console wird nicht unterstützt.

Die Dokumentation zur globalen URL Map API und zur globalen Back End Service API enthält eine vollständige Liste der Felder, einschließlich der Semantik in Bezug auf Beziehungen, Einschränkungen und Kardinalität.

Sie können einer URL-Zuordnung Konfigurationstests hinzufügen, damit Ihre URL-Zuordnung Anfragen wie vorgesehen weiterleitet. Sie können mit verschiedenen URL-Zuordnungsregeln experimentieren und so viele Tests wie nötig ausführen, damit die Zuordnung den Traffic an den entsprechenden Back-End-Dienst oder Back-End-Bucket weiterleitet. Weitere Informationen finden Sie unter Tests zu einer URL-Zuordnung hinzufügen. Wenn Sie Änderungen an einer URL-Zuordnung testen möchten, ohne die Karte tatsächlich bereitzustellen, finden Sie weitere Informationen unter Konfiguration der URL-Zuordnung prüfen.

Traffic einem einzelnen Dienst zuordnen

Der gesamte Traffic wird an einen einzelnen Dienst gesendet. Achten Sie darauf, dass Sie die Platzhalter ersetzen.

    defaultService: global/backendServices/BACKEND_SERVICE_1
    hostRules:
    - hosts:
      - '*'
      pathMatcher: matcher1
    name: URL_MAP_NAME
    pathMatchers:
    - defaultService: global/backendServices/BACKEND_SERVICE_1
      name: matcher1
      routeRules:
      - matchRules:
        - prefixMatch: /PREFIX
        priority: PRIORITY  # 0 is highest
        routeAction:
          weightedBackendServices:
          - backendService: global/backendServices/BACKEND_SERVICE_1
            weight: 100

Traffic auf zwei Dienste aufteilen

Teilen Sie Traffic auf zwei oder zwischen mehreren Diensten auf. Achten Sie darauf, dass Sie die Platzhalter ersetzen.

   defaultService: global/backendServices/BACKEND_SERVICE_1
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   name: URL_MAP_NAME
   pathMatchers:
   - defaultService: global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
     - matchRules:
       - prefixMatch: /PREFIX
       priority: 2
       routeAction:
         weightedBackendServices:
         - backendService: global/backendServices/BACKEND_SERVICE_1
           weight: 95
         - backendService: global/backendServices/BACKEND_SERVICE_2
           weight: 5

URL-Weiterleitung konfigurieren

Im folgenden Beispiel wird ein konfigurierbarer 3xx-Antwortcode zurückgegeben. Außerdem wird der Antwortheader Location mit dem entsprechenden URI festgelegt, wobei der Host und der Pfad wie in der Weiterleitungsaktion angegeben ersetzt werden.

   defaultService: global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         urlRedirect:
           hostRedirect: "new-host-name.com" # Omit to keep the requested host
           pathRedirect: "/new-path" # Omit to keep the requested path; mutually exclusive to prefixRedirect
           prefixRedirect: "/newPrefix" # Omit to keep the requested path; mutually exclusive to pathRedirect
           redirectResponseCode: FOUND
           stripQuery: True

Trafficspiegelung

Zusätzlich zur Weiterleitung der Anfrage an den ausgewählten Backend-Dienst können Sie eine identische Anfrage an den konfigurierten Spiegel-Backend-Dienst auf Fire-and-Forget-Basis senden. Der Load-Balancer wartet nicht auf eine Antwort vom Backend, an den die gespiegelte Anfrage gesendet wird. Die Spiegelung ist hilfreich zum Testen einer neuen Version eines Backend-Dienstes. Sie können die Spiegelung auch verwenden, um Produktionsfehler in einer Debugversion Ihres Backend-Dienstes anstatt in der Produktionsversion zu beheben.

   defaultService: global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: global/backendServices/BACKEND_SERVICE_1
               weight: 100
           requestMirrorPolicy:
             backendService: global/backendServices/BACKEND_SERVICE_2

Die Trafficspiegelung wird für Folgendes unterstützt:

  • Verwaltete Instanzgruppen, zonale NEGs und hybride NEGs-Back-Ends. Für Internet-NEGs, serverlose NEGs und Private Service Connect-Back-Ends wird es nicht unterstützt.
  • HTTP-Anfragen ohne Textkörper.

Die Spiegelung kann nicht nur für einen bestimmten Teil der Anfragen konfiguriert werden. Auch wenn Sie den Traffic auf mehrere gewichtete Backend-Dienste aufteilen, erhält der Spiegel-Backend-Dienst alle Anfragen. Sie können jedoch benutzerdefinierte Header verwenden, um aufzuzeichnen, welcher Backend-Dienst für die ursprüngliche Anfrage verwendet wurde. Im folgenden Beispiel wird allen Clientanfragen ein benutzerdefinierter Header mit dem Namen x-weighted-picked-backend hinzugefügt. Verwenden Sie für den Headerwert den Namen des Backend-Dienstes, von dem die ursprüngliche Anfrage verarbeitet wurde.

   defaultService: global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
            - backendService: global/backendServices/BACKEND_SERVICE_1
              weight: 95
              headerAction:
                requestHeadersToAdd:
                - headerName: x-weighted-picked-backend
                  headerValue: BACKEND_SERVICE_1
                  replace: True
            - backendService: global/backendServices/BACKEND_SERVICE_2
              weight: 5
              headerAction:
                requestHeadersToAdd:
                - headerName: x-weighted-picked-backend
                  headerValue: BACKEND_SERVICE_2
                  replace: True
           requestMirrorPolicy:
             backendService: global/backendServices/BACKEND_SERVICE_3

Angeforderte URL umschreiben

Der Teil der URL mit dem Hostnamen, dem Pfad oder beide werden umgeschrieben, bevor eine Anfrage an den ausgewählten Backend-Dienst gesendet wird. Achten Sie darauf, dass Sie die Platzhalter ersetzen.

   defaultService: global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: global/backendServices/BACKEND_SERVICE_1
               weight: 100
           urlRewrite:
             hostRewrite: "new-host-name.com" # Omit to keep the requested host
             pathPrefixRewrite: "/new-path/" # Omit to keep the requested path

Anfrage wiederholen

Die Bedingungen, unter denen der Load-Balancer fehlgeschlagene Anfragen wiederholt, die Wartezeit des Load-Balancers bis zum Neuversuch sowie die maximal zulässige Anzahl von Wiederholungsversuchen werden konfiguriert.

   defaultService: global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: global/backendServices/BACKEND_SERVICE_1
               weight: 100
           retryPolicy:
             retryConditions: 502, 504
             numRetries: 3
             perTryTimeout:
               seconds: 1
               nanos: 500000000

Routenzeitlimit angeben

Gibt die Zeitüberschreitung für die ausgewählte Route an. Das Zeitlimit wird ab der vollständigen Verarbeitung der Anfrage bis zur vollständigen Verarbeitung der Antwort berechnet. Das Zeitlimit umfasst alle Wiederholungen. Achten Sie darauf, dass Sie die Platzhalter ersetzen.

   defaultService: global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: global/backendServices/BACKEND_SERVICE_1
               weight: 100
           timeout:
             seconds: 30
             nanos: 0

Fehlerinjektion konfigurieren

Fehler können in die Verarbeitung von Anfragen eingebracht werden, um Störungen zu simulieren, einschließlich hoher Latenz, Dienstüberlastung, Dienstfehlern und Netzwerkpartitionierung. Dieses Feature ist hilfreich, um die Ausfallsicherheit eines Diensts gegenüber simulierten Störungen zu testen.

   defaultService: global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: global/backendServices/BACKEND_SERVICE_1
               weight: 100
           faultInjectionPolicy:
             delay:
               fixedDelay:
                 seconds: 10
                 nanos: 0
               percentage: 25
             abort:
               httpStatus: 503
               percentage: 50

CORS konfigurieren

Richtlinien werden für Cross-Origin Resource Sharing (CORS) konfiguriert, um Einstellungen für die Durchsetzung von CORS-Anfragen zu verarbeiten.

   defaultService: global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: global/backendServices/BACKEND_SERVICE_1
               weight: 100
           corsPolicy:
               allowOrigins: [ "http://my-domain.com" ]
               allowMethods: [ "GET", "POST" ]
               allowHeaders: [ "Authorization", "Content-Type" ]
               maxAge: 1200
               allowCredentials: true

Anfrage- und Antwortheader hinzufügen und entfernen

Fügen Sie Anfrageheader hinzu und entfernen Sie sie, bevor Sie eine Anfrage an den Backend-Service senden. Außerdem können Antwort-Header hinzugefügt oder entfernt werden, nachdem eine Antwort vom Backend-Dienst empfangen wurde.

Für headerName und headerValue gelten Einschränkungen für gültige Werte. Weitere Informationen finden Sie unter Funktionsweise benutzerdefinierter Header.

   defaultService: global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: global/backendServices/BACKEND_SERVICE_1
               headerAction:
                 requestHeadersToAdd:
                 - headerName: header-1-name
                   headerValue: header-1-value
                   replace: True
                 requestHeadersToRemove:
                 - header-2-name
                 - header-3-name
                 responseHeadersToAdd:
                 - headerName: header-4-name
                   headerValue: header-4-value
                   replace: True
                responseHeadersToRemove:
                - header-5-name
                - header-6-name

Ausreißererkennung konfigurieren

Kriterien für das Entfernen fehlerhafter Backend-VMs oder Endpunkte in NEGs werden festgelegt sowie die Kriterien dafür, wann ein Backend oder Endpunkt als stabil genug gilt, um wieder Traffic zu empfangen. Achten Sie darauf, dass Sie die Platzhalter ersetzen.

    loadBalancingScheme: EXTERNAL_MANAGED
    localityLbPolicy: RANDOM
    name: global/backendServices/BACKEND_SERVICE_1
    outlierDetection:
      baseEjectionTime:
        nanos: 0
        seconds: 30
      consecutiveErrors: 5
      consecutiveGatewayFailure: 3
      enforcingConsecutiveErrors: 2
      enforcingConsecutiveGatewayFailure: 100
      enforcingSuccessRate: 100
      interval:
        nanos: 0
        seconds: 1
      maxEjectionPercent: 50
      successRateMinimumHosts: 5
      successRateRequestVolume: 100
      successRateStdevFactor: 1900

Trafficaufteilung einrichten: detaillierte Schritte

In diesem Beispiel werden die folgenden Schritte veranschaulicht:

  1. Unterschiedliche Vorlagen für verschiedene Dienste erstellen

  2. Instanzgruppen für diese Vorlagen erstellen

  3. Routingregeln erstellen, die 95 % bzw. 5 % Trafficteilung einrichten

  4. curl-Befehle senden, mit denen Sie prüfen, ob die Prozentwerte für die Trafficaufteilung ungefähr der Konfiguration entsprechen

Bei dieser Anleitung wird Folgendes vorausgesetzt:

  • Ein Zielproxy und eine Weiterleitungsregel wurden zusammen mit einer URL-Zuordnung mit dem Namen global-lb-map erstellt.

  • Die URL-Zuordnung sendet den gesamten Traffic an einen Backend-Dienst mit dem Namen red-service. Dies ist der Standard-Backend-Dienst.

  • Sie haben einen alternativen Pfad eingerichtet, der 5 % des Traffics an blue-service und 95 % des Traffics an green-service sendet.

  • Es wird ein Pfad-Abgleichstool verwendet.

  • Sie verwenden Cloud Shell oder eine andere Umgebung, in der bash installiert ist.

Dienste definieren

Die folgende bash-Funktion erstellt einen Backend-Dienst, einschließlich der Instanzvorlage und der verwalteten Instanzgruppe.

Bei dieser Anleitung wird davon ausgegangen, dass eine HTTP-Systemdiagnose (global-lb-basic-check) erstellt wurde. Eine Anleitung finden Sie auf einer der folgenden Seiten:

function make_service() {
  local name="$1"
  local region="$2"
  local zone="$3"
  local network="$4"
  local subnet="$5"
  local subdir="$6"

  www_dir="/var/www/html/$subdir"

  (set -x; \
  gcloud compute instance-templates create "${name}-template" \
    --region="$region" \
    --network="$network" \
    --subnet="$subnet" \
    --tags=allow-ssh,load-balanced-backend \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --metadata=startup-script="#! /bin/bash
  apt-get update
  apt-get install apache2 -y
  a2ensite default-ssl
  a2enmod ssl
  sudo mkdir -p $www_dir
  /bin/hostname | sudo tee ${www_dir}index.html
  systemctl restart apache2"; \
  gcloud compute instance-groups managed create \
    "${name}-instance-group" \
    --zone="$zone" \
    --size=2 \
    --template="${name}-template"; \
  gcloud compute backend-services create "${name}-service" \
    --load-balancing-scheme=EXTERNAL_MANAGED \
    --protocol=HTTP \
    --health-checks=global-lb-basic-check \
    --global \
  gcloud compute backend-services add-backend "${name}-service" \
    --balancing-mode='UTILIZATION' \
    --instance-group="${name}-instance-group" \
    --instance-group-zone="$zone" \
    --global)
}

Erstellen Sie die Dienste:

Rufen Sie die Funktion auf, um drei Dienste zu erstellen: red, green und blue. Der Dienst red dient als Standarddienst für Anfragen an /. Die Dienste green und blue werden beide unter /prefix für 95 % bzw. 5 % des Traffics eingerichtet.

make_service red us-west1 us-west1-a lb-network backend-subnet ""
make_service green us-west1 us-west1-a lb-network backend-subnet /prefix
make_service blue us-west1 us-west1-a lb-network backend-subnet /prefix

URL-Zuordnung erstellen

Console

  1. Öffnen Sie in der Google Cloud Console die Seite Load-Balancing.
    Gehe zu „Load-Balancing“
  2. Klicken Sie auf den Link global-lb-map.
  3. Klicken Sie auf Bearbeiten .

Neue Routingregeln konfigurieren

  1. Wählen Sie unter Routingregeln die Option Erweiterte Host-, Pfad- und Routeregel aus.
  2. Erstellen Sie unter Tool zum Abgleich von neuen Hosts und Pfaden die Standardaktion. Setzen Sie dazu den Dienst auf red-service.
  3. Klicken Sie auf Fertig.
  4. Klicken Sie auf Tool zum Abgleich von Hosts und Pfaden hinzufügen.
  5. Geben Sie im Feld Hosts die IP-Adresse der Weiterleitungsregel Ihres Load-Balancers ein.

  6. Fügen Sie den folgenden YAML-Inhalt in das Feld Pfad-Matcher ein:

    defaultService: global/backendServices/red-service
name: matcher1
routeRules:
- priority: 2
  matchRules:
    - prefixMatch: /PREFIX
  routeAction:
    weightedBackendServices:
      - backendService: global/backendServices/green-service
        weight: 95
      - backendService: global/backendServices/blue-service
        weight: 5

  7. Klicken Sie auf Fertig.

  8. Klicken Sie auf Aktualisieren.

gcloud

  1. Exportieren Sie die vorhandene URL-Zuordnung mit dem Befehl gcloud compute url-maps export:

    gcloud compute url-maps export global-lb-map \
  --destination=global-lb-map-config.yaml \
  --global

  2. Aktualisieren Sie die URL-Zuordnungsdatei global-lb-map-config.yaml. Fügen Sie dazu Folgendes am Ende der Datei hinzu:

    hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
pathMatchers:
- defaultService: global/backendServices/red-service
  name: matcher1
  routeRules:
  - priority: 2
    matchRules:
      - prefixMatch: /PREFIX
    routeAction:
      weightedBackendServices:
        - backendService: global/backendServices/green-service
          weight: 95
        - backendService: global/backendServices/blue-service
          weight: 5

  3. Aktualisieren Sie mit dem Befehl gcloud compute url-maps import die URL-Zuordnung:

    gcloud compute url-maps import global-lb-map \
   --global \
   --source=global-lb-map-config.yaml

Konfiguration testen

Testen Sie die Konfiguration. Achten Sie als Erstes darauf, dass Anfragen an die IP-Adresse des Load-Balancers, die zuvor eingerichtet wurde, von der Standardkonfiguration red verarbeitet werden.

Prüfen Sie dann, ob an FORWARDING_RULE_IP_ADDRESS/prefix gesendete Anfragen wie erwartet aufgeteilt werden.

Mit der Trafficsteuerung können Sie die Sitzungsaffinität anhand eines bereitgestellten Cookies konfigurieren. In diesem Beispiel wird eine auf HTTP_COOKIE basierende Sitzungsaffinität für einen Backend-Dienst mit dem Namen red-service konfiguriert.

  1. Verwenden Sie den Befehl gcloud compute backend_services export, um die Konfiguration des Backend-Dienstes abzurufen.

    gcloud compute backend-services export red-service \
    --destination=red-service-config.yaml \
    --global

  2. Aktualisieren Sie die Datei red-service-config.yaml so:

    sessionAffinity: 'HTTP_COOKIE'
localityLbPolicy: 'RING_HASH'
consistentHash:
 httpCookie:
  name: 'http_cookie'
  path: '/cookie_path'
  ttl:
    seconds: 100
    nanos: 0
 minimumRingSize: 10000

  3. Fügen Sie in der Datei red-service-config.yaml die folgende Zeile ein:

    sessionAffinity: NONE

  4. Aktualisieren Sie die Konfigurationsdatei für den Backend-Dienst:

    gcloud compute backend-services import red-service \
    --source=red-service-config.yaml \
    --global

Fehlerbehebung

Gehen Sie nach den hier beschriebenen Informationen zur Fehlerbehebung vor, wenn der Traffic nicht gemäß den von Ihnen konfigurierten Routingregeln und Trafficrichtlinien weitergeleitet wird.

Informationen zu Logging und Monitoring finden Sie unter Externes HTTP(S)-Logging und -Monitoring.

Symptome:

  • Vermehrter Traffic an Dienste in Regeln über der betreffenden Regel
  • Unerwartet vermehrte 4xx- und 5xx-HTTP-Antworten für eine bestimmte Routingregel

Lösung: Überprüfen Sie die Reihenfolge Ihrer Routingregeln. Routingregeln werden in der Reihenfolge interpretiert, in der sie angegeben sind.

Routingregeln innerhalb einer URL-Zuordnung werden in der Reihenfolge ihrer Angabe interpretiert. Pfadregeln hingegen werden nach Abgleich mit dem längsten Präfix interpretiert. Bei einer Pfadregel wählt der globale externe Application Load Balancer nur eine einzelne Pfadregel aus. Wenn Sie jedoch Routingregeln verwenden, gelten möglicherweise mehrere.

Achten Sie beim Definieren von Routingregeln darauf, dass die Regeln oben in der Liste nicht versehentlich Traffic weiterleiten, der andernfalls von einer nachfolgenden Routingregel weitergeleitet worden wäre. Der Dienst, der fehlgeleiteten Traffic empfängt, würde wahrscheinlich Anfragen ablehnen. Der Dienst in Ihren Routenregeln würde weniger oder keinen Traffic erhalten.

Nächste Schritte