Dieses Dokument enthält eine Anleitung für ein Upgrade des VMware-Partner-Gateways von Version 3.3.2 oder 3.4 auf Version 4.0.

Version 4.0 der SD-WAN Gateway-Appliance enthält die folgenden Änderungen:

  • Ein neues Systemfestplattenlayout, das auf LVM basiert, um mehr Flexibilität bei der Volume-Verwaltung zu ermöglichen
  • Eine neue Kernel-Version
  • Neue und aktualisierte Basis-Betriebssystempakete
  • Verbesserte Sicherheitshärtung basierend auf Benchmarks des Center for Internet Security
Version 4.0 der SD-WAN Gateway-Appliance enthält die folgenden Systemänderungen:
  • „ifupdown“ wird als veraltet angesehen zugunsten von https://netplan.io/
    • „ifup“ und „ifdown“ sind nicht mehr verfügbar
    • Die Netzwerkkonfiguration befindet sich jetzt in „/etc/netplan“ anstelle von „/etc/network/“
    • „etc/network/ifup.d“ und „/etc/network/ifdown.d“ können nicht mehr ausgeführt werden. Die folgenden Netzwerk-Dispatcher-Speicherorte sollten verwendet werden: /usr/lib/networkd-dispatcher (dormant.d, no-carrier.d, off.d, routable.d)
  • Umfangreiche Änderungen an Cloud-init. Cloud-init-Bereitstellungsskripts müssen auf Kompatibilität geprüft und getestet werden
  • net-tools (ifconfig, netstat, etc) werden als „veraltet“ angesehen und ggf. in zukünftigen Versionen entfernt

Netzwerkkonfiguration

„ifupdown“ wird als veraltet angesehen zugunsten von https://netplan.io/. Die Netzwerkkonfiguration wurde von „/etc/network“ zu „/etc/netplan“ verschoben.

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: [] 
Die Netzwerkkonfiguration wird bei jedem Startvorgang neu generiert. Um Änderungen an der Standortkonfiguration vorzunehmen, deaktivieren Sie die Netzwerkkonfiguration von Cloud-init.
echo 'network: {config: disabled}' > /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg

Cloud-init

Cloud-init wurde auf Version 20.2 aktualisiert. Weitere Informationen zu Cloud-init finden Sie hier: https://cloudinit.readthedocs.io/en/stable/index.html

Beispiel 1: Einfach

meta-data:

instance-id: vcg1

local-hostname: vcg1

user-data:
#cloud-config 
hostname: vcg1 
password: Velocloud123
chpasswd: {expire: False} 
ssh_pwauth: True

Beispiel 2: Netzwerkkonfiguration im neuen Stil (network-config-Datei)

meta-data:
instance-id: vcg1 
local-hostname: vcg1 
user-data:
#cloud-config
hostname: vcg1
password: Velocloud123
chpasswd: {expire: False}
ssh_pwauth: True
ssh_authorized_keys:
  - ssh-rsa  …  rsa-key

velocloud: 
  vcg: 
    vco: demo.velocloud.net 
    activation_code: F54F-GG4S-XGFI 
    vco_ignore_cert_errors: false 

runcmd:
  - 'echo “Welcome to VeloCloud”' 

network-config – Beispiel 1:

version: 2
ethernets:
  eth0:
    addresses: 
      - 192.168.152.55/24
    gateway4: 192.168.152.1
    nameservers: 
      addresses:
        - 192.168.152.1 
  eth1:
    addresses:
      - 192.168.151.55/24
    gateway4: 192.168.151.1
    nameservers: 
      addresses:
        - 192.168.151.1 

network-config – Beispiel 2:

HINWEIS: Wenn mehrere Schnittstellen auf dem Gateway vorhanden sind und eine Schnittstelle als bevorzugte Schnittstelle für das Standard-Gateway ausgewählt werden muss, kann die unten aufgeführte Konfiguration (mit dem Metrikwert) verwendet werden, um die richtige Schnittstelle auszuwählen.

version: 2
ethernets:
eth0:
  addresses: [192.168.82.1/24]
eth1:
  addresses: [70.150.1.1/24]
  routes:
  - {metric: 1, to: 0.0.0.0/0, via: 70.150.1.254}
eth2:
  addresses: [70.155.1.1/24]
  routes:
  - {metric: 2, to: 0.0.0.0/0, via: 70.155.1.254}

Net-tools

Net-tools-Dienstprogramme wie ifconfig, netstat, route usw. werden als „veraltet“ angesehen. In der folgenden Tabelle sind die für Net-tools vorgeschlagenen Ersetzungen aufgeführt. Bei diesen Befehlen werden nur Informationen für den Linux-Host und nicht für das SD-WAN-Overlay-Netzwerk angezeigt. HINWEIS: Geben Sie Folgendes ein, um weitere Informationen zu erhalten: man ip.

Alte Net-tools-Dienstprogramme Neue entsprechende Net-tools-Dienstprogramme
arp ip n (ip neighbor)
ifconfig ip a (ip addr), ip link, ip -s (ip -stats)
nameif ip link, ifrename
netstat ss, ip route (für netstat-r), ip -s link (für netstat -i), ip maddr (für netstat-g)
route ip r (ip route)

Befehlsausgabe für Net-tool-Dienstprogramme – Beispiel

Bei der Beispielausgabe handelt es sich um die Bestätigung, dass der Befehl erfolgreich war. Nachfolgend wird eine Beispielbefehlsausgabe für ip n (ip neighbor), ip a (ipaddr) und ip link angezeigt.

ip n (ip neighbor):
root@SS-gateway-1:~# ip n 
192.168.0.100 dev eth2 lladdr 00:50:56:84:85:d4 REACHABLE 
192.168.0.250 dev eth2 lladdr 00:50:56:84:97:66 REACHABLE 
13.1.1.2 dev eth0 lladdr 00:50:56:84:e7:fa REACHABLE 
root@SS-gateway-1:~# 
ip a (ipaddr):
root@SS-gateway-1:~# ip a 
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 
    inet 127.0.0.1/8 scope host lo 
       valid_lft forever preferred_lft forever 
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever 
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 4096 
    link/ether 00:50:56:84:a0:09 brd ff:ff:ff:ff:ff:ff 
    inet 13.1.1.1/24 brd 13.1.1.255 scope global eth0 
       valid_lft forever preferred_lft forever 
    inet6 fe80::250:56ff:fe84:a009/64 scope link 
       valid_lft forever preferred_lft forever 
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 
    link/ether 00:50:56:84:a6:ab brd ff:ff:ff:ff:ff:ff 
    inet 101.101.101.1/24 brd 101.101.101.255 scope global eth1 
       valid_lft forever preferred_lft forever 
    inet6 fe80::250:56ff:fe84:a6ab/64 scope link 
       valid_lft forever preferred_lft forever 
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 
    link/ether 00:50:56:84:bc:75 brd ff:ff:ff:ff:ff:ff 
    inet 192.168.0.201/24 brd 192.168.0.255 scope global eth2 
       valid_lft forever preferred_lft forever 
    inet6 fe80::250:56ff:fe84:bc75/64 scope link 
       valid_lft forever preferred_lft forever 
6: gwd1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 4096 
    link/none 
    inet 169.254.129.1/32 scope global gwd1 
       valid_lft forever preferred_lft forever 
    inet6 fe80::27d5:9e46:e7f7:7198/64 scope link stable-privacy 
       valid_lft forever preferred_lft forever 
root@SS-gateway-1:~# 
ip link
root@SS-gateway-1:~# ip link 
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 4096 
    link/ether 00:50:56:84:a0:09 brd ff:ff:ff:ff:ff:ff 
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 
    link/ether 00:50:56:84:a6:ab brd ff:ff:ff:ff:ff:ff 
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 
    link/ether 00:50:56:84:bc:75 brd ff:ff:ff:ff:ff:ff 
6: gwd1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 4096 
    link/none 
root@SS-gateway-1:~# 

Überlegungen zum Upgrade

Hinweis: Die folgenden Schritte basieren auf der Annahme, dass Sie die gleiche IP-Adresse und den gleichen SD-WAN Gateway-Namen für das in der Version 4.0 bereitgestellte SD-WAN Gateway verwenden möchten. Wenn Sie jedoch ein neues SD-WAN Gateway mit einer anderen IP-Adresse erstellen möchten, können Sie die Verfahren für ein neues SD-WAN Gateway durchführen.

Aufgrund wesentlicher Änderungen am Festplattenlayout und den Systemdateien ist ein direktes Upgrade von älteren Versionen auf Version 4.0 nicht möglich. Die Migration erfordert die Bereitstellung neuer SD-WAN Gateway 4.0-Systeme und die Außerbetriebsetzung von Systemen mit älterem Code.

Bleiben Sie für VPN-SD-WAN Gateways oder NAT-SD-WAN Gateways mit bekannten öffentlichen IP-Adressen bei dem folgenden Verfahren, wenn die öffentliche IP-Adresse des SD-WAN Gateway beibehalten werden muss.

Vorgehensweise: (VNP- oder NAT- SD-WAN Gateways mit bekannten öffentlichen IP-Adressen)
  1. Starten Sie das neue SD-WAN Gateway-System basierend auf dem Image der Version 4.0. Weitere Informationen finden Sie im Bereitstellungshandbuch für Ihre Plattform (Gateway-Installationsverfahren).
  2. Fahren Sie das alte SD-WAN Gateway-System herunter. Schalten Sie die alte SD-WAN Gateway-VM ab (entweder durch Ausführen des Befehls “sudo poweroff” in der CLI-Konsole oder durch Ausschalten über die verfügbaren Hypervisor-Optionen).
  3. Migrieren Sie die öffentliche IP zum neuen System: Aktualisieren Sie den NAT-Eintrag so, dass er auf das neue SD-WAN Gateway-System zeigt, oder konfigurieren Sie die öffentliche IP für die neue SD-WAN Gateway-Netzwerkschnittstelle. Stellen Sie das neue Gateway mit den obigen Cloud-init-Beispielen mit derselben IP-Adresse wie das vorherige SD-WAN Gateway bereit.
  4. Beziehen Sie den Aktivierungsschlüssel aus dem bestehenden SD-WAN Gateway-Eintrag in SD-WAN Orchestrator (wie in den folgenden Schritten beschrieben).
    1. Wählen Sie in SD-WAN Orchestrator im Navigationsbereich auf der linken Seite Gateways aus.
    2. Klicken Sie im Bildschirm Gateways auf ein SD-WAN Gateway, um es auszuwählen.
    3. Klicken Sie im Bildschirm des ausgewählten SD-WAN Gateway auf den nach unten weisenden Pfeil neben dem Namen des SD-WAN Gateway, um das Informationsfeld zu öffnen.
    4. Der Aktivierungsschlüssel befindet sich am unteren Rand des Informationsfelds (siehe folgende Abbildung).

  5. Legen Sie die Systemeigenschaft „gateway.activation.validate.deviceId“ auf „False“ fest (siehe folgende Abbildung). Bei Bedarf finden Sie weitere Informationen im Abschnitt Systemeigenschaften im Operator-Handbuch für VMware SD-WAN.

  6. Reaktivieren Sie das neue SD-WAN Gateway-System. Führen Sie in der CLI-Konsole Folgendes aus: “sudo /opt/vc/bin/activate.py -s <vco_address> <activation_code>”
  7. Stellen Sie den ursprünglichen Wert der Systemeigenschaft „gateway.activation.validate.deviceId“ wieder her (falls erforderlich).

    Das SD-WAN Gateway ist jetzt registriert und bereit, eine Verbindung von den Edges zu empfangen.

Hinweis: Die Reaktivierung von SD-WAN Gateway kann über Cloud-init ausgeführt werden, wie im Abschnitt „Benutzerdaten“ in diesem Dokument beschrieben.

Aktivierung – Beispielausgabe

root@gateway/opt/vc# /opt/vc/bin/activate.py FLM6-CSV6-REJS-XFR5 -i -s 169.254.8.2

Aktivierung erfolgreich: VCO zurück zu 169.254.8.2 root@SS1-gateway-2:/opt/vc# überschrieben

SD-WAN Gateways ohne bekannte öffentliche IP-Adressen

Dieser Abschnitt gilt nur für SD-WAN Gateways ohne eine bekannte öffentliche IP-Adresse, z. B. VPN-SD-WAN Gateways. Wenn dieses Szenario zutrifft, führen Sie das folgende Verfahren durch.

Verfahren: ( SD-WAN Gateways ohne bekannte öffentliche IP-Adressen)
  1. Starten Sie ein neues SD-WAN Gateway-System. Bei Bedarf finden Sie weitere Informationen im Bereitstellungshandbuch für Ihre Plattform (Gateway-Installationsverfahren).
  2. Aktivieren Sie ein neues SD-WAN Gateway-System.
  3. Fügen Sie das neue SD-WAN Gateway dem SD-WAN Gateway-Pool von SD-WAN Orchestrator hinzu. Weitere Informationen finden Sie im VMware SD-WAN Operator-Handbuch im Abschnitt Gateway-Verwaltung.
    1. Das SD-WAN Gateway ist jetzt registriert und bereit, eine Verbindung von den Edges zu empfangen.
  4. Entfernen Sie das alte SD-WAN Gateway aus dem SD-WAN Gateway-Pool von SD-WAN Orchestrator. Weitere Informationen finden Sie im Operator-Handbuch für VMware SD-WAN im Abschnitt „Gateway-Verwaltung“.
  5. Setzen Sie die alte SD-WAN Gateway-VM außer Betrieb. (Entfernen Sie den SD-WAN Gateway-Eintrag aus SD-WAN Orchestrator und setzen Sie die VM-Instanz außer Betrieb.)

Bezug des Gateway-Aktivierungsschlüssels über API

Für eine Bereitstellung mit der API-Methode verwenden Sie Folgendes: „network/getNetworkGateways“

Beispielantwort:

{"jsonrpc":"2.0","result":[{"id":1, "activationKey":"69PX-YHY2-N5PZ-G3UW … 

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/gatewayd“ 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.