VCF9 NSX-Edge Setup – Was hat sich geändert

This post is also available in: Englisch

Vor einigen Wochen habe ich in dem Blog https://vrealize.it/de/2025/06/02/vcf-nsx-edge-setup-aus-netzwerksicht beschrieben, wie die NSX Edges in VCF5.x über den SDDC Manager bereit gestellt werden. 

In VCF9, wurde aus meiner Sicht das Zusammenspiel der einzelnen Komponenten verbessert und dadurch Nutzerfreundlicher gestaltet. Einige Veränderungen sind auch in dem Zusammenspiel mit NSX zu erkennen.

Die Installation des NSX Managers und die Konfiguration des TEP-Netzwerks auf den ESX-Hosts erfolgt in VCF9 über VCF Operations (für VI WorkloadDomain) bzw. VCF Installer für die Management Domain. Edges können direkt aus vCenter installiert und konfiguriert werden. Eine Installation und Konfiguration über den NSX Manager ist jedoch weiterhin möglich.

Das Bild beschreibt das Deployment einer Workload Domain.

In diesem Blog werde ich die Installation der NSX Edges über das vCenter beschreiben. Da sich die Funktionen der NSX Edge und die Art wie Routing/Switching funktioniert nicht verändert haben, verweise ich für die Details auf meinen vorherigen Blog Eintrag https://vrealize.it/de/2025/06/02/vcf-nsx-edge-setup-aus-netzwerksicht, wenn es zu Verständnissfragen kommen sollte. 

Zieldesign

Das Zieldesign der NSX Edges und des T0 Gateway ist identisch zu dem Design welches ich in dem vorherigen Blog beschrieben habe. 

Es gibt jedoch eine Änderung: Es gibt ein neues Element namens „Transit Gateway“. Das Transit Gateway ähnelt dem bekannten T0, nur ohne externe Schnittstellen. Das T0-Gateway mit externen Schnittstellen ist auf eine reine SR-Komponente (ohne DR) reduziert. Transit Gateways wurden mit VCF9 eingeführt und dienen der Verbindung mehrerer VPCs in einem Projekt. Ein Tier-1-Gateway ist das Gegenstück zum VPC-Gateway im VPC-Netzwerkmodell.

Weitere Informationen finden Sie hier: https://community.broadcom.com/applications-networking-security/blogs/luca-camarda/2025/06/23/vcf-virtual-networking-technical-reference

In VCF9 können außerdem VPCs (Virtual Private Clouds) direkt aus dem vCenter bereitgestellt werden. Das Konstrukt mit VPCs und Projekts habe ich in dem folgenden Blog beschrieben -> https://vrealize.it/de/2025/02/07/vpc-networking-mit-vcf-nsx/

Für die native VPCs (erstellt aus dem vCenter) wird anstelle des T1 Gateways, dass Transit Gateway genutzt.

Die NSX Edge VMs werden auf den Hosts installiert wo sich auch die Workload VMs befinden. Wenn der ESXi Server nur über 2 physikalische Netzwerkkarten verfügt kann der Geneve Overlay Tunnel entweder an den physikalischen Netzwerkkarten terminieren oder aber wird durchgereicht zu der Edge Komponente und terminiert dort. Beides heißt aber im Umkehrschluss das der Tunnel Endpunkt nicht gleichzeitig für Workload VMs und der NSX Edge zur Verfügung stehen kann.

Damit die Konfiguration funktioniert, könnten sich die TEPs der Edge-VMs in einem anderen IP-Netzwerk als die TEPs der ESXi-Server befinden und über einen externen Router miteinander verbunden sein. In VCF9 kann man auch dasselbe IP-Netzwerk für Host-TEP und Edge-TEP verwenden (in meinem Beispiel verwende ich weiterhin separate Netzwerke für HOST-TEP und Edge-TEP). Im obigen Beispiel befinden sich die ESXi-Server im Overlay-Netzwerk 10.13.14.0/24 (VLAN 1314) und die Edge-VMs im Overlay-Netzwerk 10.13.19.0/24 (VLAN 1319). Es gibt auch Konfigurationsoptionen, um die TEPs der ESXi-Server und der Edges im selben IP-Netzwerk auszuführen. Ich werde diese Optionen in diesem Blog jedoch nicht diskutieren, da VCF den Konfigurationspfad mit zwei verschiedenen TEP-Netzwerken benötigt.

Von den NSX Edges werden insgesamt 3 virtuelle Interfaces (vNICs) genutzt. Das Interface vNIC-1 ist das Management Interface mit dem der NSX Manager kommuniziert, oder aber auch ein SSH Zugriff erfolgen kann.

Die Interfaces vNIC-2 und vNIC-3 verarbeiten den Workload Traffic. Beide Interfaces sind mit dem Overlay Netzwerk verbunden und bauen einen Tunnel zu den ESXi Servern auf. Auf den beiden vNICs werden über andere VLANS die Interfaces für das Routing konfiguriert.

Voraussetzungen

Für das Setup müssen folgende Voraussetzungen erfüllt sein:

• Workload Domain wurde über den SDDC Manager erstellt
• Externe Router wurden konfiguriert und Transit IP Adressen wurden festgelegt
• Das Routing Protokoll (Static/BGP) wurde ausgewählt und auf den Datacenter Routern eingerichtet
• VLANs für das NSX Edge Overlay wurde konfiguriert und hat eine MTU Size von mindestens 1.700
• Routing zwischen dem Host und Edge Overlay Netzwerk ist möglich
• DNS Einträge sind vorhanden

Setup

Die Konfiguration erfolgt nicht über den SDDC Manager oder in VCF Operations, sondern direkt über das vCenter der jeweiligen Workload Domain.

(Sollte die Workload Domain frisch erstellt worden sein, muss eventuell noch die Portgruppe für das Management Interface der Edges und dem dazugehörigen VLAN angelegt werden. In meinem Fall ist es die Portgruppe “sfo-w01-cl01-vds01-pg-vm-mgmt” mit dem VLAN 1310) 

Nachdem erfolgreichen Login auf dem vCenter, befindet sich der Konfigurations-Task unter Networks -> Network Connectivity.

Der Konfigurationsprozess wird dann über “CONFIGURE NETWORK CONNECTIVITY” gestartet. 

Es öffnet sich eine neue Eingabe Maske und als erstes muss der Gateway Type festgelegt werden. Für die meisten Anwendungen sollte der Typ “Centralized Connectivity” ausgewählt werden, da hier die Services über die NSX Edges (DHCP, NAT, Layer 3 services, and network monitoring and logging) bereit gestellt werden.

Es gibt Anwendungsfälle, wo die “Distributed Connectivity” benötigt wird. In diesem Fall, erfolgt die Kommunikation in das Datacenter direkt aus dem Host in ein VLAN Netzwerk und umgeht somit die NSX Edge Komponente. Das erhöht die Performance, aber es stehen nur noch die Services DHCP und External IP zur Verfügung.

Da ich in meinem Use Case alle Funktionen nutzen möchte, wählen wir “Centralized Connectivity” aus und gehen über “NEXT” auf den nächsten Konfigurationsschritt.

An diese Stelle sollte noch einmal geprüft werden, ob alle Vorraussetzungen erfüllt sind und bestäigen dieses.

Wir werden nun aufgefordert die Edges zu konfigurieren und starten mit einem Namen für das Edge Cluster und wählen den Form Factor der Edges aus. Anschließend fügen wir die erste Edge über “ADD” hinzu.

Die Edge Nodes sollten am besten schon auf einem DNS Server eingetragen sein. Folgende Werte müssen natürlich individuell auf die jeweilige Umgebung angepasst werden:

• Edge Node Name: sfo-w01-r01-en01.sfo.rainpole.io
• vSphere Cluster: sfo-w01-cl01
• Data Store: sfo-w01-sfo-w01-cl01-vsan-01
• Management IP
  • IP Allocation: Static (kann natürlich auch über DHCP erfolgen)
  • Port Group: sfo-w01-cl01-vds01-pg-vm-mgmt (mgmt VLAN)
  • Management IP: 10.13.10.135/24
  • Default Gateway: 10.13.10.1

INFORMATION: Falls Sie dasselbe Netzwerk für Host und Edge TEP verwenden möchten, müssen Sie NSX auf DVPG auf Cluster Ebene in NSX aktivieren.

… und aktivieren Sie die Checkbox Uplinks – “Use the host overlay network configuration..”

Anschließend erfolgt das Mapping der Uplinks und es wird sowohl das VLAN des Overlay Netzwerkes und die IPs festgelegt. Ich arbeite mit statischen IP Adressen und habe deswegen bei IP Allocation “Static IP List” ausgewählt und die zwei IP Adressen für die Tunnel Endpunkte manuell eingetragen.

Über den “APPLY” Button wird die Konfiguration der ersten Edge gespeichert und wir können über den “ADD” Button die Parameter für die zweite Edge eintragen.

Bei der zweiten Edge Node ändern sich der FQDN, und die IP Adressen für das Management und den Tunnel Endpunkten. Die anderen Parameter sollten identisch sein.

Über “NEXT” können wir uns jetzt dem nächsten Schritt widmen.

Bei der Workload Domain Connectivity, werden die Parameter für das T0 Gateway eingetragen.

!!! Sollte das Deployment für VKS (vSphere Kubernetes Services) genutzt werden, muss der “High Availability Mode” auf Active/Standby gesetzt werden !!!

Die Parameter für mein Deployment sind wie folgt:

• Gateway Name: VLC-Tier-0
• HA Mode: Active/Standby (ich möchte später VKS ausrollen)
• Gateway Routing Type: BGP
• Local ASN: 65102

Anschließend werden über Gateway Uplinks -> Set die Uplink Interfaces zwischen dem T0 Gateway und dem externen Datacenter Router konfiguriert. Folgende Parameter treffen in meiner Umgebung zu:

First Uplink

• GW Interface VLAN: 1317
• GW Interface CIDR: 10.13.17.2/24
• BGP Peer IP: 10.13.17.10
• BPG Peer ASN: 65131
• BGP Peer Password: Identisch mit dem externen BGP Router

Second Uplink

• GW Interface VLAN: 1318
• GW Interface CIDR: 10.13.18.2/24
• BGP Peer IP: 10.13.18.10
• BPG Peer ASN: 65131
• BGP Peer Password: Identisch mit dem externen BGP Router

Anschließend wird auch die zweite Edge Node konfiguriert.

Die IP Adressen der zweiten Edge müssen natürlich angepasst werden.

First Uplink

• GW Interface VLAN: 1317
• GW Interface CIDR: 10.13.17.3/24
• BGP Peer IP: 10.13.17.10
• BPG Peer ASN: 65131
• BGP Peer Password: Identisch mit dem externen BGP Router

Second Uplink

• GW Interface VLAN: 1318
• GW Interface CIDR: 10.13.18.3/24
• BGP Peer IP: 10.13.18.10
• BPG Peer ASN: 65131
• BGP Peer Password: Identisch mit dem externen BGP Router

Nachdem beide Edges mit den Uplink Interfaces konfiguriert wurden können zum Abschluss noch IP Pools für das native VPC erstellt werden.

In meiner Lab Umgebung steht mir das Netzwerk 192.168.24.0/23 zur Verfügung. Aus diesem Netz werden später Adressräume genutzt um diese extern Verfügbar (also außerhalb der NSX Umgebung) zu machen. Das ist zum einen die NAT Adresse für VMs die sich in einem “private” oder “transit” Subnet befinden und für die Netze die als Public (also außerhalb der NSX Umgebung) erreichbar sein sollen.

Der Private – Transit Gateway IP Block wird nicht nach außen propagiert und kann genutzt werden, wenn VMs aus verschiedenen VPCs miteinander kommunizieren müssen. Da der IP Block nicht propagiert wird, wähle ich hier einen größeren Raum mit dem Netzwerk 172.16.0.0/16

Sobald die Daten erfasst wurden, kann die Konfiguration über “NEXT” abgeschlossen werden.

Man erhält noch einmal die Möglichkeit sich die Konfiguration anzuschauen und mit “DEPLOY” wird die Installation und Konfiguration gestartet.

Danach kehrt man zurück in die vCenter Ansicht und sieht wie das Edge Cluster erstellt wird. Bei den Network Configuration sieht man außerdem die Information der IP Blocks, die wir im letzten Schritt angelegt haben. Je nach Umgebung kann die Installation einen Moment dauern.

Konfiguration prüfen

Wenn das Deployment erfolgreich durchgelaufen ist, können wir uns mit dem NSX Manager verbinden und prüfen, ob die Verbindungen zwischen dem T0 Gateway und dem externen Router sauber hergestellt wurden. Nach dem erfolgreichen Login auf dem NSX Manager sollte der BGP Nachbarschaftsstatus geprüft werden. Diesen findet man unter Networking -> Tier-0 Gateways -> ROUTER-NAME -> BGP -> BGP Neighbors.

In dem neuen Fenster kann man die BGP Neighbors aufklappen und findet auf der rechten Seite den “BGP CONNECTIVITY STATUS”

Der Status sollte bei allen Verbindungen auf “Established” stehen.

VPC erstellen

Jetzt ist es an der Zeit unser erstes VPC zu erstellen. Dazu gehen wir zurück ins vCenter und dort auf den Netzwerk Reiter -> Virtual Private Clouds -> “ADD VPC”

Für das VPC muss ein Name festgelegt werden und ein IP Adressbereich, der nur innerhalb des VPCs existiert. Sollte man mehrere VPs erstellen, kann dieses Netzwerk in allen VPCs identisch (overlapping) sein. Auch hier wähle ich wieder einen großen IP Address Raum mit 172.31.0.0/16.

Über “VIEW DETAILS” bei Connectivity and Services können die Voreinstellungen für das VPC überprüft werden.

Es werden die IP Blöcke genutzt, die wir bei der initialen Konfiguration erstellt haben. Außerdem wird automatisch NAT aktiviert. Das ist nötig, damit VMs, die mit in einem “private network” oder dem “private transit network” zwar nicht von außen direkt erreicht werden können, aber trotzdem von innen nach außen (z.B. zum DNS, NTP, AD) kommunizieren können. Nach der Überprüfung der Informationen können wir das Fenster schließen und über den “SAVE” Button das VPC erstellen.

In der Summary sehen wir die Information über die IP Blöcke und auch die Anzahl der konfigurierten Netze, die momentan natürlich noch auf 0 steht. Wenn man in dem Feld “CONNECTIVITY AND SERVICES” nach unten scrollt, wird einem auch die Default Outbound NAT Adresse angezeigt.

Die NAT IP wird aus dem externen IP Pool (192.168.24.0/23) bereitgestellt. Da es sich hier um eine /32 Adresse handelt, kann diese auch mit einer 0 enden und wird trotzdem von allen Router weiter propagiert.

Als nächstes können wir Netze in dem VPC erstellen. Das geschieht über ACTIONS -> New Subnet…

Das Subnet benötigt einen eindeutigen Namen innerhalb des VPCs. Anschließen wird der Access Mode ausgewählt. Das kann entweder “Private – VPC”, “Private – Transit Gateway” oder “Public” sein, je nachdem ob das Netz von außen erreichbar sein soll oder nur innerhalb eines VPCs oder zwischen VPCs.

Um es dem Nutzer zu vereinfachen, muss kein Netzwerk mit Subnetmaske eingetragen werden, sondern der Nutzer bestimmt über die Subnet size, lediglich die Anzahl von verfügbaren Adressen die in dem Netz zur Verfügung stehen sollen.

Sollte man DHCP nutzen wollen, kann entweder in NSX ein DHCP Profile hinterlegt werden (DHCP Server) oder aber über DHCP Relay eine Weiterleitung an einen DHCP Server erfolgen.

In meiner Umgebung habe ich jeweils ein Subnet in private, private transit und public erstellt.

In dem Reiter Networks, sieht man die Details zu den einzelnen Netzwerken die ich erstellt habe. Bei den jeweiligen IP CIDR sieht man, dass je nach Netzwerk Typ ein Netz aus den vordefinierten IP Pools erstellt wurde.

Eine weitere Möglichkeit der Ansicht findet man unter -> Configure -> Settings -> Topology

Wenn die Netze erstellt wurden, können wir den VMs Netze zuweisen und testen. Wenn auch die INTER-VPC Kommunikation getestet werden soll, benötigen wir noch ein zweites VPC. Dieses habe ich mit dem Namen My2ndVPC erstellt und ebenfalls die 3 Netzwerke konfiguriert. Wie man in der Topology sehen kann, habe ich für den IP Bereich der Private Netze auch die 172.31.0.0/16 gewählt und damit überlappende IPs. Das stört aber nicht, da die IPs aus dem Private Net nur innerhalb des jeweiligen VPCs relevance haben.

Eine Gesamt Ansicht aller VPCs kann man sich über Virtual Private Clouds -> Configure -> Topology anschauen. Hier sieht man auch das beide VPCs über das Transit Gateway miteinander verbunden sind.

Jetzt ist es an der Zeit VMs mit den angelegten Netzen zu verbinden. Wenn man ein Subnet ausgewählt hat, kann man über ACTIONS -> Connect VMs.. die VMS direkt hinzufügen. Natürlich geht dass auch nach wie vor über die Konfigurationseinstellungen auf der VM.

Es werden zuerst die VMs ausgewählt und anschließend die Network Adapter (falls die VM mehrere konfiguriert hat)

Diesen Vorgang wiederholen wir dann für die anderen Netze. Am Ende sollte in jedem Netz eine VM sein.

Hier die Übersicht meiner VMs

VM Name	VPC / VPC SUBNET	IP Adresse
demo-1-server	MyFirstVPC/PRIVATE-VPC	172.31.0.3/26
demo-2-server	MyFirstVPC/PRIVATE-TRANSIT	172.16.0.3/27
demo-3-server	MyFirstVPC/PUBLIC	192.168.24.19/28
demo-4-server	My2ndVPC/PRIVATE-VPC	172.31.0.3/26
demo-5-server	My2ndVPC/PRIVATE-TRANSIT	172.16.0.35/27
demo-6-server	My2ndVPC/PUBLIC	192.168.24.35/28

Test 1: SSH von meinem PC (also extern) auf demo-3-server (192.168.24.19) in dem Public Network.

Wie zu erwarten komme ich über die Public IP Adresse auf den Server.

Test 2: Ping von demo-3-server zu den servern demo-1 und demo-2 sowie demo-5 und demo-6

Der Server demo-3-server kann alle anderen Server erreichen. Das demo-4-server nicht erreicht werden kann, ergibt sich aus der Tatsache, das dieser Server die gleiche IP Adresse hat, wie demo-1-server in dem lokalen VPC.

Test 3: Ping von demo-1-server und von demo-2-server auf eine externe Adresse (8.8.8.8)

Die Server können erfolgreich die externe IP Adresse erreichen.

Test 4: Ping von meinem PC (also extern) auf demo-1-server und demo-2-server.

Sowohl private als auch private-transit Netze sind nicht von einer externen Adresse erreichbar.

Summary

VCF9 ermöglicht ein einfaches Deployment der NSX Infrastruktur. Außerdem können Anwender durch die native VPCs, Netzwerke aus dem vCenter heraus konsumieren und je nach Bedarf zwischen den verschiedenen Netzwerktypen wählen. Der Anwender kann so schneller auf Resourcen zugreifen (Agilität) und der Netzwerk Administrator behält trotzdem die Hoheit über die IP Address Räume die genutzt werden dürfen (robustness).