In diesem Abschnitt werden die Schritte nach der Installation und die Schritte zur Überprüfung der Installation erläutert.

Wenn bei der Installation alles erwartungsgemäß funktioniert hat, können Sie sich jetzt bei der VM anmelden.

  1. Wenn alles wie erwartet funktioniert, sollte Ihnen jetzt die Anmeldeaufforderung in der Konsole angezeigt werden. Ihnen sollte der Aufforderungsname wie in Cloud-init angegeben angezeigt werden.

  2. Informationen dazu finden Sie auch unter /run/cloud-init/result.json. Wenn die folgende Meldung angezeigt wird, wird Cloud-init wahrscheinlich erfolgreich ausgeführt.

  3. Überprüfen Sie, ob SD-WAN Gateway bei SD-WAN Orchestrator registriert ist.

    vcg-is-registered-with-vco

  4. Überprüfen Sie die externe Konnektivität.

    vcg-code-verify-outside-connectivity

  5. Stellen Sie sicher, dass MGMT VRF auf ARPs reagiert.

    vcg-code-verify-mgmt-vrf

  6. Optional: Deaktivieren Sie Cloud-init, damit es nicht bei jedem Startvorgang ausgeführt wird.
    Hinweis: Wenn Sie OVA auf VMware vSphere mit vApp-Eigenschaften bereitgestellt haben, müssen Sie Cloud-init vor dem Upgrade auf die Version 4.0.1 oder 4.1.0 deaktivieren. Dadurch wird sichergestellt, dass die Anpassungseinstellungen wie z. B. die Netzwerkkonfiguration oder das Kennwort während des Upgrades nicht verloren gehen.
    touch /etc/cloud/cloud-init.disabled
  7. Ordnen Sie den neuen Gateway-Pool dem Kunden zu.

  8. Ordnen Sie das Gateway einem Edge zu.

    vcg-associate-gateway-with-edge

  9. Stellen Sie sicher, dass der Edge in der Lage ist, einen Tunnel mit dem Gateway auf der Internetseite einzurichten. Navigieren Sie in VMware SD-WAN Orchestrator zu Überwachen (Monitor) > Edges > Übersicht (Overview).

    Navigieren Sie in VMware SD-WAN Orchestrator zu Testen und Fehlerbehebung (Test & Troubleshoot) > Remote-Diagnose (Remote Diagnostics) > [Edge] > Pfade auflisten (List Paths) und klicken Sie auf Ausführen (Run), um die Liste der aktiven Pfade anzuzeigen.

  10. Konfigurieren Sie die Übergabeschnittstelle.

    vcg-configure-handoff-interface

  11. Stellen Sie sicher, dass die BGP-Sitzung aktiv ist.

    vcg-verify-bgp-session-is-up

  12. Ändern Sie die Netzwerkkonfiguration.

    Netzwerkkonfigurationsdateien befinden sich unter „/etc/netplan“.

    Beispielnetzwerkkonfiguration (Leerzeichen sind wichtig!) – /etc/netplan/50-cloud-init.yaml:
    network: 
      version: 2 
      ethernets: 
        eth0: 
          addresses: 
            - 192.168.151.253/24 
          gateway4: 192.168.151.1 
          nameservers: 
            addresses: 
              - 8.8.8.8 
              - 8.8.4.4 
            search: [] 
          routes: 
            - to: 192.168.0.0/16 
              via: 192.168.151.254 
              metric: 100 
        eth1: 
          addresses: 
            - 192.168.152.251/24 
          gateway4: 192.168.152.1 
          nameservers: 
            addresses: 
              - 8.8.8.8 
            search: []
Wichtig: Wenn Cloud-init aktiviert ist, wird die Netzwerkkonfiguration bei jedem Startvorgang neu generiert. Wenn Sie Änderungen an der Standortkonfiguration vornehmen möchten, deaktivieren Sie Cloud-init oder deaktivieren Sie die Netzwerkkonfigurationskomponente von Cloud-init:
echo 'network: {config: disabled}' > /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg 

Konfigurieren der Übergabeschnittstelle in der Datenebene

VMware SD-WAN Gateway – Netzwerkkonfiguration

Im Beispiel mit der folgenden Abbildung (VRF-/VLAN-Übergabe an PE) wird davon ausgegangen, dass eth0 als Schnittstelle für das öffentliche Netzwerk (Internet) und eth1 als Schnittstelle für das interne Netzwerk (Kunden-VRF über PE) fungiert. Die BGP-Peering-Konfiguration wird auf dem VCO pro Kunde/VRF unter „Konfigurieren (Configure) > Kunde (Customer)“ verwaltet. Beachten Sie, dass die IP-Adresse aller VRFs pro Kunde konfigurierbar ist. Die IP-Adresse der Verwaltungs-VRF erbt die auf der SD-WAN Gateway-Schnittstelle in Linux konfigurierte IP-Adresse.

Eine Verwaltungs-VRF wird auf dem SD-WAN Gateway erstellt und zum Senden periodischer ARP-Aktualisierungen an die Standard-Gateway-IP verwendet, um die MAC des nächsten Hops zu ermitteln. Es wird empfohlen, für diesen Zweck eine dedizierte VRF im PE-Router einzurichten. Dieselbe Verwaltungs-VRF kann auch vom PE-Router zum Senden eines IP-SLA-Tests an das SD-WAN Gateway verwendet werden, um den Status des SD-WAN Gateways zu überprüfen (SD-WAN Gateway verfügt über einen statusbehafteten ICMP-Responder, der nur bei entsprechend aktiviertem Dienst auf Ping reagiert). BGP-Peering ist auf der Verwaltungs-VRF nicht erforderlich. Wenn keine Verwaltungs-VRF eingerichtet wurde, können Sie eine der Kunden-VRFs als Verwaltungs-VRF verwenden. Dies wird jedoch nicht empfohlen.

Schritt 1: Bearbeiten von „/etc/config/gateway“ und Angeben der korrekten VCMP- und WAN-Schnittstelle. Die VCMP-Schnittstelle ist die öffentliche Schnittstelle, die die Overlay-Tunnel beendet. In diesem Kontext handelt es sich bei der WAN-Schnittstelle um die Übergabeschnittstelle.
      "vcmp.interfaces":[
                   "eth0"
               ], 
         (..snip..)

               "wan": [
                   "eth1"
               ],

Schritt 2: Konfigurieren der Verwaltungs-VRF. Diese VRF wird vom SD-WAN-Gateway zu ARP für die MAC (PE-Router) des nächsten Hops verwendet. Dieselbe MAC des nächsten Hops wird von allen vom SD-WAN Gateway erstellten VRFs verwendet. Sie müssen den Verwaltungs-VRF-Parameter in „/etc/config/gatewayd“ konfigurieren.

Die Verwaltungs-VRF ist dieselbe VRF, die vom PE-Router zum Senden des IP-SLA-Tests verwendet wird. Das SD-WAN Gateway reagiert nur dann auf den ICMP-Test, wenn der Dienst aktiv ist und Edges mit diesem Dienst verbunden sind. In der folgenden Tabelle werden alle Parameter erläutert, die definiert werden müssen. Dieses Beispiel weist Verwaltungs-VRF auf der 802.1q VLAN-ID von 1000 auf.

mode QinQ (0x8100), QinQ (0x9100), keine, 802.1Q, 802.1ad
c_tag C-Tag-Wert für QinQ-Kapselung oder 802.1Q-VLAN-ID für 802.1Q-Kapselung
s_tag S-Tag-Wert für die QinQ-Kapselung
interface Übergabeschnittstelle, in der Regel eth1
      "vrf_vlan": {
          "tag_info": [
             {
                 "resp_mode": 0,
                 "proxy_arp": 0,
                 "c_tag": 1000, 
                 "mode": "802.1Q",
                 "interface": "eth1",
                 "s_tag": 0
             }
          ]
      },

Schritt 3: Bearbeiten Sie „/etc/config/gatewayd-tunnel“, um beide Schnittstellen in den WAN-Parameter aufzunehmen. Speichern Sie die Änderung.

wan="eth0 eth1"

Entfernen blockierter Subnetze

Standardmäßig blockiert das SD-WAN Gateway den Datenverkehr zu 10.0.0.0/8 und 172.16.0.0/14. Diese müssen vor der Verwendung dieses SD-WAN Gateways entfernt werden, da SD-WAN Gateway erwartungsgemäß auch Datenverkehr an private Subnetze sendet. Wenn Sie diese Datei nicht bearbeiten und versuchen, Datenverkehr an blockierte Subnetze zu senden, werden die folgenden Meldungen in der Datei „/var/log/gwd.log“ angezeigt

2015-12-18T12:49:55.639  ERR     [NET] proto_ip_recv_handler:494 Dropping packet destined for
10.10.150.254, which is a blocked subnet.
2015-12-18T12:52:27.764  ERR     [NET] proto_ip_recv_handler:494 Dropping packet destined for 
10.10.150.254, which is a blocked subnet. [message repeated 48 times]
2015-12-18T12:52:27.764  ERR     [NET] proto_ip_recv_handler:494 Dropping packet destined for 
10.10.150.10, which is a blocked subnet.
Schritt 1: Bearbeiten Sie die Datei „/opt/vc/etc/vc_blocked_subnets.json“ auf dem SD-WAN Gateway. Sie werden feststellen, dass diese Datei zunächst Folgendes enthält.
[
            {
                        "network_addr": "10.0.0.0",
                        "subnet_mask": "255.0.0.0"
            },
            {
            "network_addr": "172.16.0.0",
            "subnet_mask": "255.255.0.0"
            }
]
Schritt 2: Entfernen Sie die beiden Netzwerke. Die Datei sollte nach der Bearbeitung wie folgt aussehen. Speichern Sie die Änderung.
[
]

Schritt 3: Starten Sie den SD-WAN Gateway-Prozess mit „sudo /opt/vc/bin/vc_procmon“ neu.