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.
- 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.
- Informationen dazu finden Sie auch unter /run/cloud-init/result.json. Wenn die folgende Meldung angezeigt wird, wird Cloud-init wahrscheinlich erfolgreich ausgeführt.
- Überprüfen Sie, ob das Gateway bei SASE Orchestrator registriert ist.
- Überprüfen Sie die externe Konnektivität.
- Stellen Sie sicher, dass MGMT VRF auf ARPs reagiert.
- 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
- Ordnen Sie den neuen Gateway-Pool dem Kunden zu.
- Ordnen Sie das Gateway einem Edge zu. Weitere Informationen finden Sie im Abschnitt „Zuweisen der Partner-Gateway-Übergabe“ im VMware SD-WAN-Administratorhandbuch.
- Stellen Sie sicher, dass der Edge in der Lage ist, einen Tunnel mit dem Gateway auf der Internetseite einzurichten. Navigieren Sie im SASE Orchestrator zu .
Navigieren Sie im SASE Orchestrator zu und klicken Sie auf Ausführen (Run), um die Liste der aktiven Pfade anzuzeigen.
- Konfigurieren Sie die Übergabeschnittstelle. Weitere Informationen finden Sie unter Konfigurieren der Partnerübergabe.
- Stellen Sie sicher, dass die BGP-Sitzung aktiv ist.
- Ä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: []
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.
"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.
[
{
"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 3: Starten Sie den SD-WAN Gateway-Prozess mit „sudo /opt/vc/bin/vc_procmon“ neu.
