VMware Hands-on Labs - HOL-1903-01-NET


Hands-on Lab im Überblick – HOL-1903-01-NET – Erste Schritte mit VMware NSX Data Center

Anleitung für das Hands-on Lab


Hinweis: Dieses Hands-on Lab dauert möglicherweise länger als 90 Minuten. Sie werden wahrscheinlich nur zwei bis drei Module in einer Sitzung schaffen. Da die Module unabhängig voneinander sind, können Sie mit jedem beliebigen Modul beginnen. Über das Inhaltsverzeichnis gelangen Sie direkt zum Modul Ihrer Wahl.

Das Inhaltsverzeichnis können Sie rechts oben im Hands-on Lab-Handbuch aufrufen.

NSX Data Center for vSphere ist die Netzwerkvirtualisierungsplattform von VMware für das Software-Defined Datacenter (SDDC), mit der Netzwerk- und Sicherheitsfunktionen vollständig softwarebasiert und von der zugrunde liegenden physischen Infrastruktur abstrahiert bereitgestellt werden können.

In diesem Hands-on Lab erhalten Sie eine Einführung in die Kernfunktionen von VMware NSX Data Center in einer vSphere-Umgebung. Sie werden praktische Erfahrungen in den Bereichen logisches Switching, verteiltes logisches Routing, dynamisches Routing sowie logische Netzwerkservices sammeln.

Liste der Module des Hands-on Lab:

Hands-on Lab-Dozenten:

  • Module 1 – 4: Joe Collon, Staff NSX Systems Engineer, USA

Das Handbuch für dieses Hands-on Lab kann unter der folgenden Adresse heruntergeladen werden:

http://docs.hol.vmware.com

Dieses Hands-on Lab ist möglicherweise auch in anderen Sprachen verfügbar. Informationen zum Einstellen Ihrer gewünschten Sprache und zum Abrufen eines übersetzten Hands-on Lab-Handbuchs finden Sie im folgenden Dokument:

http://docs.hol.vmware.com/announcements/nee-default-language.pdf


 

Position der Hauptkonsole

 

  1. Der ROT umrahmte Bereich ist die Hauptkonsole. Das Hands-on Lab-Handbuch finden Sie auf der Registerkarte rechts neben der Hauptkonsole.
  2. Für bestimmte Hands-on Labs sind möglicherweise auf separaten Registerkarten links oben zusätzliche Konsolen verfügbar. Falls Sie eine andere Konsole öffnen müssen, erhalten Sie entsprechende Anweisungen.
  3. Für die Bearbeitung des Hands-on Lab haben Sie 90 Minuten Zeit. Das Hands-on Lab kann nicht gespeichert werden. Sie müssen alle Aufgaben während dieser Zeit erledigen. Sie können jedoch die verfügbare Zeit verlängern, indem Sie auf die Schaltfläche EXTEND klicken. Auf einer Veranstaltung von VMware können Sie die Zeit für Hands-on Labs zweimal um bis zu 30 Minuten verlängern. Mit jedem Klick erhalten Sie weitere 15 Minuten. Außerhalb von VMware-Veranstaltungen können Sie Ihre Zeit für das Hands-on Lab um bis zu 9 Stunden und 30 Minuten verlängern. Mit jedem Klick verlängert sich die Dauer um eine Stunde.

 

 

Alternativen zur Tastatureingabe

Im Verlauf des Moduls geben Sie Text in die Hauptkonsole ein. Neben der Tastatureingabe gibt es zwei weitere, äußerst hilfreiche Methoden, die die Eingabe komplexer Daten erleichtern.

 

 

Inhalte im Hands-on Lab-Handbuch anklicken und in das aktive Konsolenfenster ziehen

 
 

Sie können Text und Befehle in der Befehlszeilenschnittstelle (CLI) anklicken und direkt aus dem Hands-on Lab-Handbuch in das aktive Fenster der Hauptkonsole ziehen.  

 

 

Internationale Online-Tastatur aufrufen

 

Darüber hinaus können Sie die internationale Online-Tastatur in der Hauptkonsole verwenden.

  1. Klicken Sie auf das Tastatursymbol in der Windows-Schnellstartleiste.

 

 

Einmal in das aktive Konsolenfenster klicken

 

In diesem Beispiel verwenden Sie die Online-Tastatur zur Eingabe des in E-Mail-Adressen verwendeten Symbols @. Auf US-Tastaturen wird das @-Zeichen über die Umschalttaste (2) eingegeben.

  1. Klicken Sie einmal in das aktive Konsolenfenster.
  2. Klicken Sie auf die Umschalttaste.

 

 

Auf die @-Taste klicken

 

  1. Klicken Sie auf die @-Taste.

Das @-Zeichen wurde im aktiven Konsolenfenster eingegeben.

 

 

Aktivierungsaufforderung oder Wasserzeichen

 

Wenn Sie Ihr Hands-on Lab erstmals starten, sehen Sie möglicherweise ein Wasserzeichen auf dem Desktop, das angibt, dass Windows nicht aktiviert wurde.  

Einer der großen Vorteile von Virtualisierung ist, dass virtuelle Maschinen verschoben und auf jeder beliebigen Plattform ausgeführt werden können. Die Hands-on Labs machen sich diesen Vorteil zunutze, d.h. sie können von mehreren Rechenzentren aus ausgeführt werden. Allerdings können sich die Prozessoren dieser Rechenzentren unterscheiden. Dies veranlasst Microsoft zu einer Aktivierungsprüfung über das Internet.

Sie können jedoch sicher sein, dass VMware und die Hands-on Labs die Lizenzierungsanforderungen von Microsoft uneingeschränkt erfüllen. Bei dem Hands-on Lab, mit dem Sie gerade arbeiten, handelt es sich um einen gekapselten Pod ohne Vollzugriff auf das Internet. Ein solcher Zugriff ist jedoch für die Windows-Aktivierungsprüfung erforderlich. Ohne Vollzugriff auf das Internet schlägt dieser automatisierte Prozess fehl und es wird dieses Wasserzeichen angezeigt.

Hierbei handelt es sich um ein kosmetisches Problem, das Ihr Hands-on Lab nicht beeinträchtigt.  

 

 

Info rechts unten auf dem Bildschirm

 

Überprüfen Sie, ob das Hands-on Lab alle Startroutinen abgeschlossen hat und gestartet werden kann. Falls etwas anderes als „Ready“ angezeigt wird, warten Sie einige Minuten. Wenn der Status Ihres Hands-on Lab nach fünf Minuten immer noch nicht zu „Ready“ gewechselt hat, bitten Sie um Hilfe.

 

 

Ausführen von vmware-cip-launcher.exe zulassen

 

Gelegentlich wird das Hands-on Lab mit Chrome-Standardeinstellungen bereitgestellt. Ist dies der Fall, wird möglicherweise der oben abgebildete Dialog angezeigt. Gehen Sie folgendermaßen vor, um das Startprogramm mit dem vSphere Web Client (Flash) auszuführen:

  1. Aktivieren Sie das Kontrollkästchen Always open these types of links in the associated app.
  2. Wählen Sie Open vmware-cip-launcher.exe aus.

Sie können anschließend wie gewohnt mit dem Hands-on Lab fortfahren.

 

 

„Recent Tasks“ und „Recent Objects“ im vSphere Web Client minimieren

 

Aufgrund der Bildschirmauflösung des Hands-on Lab-Desktops werden im Lab-Verlauf einige Komponenten der NSX-Benutzeroberfläche möglicherweise unvollständig oder überhaupt nicht angezeigt. Um die nutzbare Bildschirmfläche zu maximieren, wird empfohlen, die Fenster „Recent Objects“ und „Recent Tasks“ im vSphere Web Client (Flash) zu minimieren. Gehen Sie dazu folgendermaßen vor:

  1. Klicken Sie rechts oben im Fenster Recent Objects auf das Stecknadelsymbol.
  2. Klicken Sie rechts oben im Fenster Recent Tasks auf das Stecknadelsymbol.

 

Modul 1 – Installation und Konfiguration von NSX Manager (15 Minuten)

Einführung


VMware NSX Data Center ist die führende Netzwerkvirtualisierungsplattform, die das Betriebsmodell virtueller Maschinen auf das Netzwerk überträgt. Ebenso wie bei der Servervirtualisierung, mit der Sie die Steuerung virtueller Maschinen in einem Pool aus Serverhardware ausweiten können, bietet die Netzwerkvirtualisierung mit NSX Data Center eine zentralisierte API, um in einem einzigen physischen Netzwerk ausgeführte virtuelle Netzwerkservices bereitzustellen und zu konfigurieren.

Logische Netzwerke koppeln virtuelle Maschinen und Netzwerkservices vom physischen Netzwerk ab, wodurch Kunden virtuelle Maschinen flexibel migrieren und überall im Rechenzentrum platzieren können. Gleichzeitig bleiben Layer 2-/Layer 3-Konnektivität sowie die Netzwerkservices für Layer 4 – 7 erhalten.

Im Rahmen dieses Moduls wird eine interaktive Simulation verwendet, die sich auf die Bereitstellung von NSX Data Center in Ihrer Umgebung konzentriert. In der Lab-Umgebung wurde die Bereitstellung bereits für Sie abgeschlossen.

Die interaktive Simulation beinhaltet folgende Punkte:


 

NSX-Komponenten

 

Hinweis: Eine Cloud-Management-Plattform (CMP) ist zwar keine NSX-Komponente, jedoch kann NSX mithilfe der REST-API in nahezu jede CMP integriert werden. Eine Integration in VMware-CMPs ist bereits im Auslieferungszustand möglich.

Die Hauptkomponenten von NSX sind in drei Kategorien unterteilt:

Managementebene: NSX Manager, die NSX-Komponente für zentrales Netzwerkmanagement, bildet die NSX-Managementebene. Er ist der zentrale Konfigurations- und Einstiegspunkt für die REST-API.

Steuerungsebene: Die NSX-Steuerungsebene wird im NSX Controller-Cluster ausgeführt. NSX Controller ist ein erweitertes, verteiltes Statusmanagementsystem, das Funktionen der Steuerungsebene für logisches Switching und Routing von NSX bereitstellt. Er ist der zentrale Steuerungspunkt für alle logischen Switches innerhalb eines Netzwerks und enthält Informationen zu allen Hosts, logischen Switches (VXLANs) und verteilten logischen Routern.

Datenebene: Die NSX-Datenebene besteht aus dem NSX vSwitch, der auf vSphere Distributed Switch (VDS) basiert und zusätzliche Servicekomponenten enthält. Die Kernel-Module, Agents für die Anwenderumgebung, Konfigurationsdateien und Installationsskripts von NSX werden als VIBs innerhalb des Hypervisor-Kernels ausgeführt und stellen Services wie verteiltes Routing, logische Firewalls und VXLAN-Bridging bereit.

 

Interaktive Hands-on Labs-Simulation: Installation und Konfiguration von NSX – Teil 1


Dieser Teil wird als interaktive Hands-on Labs-Simulation durchgeführt. Dadurch können Sie Schritte nachvollziehen, die zu zeitaufwendig oder ressourcenintensiv für die Hands-on Lab-Umgebung sind. In dieser Simulation können Sie die Softwareschnittstelle wie eine Live-Umgebung verwenden.

*** WICHTIGER HINWEIS ***    Die nachfolgende Simulation besteht aus zwei Teilen. Der erste Teil endet nach der Konfiguration von NSX Manager. Um mit dem zweiten Teil der Simulation fortzufahren, müssen Sie oben rechts im Bildschirm auf Return to the Lab klicken. Die notwendigen Schritte werden darüber hinaus im Anschluss an die Konfiguration von NSX Manager im Handbuch erläutert.

  1. Klicken Sie hier, um die interaktive Simulation zu öffnen. Diese wird in einem neuen Browserfenster oder einer neuen Registerkarte geöffnet.
  2. Wenn Sie fertig sind, klicken Sie auf den Link Return to the lab, um mit diesem Hands-on Lab fortzufahren.

 


Interaktive Hands-on Labs-Simulation: Installation und Konfiguration von NSX – Teil 2


Dieser Teil wird als interaktive Hands-on Labs-Simulation durchgeführt. Dadurch können Sie Schritte nachvollziehen, die zu zeitaufwendig oder ressourcenintensiv für die Hands-on Lab-Umgebung sind. In dieser Simulation können Sie die Softwareschnittstelle wie eine Live-Umgebung verwenden.

  1. Klicken Sie hier, um die interaktive Simulation zu öffnen. Diese wird in einem neuen Browserfenster oder einer neuen Registerkarte geöffnet.
  2. Wenn Sie fertig sind, klicken Sie auf den Link Return to the lab, um mit diesem Hands-on Lab fortzufahren.

 


Modul 1 – Fazit


In diesem Modul wurde demonstriert, wie einfach NSX zur Bereitstellung von Layer 2- bis 7-Services innerhalb der Software installiert und konfiguriert werden kann.

Zudem wurden Installation und Konfiguration der NSX Manager-Appliance (Bereitstellung, vCenter-Integration sowie Konfigurieren von Protokollierung und Backups) behandelt. Weitere Themen waren die Bereitstellung der NSX Controller und die Installation von VMware Infrastructure Bundles (VIBs), d.h. Kernel-Module, die zur Bereitstellung von NSX Services auf den Hypervisor übertragen werden. Zu guter Letzt wurden noch die automatisierte Bereitstellung von VXLAN-Tunnelendpunkten (VTEPs) sowie das Erstellen von VXLAN Network Identifier-Pools (VNIs) und Transportzonen beschrieben.


 

Abschluss von Modul 1

Sie haben Modul 1 abgeschlossen.

Weitere Informationen zum Bereitstellen von NSX finden Sie im NSX 6.4 Documentation Center unter der folgenden URL:

Fahren Sie mit einem der folgenden Module fort:

Liste der Module des Hands-on Lab:

Hands-on Lab-Dozenten:

  • Module 1 – 4: Joe Collon, Staff NSX Systems Engineer, USA

 

 

Hands-on Lab beenden

 

Klicken Sie auf die Schaltfläche END, wenn Sie Ihr Hands-on Lab beenden möchten.  

 

Modul 2 – Logisches Switching (30 Minuten)

Logisches Switching – Modulübersicht


In diesem Modul lernen Sie die folgenden Komponenten von VMware NSX kennen:

  • NSX Controller-Cluster: Dank des NSX Controller-Clusters ist die Unterstützung von Multicast-Protokollen in der physischen Fabric nicht mehr notwendig. Darüber hinaus bietet er Funktionen wie VTEP-, IP- und MAC-Auflösung.
  • Sie erstellen einen logischen Switch und verbinden anschließend zwei VMs mit dem logischen Switch.
  • Sie erfahren mehr zu Skalierbarkeit und Hochverfügbarkeit der NSX-Plattform.

Logisches Switching


In diesem Abschnitt werden Sie Folgendes tun:

  1. Konfigurationsbereitschaft der Hosts bestätigen
  2. Vorbereitung logischer Netzwerke bestätigen
  3. Neuen logischen Switch erstellen
  4. Logischen Switch mit dem NSX Edge Services Gateway verbinden
  5. VMs zum logischen Switch hinzufügen
  6. Konnektivität zwischen den VMs testen

 

Auf vSphere Web Client (Flash) zugreifen

 

  1. Starten Sie den vSphere Web Client (Flash) über das Google Chrome-Symbol auf dem Desktop.

 

 

Beim vSphere Web Client (Flash) anmelden

 

Wenn Sie noch nicht beim vSphere Web Client angemeldet sind:

(Die Startseite sollte der vSphere Web Client sein. Falls nicht, klicken Sie auf das vSphere Web (Flash)-Symbol in Google Chrome.)

  1. Geben Sie administrator@vsphere.local in das Feld „User name“ ein.
  2. Geben Sie VMware1! in das Feld „Password“ ein.
  3. Klicken Sie auf Login.

 

 

Zum Bereich „Networking & Security“ im vSphere Web Client navigieren

 

  1. Klicken Sie auf das Haussymbol.
  2. Klicken Sie auf Networking & Security.

 

 

Bereitgestellte Komponenten anzeigen

 

  1. Klicken Sie auf Installation and Upgrade.
  2. Klicken Sie auf Host Preparation.
  3. Wählen Sie einen Cluster aus der Liste aus (in diesem Beispiel RegionA01-COMP01), um Informationen zum Status der NSX-Hosts in diesem Cluster anzuzeigen.

Sie werden feststellen, dass die Netzwerkvirtualisierungskomponenten, auch Datenebenenkomponenten genannt, auf den Hosts in den Clustern installiert sind. Diese Komponenten beinhalten Folgendes: Kernel-Module auf Hypervisor-Ebene für Portsicherheit, VXLAN, die verteilte Firewall und verteiltes Routing.

Nach der Installation der Netzwerkvirtualisierungskomponenten werden die Firewall- und VXLAN-Funktionen auf jedem Cluster konfiguriert und aktiviert. Das Portsicherheitsmodul stellt die VXLAN-Funktion bereit, während das verteilte Routing-Modul nach der Konfiguration der Steuerungs-VM für den logischen NSX Edge-Router aktiviert wird.

 

 

Topologie nach dem Vorbereiten des Hosts mit Datenpfadkomponenten

 

 

 

VTEP-Konfiguration anzeigen

 

  1. Scrollen Sie in der Liste der angezeigten Hosts nach rechts, bis der Link VIEW DETAILS sichtbar ist.
  2. Klicken Sie auf VIEW DETAILS, um Informationen zu VTEP-Kernel-Port und IP-Adresse des Hosts anzuzeigen.

Die VXLAN-Konfiguration kann in drei wichtige Schritte untergliedert werden:

  • Konfigurieren des VXLAN-Tunnelendpunkts (VTEP) auf jedem Host
  • Konfigurieren des Segment-ID-Bereichs zum Erstellen eines Pools aus logischen Netzwerken: Da in diesem Lab der Unicast-Modus verwendet wird, muss kein Multicast-Bereich angegeben werden. Ansonsten würde dieser Schritt die Konfiguration von Multicast-Gruppenadressen beinhalten.
  • Konfigurieren der Transportzone zur Definition der Reichweite logischer Netzwerke

Wie im Diagramm dargestellt, wurden die Hosts mit VXLAN-Tunnelendpunktschnittstellen (VTEPs) konfiguriert. In der Umgebung wird das Subnetz 192.168.130.0/24 für den VTEP-Pool eingesetzt.

 

 

Konfiguration von Segment-IDs und Multicast-Gruppenadressen

In der Vergangenheit war die Unterstützung von Multicast-Protokollen für physische Netzwerkgeräte eine der größten Herausforderungen bei der VXLAN-Bereitstellung. Diese Herausforderung wurde nun mit der NSX-Plattform bewältigt. Durch das Bereitstellen einer controllerbasierten VXLAN-Implementierung muss Multicast nicht mehr in physischen Netzwerken konfiguriert werden. NSX bietet drei Optionen für „Broadcast, Unknown and Multicast“(BUM)-Datenverkehr: „Multicast“, „Unicast“ und „Hybrid“.  Diese Option wird global als Teil der Transportzone definiert, kann jedoch auch pro logischem Switch explizit definiert werden.

In NSX stehen folgende drei Replikationsmodi zur Verfügung:

  • Multicast: NSX nutzt die native L2-/L3-Multicast-Funktion des physischen Netzwerks, um sicherzustellen, dass in VXLAN gekapselter BUM-Datenverkehr an alle VTEPs gesendet wird. In diesem Modus muss jedem definierten VXLAN-L2-Segment (d.h. logischem Switch) eine Multicast-IP-Adresse zugeordnet werden. Bei dieser Konfiguration wird der Datenverkehr mithilfe der L2-Multicast-Funktion auf alle VTEPs im lokalen Segment (d.h. VTEP-IP-Adressen, die Teil desselben IP-Subnetzes sind) repliziert. Zusätzlich sollte IGMP-Snooping auf den physischen Switches konfiguriert werden, um die Bereitstellung von L2-Multicast-Datenverkehr zu optimieren.
  • Unicast: Die Steuerungsebene wird vom NSX Controller mittels Kopfendereplikation verwaltet. Bei dieser Replikationsmethode werden keine Multicast-IP-Adressen oder besonderen Konfigurationen benötigt.
  • Hybrid: ein optimierter Unicast-Modus. Die Replikation des lokalen Datenverkehrs wird mithilfe von L2-Multicast in das physische Netzwerk ausgelagert. Dies erfordert IGMP-Snooping auf dem lokalen Switch, jedoch kein Multicast-Routing-Protokoll wie PIM. Der Hybridmodus wird für umfangreiche NSX-Bereitstellungen empfohlen.

 

 

Segment-ID-Konfiguration anzeigen

 

  1. Klicken Sie auf Logical Network Settings.
  2. Sehen Sie sich den Segment ID Pool an, der der Umgebung zugewiesen ist. Wenn logische Switches in NSX erstellt werden, wird jedem neuen logischen Switch die nächste freie Segment-ID zugewiesen.
  3. Beachten Sie, dass das Feld Multicast addresses leer ist. Wie bereits erwähnt, liegt dies daran, dass die Lab-Umgebung Unicast als Standardmodus verwendet und daher kein Multicast erforderlich ist.

 

 

Transportzonen anzeigen

 

  1. Klicken Sie auf Transport Zones.
  2. Wählen Sie die Transportzone RegionA0_Global_TZ aus, indem Sie auf das Optionsfeld klicken.

Nach der Beschreibung der verschiedenen NSX-Komponenten und der VXLAN-Konfiguration ist es nun an der Zeit, einen logischen NSX-Switch zu erstellen. Der logische NSX-Switch definiert eine logische Broadcast-Domäne oder ein Netzwerksegment, mit dem eine Anwendung oder virtuelle Maschine logisch verbunden werden kann. Ein logischer NSX-Switch stellt VLAN-ähnliche Layer 2-Broadcast-Domänen bereit, jedoch ohne die für VLANs übliche physische Netzwerkkonfiguration.

 

 

Logische Switches anzeigen

 

  1. Klicken Sie links auf Logical Switches.

Sie werden feststellen, dass bereits mehrere logische Switches in diesem Hands-on Lab definiert wurden. Diese wurden vorkonfiguriert und werden zum Absolvieren der verschiedenen Module des Hands-on Lab benötigt. Bei einer NSX-Neubereitstellung wäre die Liste der logischen Switches leer.

Im nächsten Schritt wird ein neuer logischer Switch erstellt. Sobald dieser Switch erstellt wurde, werden die vorhandenen VMs auf das neu erstellte Netzwerk migriert und mit der NSX-Umgebung verbunden.

 

 

Neuen logischen Switch erstellen

 

  1. Klicken Sie auf das grüne Pluszeichen, um einen neuen logischen Switch zu erstellen.
  2. Benennen Sie den logischen Switch wie folgt: Prod_Logical_Switch.
  3. Vergewissern Sie sich, dass RegionA0_Global_TZ als Transportzone ausgewählt ist.
  4. Stellen Sie sicher, dass Unicast als Replikationsmodus ausgewählt ist.
  5. Überprüfen Sie, ob das Kontrollkästchen Enable IP Discovery aktiviert ist. Durch das Aktivieren der IP-Erkennung kann die ARP-Unterdrückung genutzt werden. Eine Erläuterung dieser Funktion folgt weiter unten.
  6. Klicken Sie auf OK.

Durch die Auswahl des Kontrollkästchens Enable IP Discovery wird die Address Resolution Protocol(ARP)-Unterdrückung aktiviert. Mithilfe von ARP wird die MAC(Media Access Control)-Zieladresse einer IP-Adresse bestimmt, indem ein Broadcast an ein Layer 2-Segment gesendet wird. Wenn ein ESXi-Host mit NSX Virtual Switch ARP-Datenverkehr von einer VM- oder Ethernet-Anfrage empfängt, sendet dieser die Anfrage an den NSX Controller, der über eine ARP-Tabelle verfügt. Wenn die Informationen in der ARP-Tabelle von NSX Controller vorhanden sind, werden diese an den Host zurückgegeben, der dann der VM antwortet.

 

 

Neuen logischen Switch für externen Zugriff zum NSX Edge Services Gateway hinzufügen

 

  1. Wählen Sie den neu erstellten Prod_Logical_Switch aus.
  2. Klicken Sie auf das Menü Actions.
  3. Klicken Sie auf Connect Edge.

 

 

Logischen Switch mit NSX Edge verbinden

 

NSX Edge kann als logischer (verteilter) Router oder Edge Services Gateway installiert werden.

  • Das Edge Services Gateway „Perimeter-Gateway-01“ stellt Netzwerkservices wie DHCP, NAT, Lastausgleich, Firewall und VPN bereit und enthält dynamische Routing-Funktionen.
  • Der logische verteilte Router „Distributed-Router-01“ unterstützt verteiltes und dynamisches Routing.

NSX Edge und -Routing werden in den nachfolgenden Modulen detaillierter behandelt.

Nun muss der logische Switch mit dem NSX Edge Services Gateway „Perimeter-Gateway-01“ verbunden werden. Dadurch wird Konnektivität zwischen den mit dem logischen Switch verbundenen VMs und der restlichen Umgebung hergestellt.

  1. Klicken Sie auf das Optionsfeld links neben Perimeter-Gateway-01.
  2. Klicken Sie auf Next.

 

 

Logischen Switch mit NSX Edge verbinden

 

  1. Klicken Sie auf das Optionsfeld links neben vnic7.
  2. Klicken Sie auf Next.

 

 

Schnittstelle benennen

 

  1. Geben Sie Prod_Interface als Namen ein.
  2. Wählen Sie Connected aus.
  3. Klicken Sie auf das grüne Pluszeichen, um IP-Adresse und Subnetz für diese Schnittstelle zu konfigurieren.

 

 

IP-Adresse für die Schnittstelle zuweisen

 

  1. Geben Sie 172.16.40.1 unter „Primary IP Address“ ein (lassen Sie „Secondary IP Addresses“ leer).
  2. Geben Sie 24 unter „Subnet Prefix Length“ ein.
  3. Überprüfen Sie Ihre Einstellungen und klicken Sie dann auf Next.

 

 

Bearbeitung der Schnittstelle abschließen

 

  1. Klicken Sie auf Finish.

 

 

„web-03a“ und „web-04a“ zum neu erstellten Switch „Prod_Logical_Switch“ hinzufügen

 

  1. Wählen Sie den neu erstellten Prod_Logical_Switch aus.
  2. Klicken Sie auf das Menü Actions.
  3. Klicken Sie auf Add VM.

 

 

Virtuelle Maschinen zum logischen Switch hinzufügen

 

  1. Suchen Sie nach VMs mit dem Wort web im Namen.
  2. Wählen Sie web-03a.corp.local und web-04a.corp.local aus.
  3. Klicken Sie auf den Rechtspfeil, um die ausgewählten VMs zu diesem logischen Switch hinzuzufügen.
  4. Klicken Sie auf Next.

 

 

vNICs der virtuellen Maschinen auswählen, die zum logischen Switch hinzugefügt werden sollen

 

  1. Wählen Sie die vNICs der beiden Web-VMs aus.
  2. Klicken Sie auf Next.

 

 

Hinzufügen von VMs zum logischen Switch abschließen

 

  1. Klicken Sie auf Finish.

 

 

Topologie nach dem Verbinden von „Prod_Logical_Switch“ mit dem NSX Edge Services Gateway

 

Sie haben nun einen neuen logischen Switch konfiguriert und diesen über das Edge Gateway Perimeter-Gateway-01 mit dem externen Netzwerk verbunden. Außerdem haben Sie zwei virtuelle Maschinen zum neuen logischen Switch hinzugefügt.

 

 

Konnektivität zwischen „web-03a“und „web-04a“ testen

Als Nächstes testen Sie die Konnektivität zwischen „web-03a“und „web-04a“.

 

 

Zu „Hosts and Clusters“ navigieren

 

  1. Klicken Sie auf das Haussymbol.
  2. Klicken Sie auf Hosts and Clusters.

 

 

Cluster erweitern

 

Erweitern Sie die Cluster RegionA01-COMP01 und RegionA01-COMP02. Die zwei VMs „web-03a.corp.local“ und „web-04a.corp.local“ befinden sich auf zwei verschiedenen Computing-Clustern. Beachten Sie, dass diese beiden VMs in den vorangegangenen Schritten zum logischen Switch hinzugefügt wurden.

 

 

PuTTY öffnen

 

  1. Klicken Sie auf die Windows-Startschaltfläche.
  2. Klicken Sie im Startmenü auf das PuTTY-Anwendungssymbol.

Sie stellen eine Verbindung über die Hauptkonsole her, die sich im Subnetz 192.168.110.0/24 befindet. Der Datenverkehr wird über Perimeter-Gateway-01 von NSX Edge und anschließend an den Webserver geleitet.

 

 

SSH-Sitzung für „web-03a“ öffnen

 

  1. Scrollen Sie durch die Liste der gespeicherten Sitzungen, bis web-03a.corp.local angezeigt wird.
  2. Klicken Sie auf web-03a.corp.local.
  3. Klicken Sie auf Load, um die Sitzungsinformationen abzurufen.
  4. Klicken Sie auf Open, um eine PuTTY-Sitzung für die VM zu starten.

 

 

Bei der VM anmelden

 

  • Wenn Sie von einer PuTTY-Sicherheitswarnung entsprechend aufgefordert werden, klicken Sie auf Yes, um den Hostschlüssel des Servers anzunehmen.
  • Wenn Sie nicht automatisch angemeldet wurden, melden Sie sich als Anwender root mit dem Kennwort VMware1! an.

Hinweis: Wenn beim Verbinden mit „web-03a.corp.local“ Probleme auftreten, überprüfen Sie, ob die vorangegangenen Schritte ordnungsgemäß durchgeführt wurden.

 

 

Webserver „web-04a.corp.local“ anpingen

 

Geben Sie „ping -c 2 web-04a“ ein, um zwei Pings anstatt eines kontinuierlichen Ping zu senden.

ping -c 2 web-04a

Hinweis: web-04a.corp.local hat die IP-Adresse 172.16.40.12. Bei Bedarf können Sie auch nach IP-Adresse pingen.

Falls Sie DUP!- Pakete sehen: Diese werden aufgrund der geschachtelten Lab-Umgebung von VMware angezeigt. In einer Produktionsumgebung sind sie nicht zu sehen.

Schließen Sie die PuTTY-Sitzung nicht. Minimieren Sie das Fenster zur späteren Verwendung.

 

Skalierbarkeit und Verfügbarkeit


In diesem Abschnitt werden Skalierbarkeit und Verfügbarkeit der NSX Controller behandelt. Der NSX Controller-Cluster ist die Komponente der Steuerungsebene, die für das Management der Switching- und Routing-Module in den Hypervisoren verantwortlich ist. Der NSX Controller-Cluster besteht aus drei NSX Controller-Knoten, die jeweils bestimmte logische Objekte verwalten. Durch die Verwendung eines NSX Controller-Clusters für das Management von VXLAN-basierten logischen Switches wird keine Multicast-Unterstützung in der physischen Netzwerkinfrastruktur benötigt.

Für eine optimale Stabilität und Performance muss in Produktionsumgebungen ein NSX Controller-Cluster mit drei NSX Controller-Knoten bereitgestellt werden. Der NSX Controller-Cluster stellt ein horizontal skalierbares verteiltes System dar, in dem jedem NSX Controller-Knoten verschiedene Rollen zugewiesen werden. Anhand der zugewiesenen Rolle werden die Aufgabenarten definiert, die von einem NSX Controller-Knoten implementiert werden können. Die aktuell unterstützte Konfiguration erlaubt eine vollständig aktive Lastverteilung sowie Redundanz.

Für eine bessere Skalierbarkeit der NSX-Architektur wird ein „Segmentierungsmechanismus“ verwendet, damit alle NSX Controller-Knoten jederzeit aktiv sein können.

Wenn ein NSX Controller ausfällt, hat dies keine Auswirkungen auf den Datenverkehr der Datenebene (VM). Der Datenverkehr fließt weiterhin wie gewohnt, da die logischen Netzwerkinformationen bereits auf die logischen Switches (Datenebene) übertragen wurden. Jedoch können Sie ohne die Steuerungsebene (NSX Controller-Cluster) keine Anpassungen (Hinzufügen/Verschieben/Ändern) vornehmen.

Zusätzlich verfügt NSX nun über Controller Disconnected Operation(CDO)-Funktionen. Im CDO-Modus wird ein spezieller logischer Switch erstellt, dem alle Hosts beitreten. So entsteht eine zusätzliche Redundanzschicht für die Datenebenenkonnektivität, falls Hosts in der NSX-Umgebung nicht auf die Controller zugreifen können. Weitere Informationen zum CDO-Modus erhalten Sie über einen Link im Modulfazit.


 

Skalierbarkeit und Verfügbarkeit der NSX Controller

 

  1. Klicken Sie auf das Haussymbol.
  2. Klicken Sie auf Networking & Security.

 

Modul 2 – Fazit


In diesem Modul haben Sie folgende Vorteile der NSX-Plattform kennengelernt:

  1. Netzwerkagilität, einschließlich der einfachen Bereitstellung und Konfiguration logischer Switches zur Verbindung mit virtuellen Maschinen und externen Netzwerken
  2. Skalierbarkeit der NSX-Architektur, z.B. clusterübergreifende Transportzonen, oder Bereitstellen von Netzwerkservices über den NSX Controller-Cluster ohne Neukonfiguration des physischen Netzwerks

 

Abschluss von Modul 2

Sie haben Modul 2 abgeschlossen.

Weitere Informationen zum Bereitstellen von NSX finden Sie im NSX 6.4 Documentation Center unter der folgenden URL:

Weitere Informationen zum NSX Controller Disconnected Operation(CDO)-Modus finden Sie unter folgendem Link:

Fahren Sie mit einem der folgenden Module fort:

Liste der Module des Hands-on Lab:

Hands-on Lab-Dozenten:

  • Module 1 – 4: Joe Collon, Staff NSX Systems Engineer, USA

 

 

Hands-on Lab beenden

 

Klicken Sie auf die Schaltfläche END, wenn Sie Ihr Hands-on Lab beenden möchten.  

 

Modul 3 – Logisches Routing (60 Minuten)

Logisches Routing – Modulübersicht


Im vorangegangenen Modul haben Sie gelernt, wie Sie mit nur wenigen Klicks isolierte logische Switches/Netzwerke erstellen können. Um die Kommunikation zwischen diesen isolierten Layer 2-Netzwerken zu gewährleisten, ist Routing unerlässlich. In der NSX-Plattform können Sie dank des verteilten logischen Routers Datenverkehr zwischen logischen Switches vollständig im Hypervisor routen. Durch diese logische Routing-Komponente kann NSX komplexe Routing-Topologien im logischen Bereich reproduzieren. Ein Beispiel dafür wäre eine dreischichtige Anwendung, die mit drei logischen Switches verbunden wird, wobei das Routing zwischen den Schichten von diesem verteilten logischen Router übernommen wird.

In diesem Modul werden Sie einige der Routing-Funktionen in der NSX-Plattform kennenlernen und erfahren, wie Sie diese beim Bereitstellen einer dreischichtigen Anwendung verwenden können.

In diesem Modul werden folgende Themen behandelt:

  • Überprüfen des Datenverkehrsflusses, wenn das Routing von einem externen physischen Router oder vom NSX Edge Services Gateway verwaltet wird
  • Konfigurieren des verteilten logischen Routers und seiner logischen Schnittstellen (Logical Interfaces, LIFs) zum Routing zwischen Web-, Anwendungs- und Datenbankschicht der dreischichtigen Anwendung
  • Konfigurieren dynamischer Routing-Protokolle auf dem verteilten logischen Router und dem Edge Services Gateway sowie Überblick über die Steuerung interner Routen-Ankündigungen für externe Upstream-Router
  • Skalieren und Schützen des NSX Edge Services Gateways mithilfe von Routing-Protokollen und Equal-Cost Multi-Path(ECMP)-Routing

 

Spezielle Anweisungen für CLI-Befehle

 

Bei vielen Modulen müssen Sie Command Line Interface(CLI)-Befehle eingeben. Zum Senden von CLI-Befehlen an das Hands-on Lab stehen zwei Methoden zur Verfügung.

Bei der ersten Methode senden Sie einen CLI-Befehl an die Lab-Konsole:

  1. Markieren Sie den CLI-Befehl im Handbuch und kopieren Sie ihn mit STRG+C in die Zwischenablage.
  2. Klicken Sie im Konsolenmenü auf SEND TEXT.
  3. Drücken Sie STRG+V, um den Befehl aus der Zwischenablage in das Fenster einzufügen.
  4. Klicken Sie auf die Schaltfläche SEND.

Zweite Methode: Eine Textdatei (README.txt) wurde auf dem Desktop der Umgebung abgelegt. Mit dieser können Sie komplexe Befehle oder Kennwörter ganz einfach kopieren und in die jeweiligen Dienstprogramme (CMD, PuTTY, Konsole etc.) einfügen. Bestimmte Zeichen sind nicht auf allen Tastaturen weltweit vorhanden. Diese Textdatei ist auch für Tastaturen vorgesehen, die solche Zeichen nicht enthalten.

Die Textdatei heißt „README.txt“ und befindet sich auf dem Desktop.  

 

Dynamisches und verteiltes Routing


Bei einem verteilten logischen Router (Distributed Logical Router, DLR) handelt es sich um eine virtuelle Appliance. Sie umfasst die Routing-Steuerungsebene und verteilt gleichzeitig die Datenebene in Kernel-Modulen an jeden Hypervisor-Host. Die Funktion der DLR-Steuerungsebene basiert auf NSX Controller-Clustern. Diese müssen Routing-Updates an die Kernel-Module weiterleiten. Dadurch wird das Ost-West-Routing in jedem einzelnen lokalen Hypervisor optimiert, da Datenverkehr nicht mehr über einen zentralen Netzwerkpunkt geleitet werden muss.

Um die Vorteile des Routings auf Kernel-Ebene besser verstehen zu können, lernen Sie zuerst die Konfiguration des verteilten Routings kennen.


 

Aktuelle Topologie und Paketfluss

 

In der obigen Abbildung sehen Sie die Lab-Umgebung, in der sich die Anwendungs- und Datenbank-VMs auf demselben physischen Host befinden. Die roten Pfeile zeigen den Datenverkehrsfluss zwischen den beiden VMs an.

  1. Der Datenverkehr verlässt die Anwendungs-VM und erreicht den Host.
  2. Da sich Anwendungs- und Datenbank-VM nicht im selben Netzwerksubnetz befinden, muss der Datenverkehr an ein Layer 3-Gerät gesendet werden. Das Perimeter-Gateway von NSX Edge befindet sich im Management-Cluster und fungiert als Layer 3-Gateway. Der Datenverkehr wird an den Host gesendet, auf dem sich das Perimeter-Gateway befindet.
  3. Der Datenverkehr erreicht das Perimeter-Gateway.
  4. Das Perimeter-Gateway routet das Paket und sendet es zurück an den Host im Zielnetzwerk.
  5. Der geroutete Datenverkehr wird zurück an den Host gesendet, auf dem sich die Datenbank-VM befindet.
  6. Der Datenverkehr wird vom Host an die Datenbank-VM weitergeleitet.

Das Datenverkehrsflussdiagramm wird im Anschluss an die Konfiguration des verteilten Routings am Ende dieses Hands-on Lab nochmal genauer unter die Lupe genommen. Dadurch können Sie den positiven Einfluss des verteilten Routings auf den Netzwerkdatenverkehr besser nachvollziehen.

 

 

Auf vSphere Web Client (Flash) zugreifen

 

  1. Starten Sie den vSphere Web Client (Flash) über das Google Chrome-Symbol auf dem Desktop.

 

 

Beim vSphere Web Client (Flash) anmelden

 

Wenn Sie noch nicht beim vSphere Web Client angemeldet sind:

(Die Startseite sollte der vSphere Web Client sein. Falls nicht, klicken Sie auf das vSphere Web (Flash)-Symbol in Google Chrome.)

  1. Geben Sie administrator@vsphere.local in das Feld „User name“ ein.
  2. Geben Sie VMware1! in das Feld „Password“ ein.
  3. Klicken Sie auf Login.

 

 

Funktionen der dreischichtigen Anwendung überprüfen

 

  1. Öffnen Sie eine neue Registerkarte in Ihrem Browser.
  2. Klicken Sie auf das Lesezeichen Customer DB App.

 

Vor der Konfiguration des verteilten Routings muss überprüft werden, ob die dreischichtige Anwendung ordnungsgemäß funktioniert. Die drei Schichten der Anwendung (Web, Anwendung und Datenbank) befinden sich auf verschiedenen logischen Switches. Das Routing zwischen den Schichten erfolgt mithilfe eines NSX Edge Services Gateways.

  • Der Webserver gibt eine Seite mit Kundeninformationen aus der Datenbank aus.

 

 

Anwendungs- und Datenbankschnittstellen aus dem Perimeter-Edge entfernen

 

Wie Sie bereits in der vorangegangenen Topologie gesehen haben, befinden sich die drei Anwendungsschichten auf schichtspezifischen logischen Switches, die vom Perimeter-Gateway (NSX ESG) geroutet werden. Sie aktualisieren nun die Topologie, indem Sie die Anwendungs- und Datenbankschnittstellen aus dem Perimeter-Gateway entfernen. Nach dem Entfernen dieser Schnittstellen verschieben Sie diese auf den verteilten Router (NSX DLR). Um Zeit zu sparen, wurde bereits ein verteilter Router für Sie bereitgestellt.

  1. Klicken Sie auf die Browser-Registerkarte vSphere Web Client.
  2. Klicken Sie auf das Haussymbol.
  3. Klicken Sie auf Networking & Security.

 

 

Anwendungs- und Datenbankschnittstellen zum verteilten Router hinzufügen

 

Beginnen Sie mit der Konfiguration des verteilten Routings, indem Sie die Anwendungs- und Datenbankschnittstellen zum verteilten Router (NSX Edge) hinzufügen.

  1. Doppelklicken Sie auf Distributed-Router-01.

 

 

Dynamisches Routing auf dem verteilten Router konfigurieren

 

Kehren Sie zur Browser-Registerkarte vSphere Web Client zurück.

  1. Klicken Sie auf Routing.
  2. Klicken Sie auf Global Configuration.
  3. Klicken Sie auf Edit, um den Abschnitt Dynamic Routing Configuration zu bearbeiten.

 

 

Abschnitt „Dynamic Routing Configuration“ bearbeiten

 

  1. Wählen Sie die IP-Adresse der Uplink-Schnittstelle als standardmäßige Router-ID aus. In diesem Fall ist die Uplink-Schnittstelle Transit_Network_01 und die IP-Adresse lautet 192.168.5.2.
  2. Klicken Sie auf OK.

Hinweis: Die Router-ID ist eine 32-Bit-Kennung und wird als IP-Adresse angegeben. Sie ist wichtig für den OSPF-Betrieb, da sie die Identität des Routers in einem autonomen System angibt. In diesem Hands-on Lab-Szenario wird eine Router-ID verwendet, die mit der IP-Adresse der Uplink-Schnittstelle in NSX Edge identisch ist. Sie werden zurück zum Abschnitt Global Configuration mit der Option Publish Changes geleitet.

Vergewissern Sie sich, dass im Feld „Router ID“ die mit dem logischen Switch „Transit_Network“ verknüpfte IP-Adresse 192.168.5.2 angezeigt wird. Falls die Konfigurationsänderung nicht erfolgreich angewendet wurde, bleibt dieses Feld leer. Ist dies der Fall, wiederholen Sie die Schritte 1 und 2, um die Router-ID erneut anzuwenden.

 

 

OSPF-spezifische Parameter konfigurieren

 

Als dynamisches Routing-Protokoll zwischen „Perimeter-Gateway-01“ und „Distributed-Router-01“ wird OSPF verwendet. Dadurch können die beiden Router Informationen zu ihren bekannten Routen austauschen.

  1. Klicken Sie auf OSPF.
  2. Klicken Sie auf Edit, um die OSPF-Konfiguration zu ändern. Dadurch wird das Dialogfeld OSPF Configuration geöffnet.

 

 

OSPF-Routing auf dem Perimeter-Edge konfigurieren

 

Als Nächstes wird dynamisches Routing auf „Perimeter-Gateway-01“ (NSX Edge) konfiguriert, um die Verbindung mit der dreischichtigen Anwendung wiederherzustellen.

  1. Klicken Sie so lange auf Back, bis Sie zur Übersichtsseite NSX Edges mit der Liste der „edge“-Installationen gelangen.

 

 

Neue Topologie

 

In der neuen Topologie erfolgt ein Routen-Peering zwischen verteiltem Router und Perimeter-Gateway (NSX Edge). Routen zu einem mit dem verteilten Router verbundenen Netzwerk werden mittels OSPF an das Perimeter-Gateway (NSX Edge) weitergeleitet. Darüber hinaus werden auch alle Routen vom Perimeter-Gateway mittels BGP an den vPod-Router des physischen Netzwerks weitergeleitet.

Dies wird im folgenden Abschnitt näher erläutert.

 

 

Kommunikation mit der dreischichtigen Anwendung überprüfen

 

Routing-Informationen werden nun zwischen verteiltem Router und Perimeter-Gateway ausgetauscht. Sobald das Routing zwischen beiden NSX Edges eingerichtet wurde, wird die Verbindung mit der dreischichtigen Webanwendung wiederhergestellt. Überprüfen Sie, ob das Routing funktioniert, indem Sie auf die dreischichtige Webanwendung zugreifen.

  1. Klicken Sie auf die Browser-Registerkarte HOL - Customer Database (diese wurde in einem vorherigen Schritten geöffnet). Die Seite zeigt möglicherweise noch 504 Gateway Time-out von einem vorangegangenen Versuch an.
  2. Klicken Sie auf das Aktualisierungssymbol.

Hinweis: Aufgrund der geschachtelten Hands-on Lab-Umgebung kann es einen Moment dauern, bis die Routen weitergegeben werden.

 

 

Dynamisches und verteiltes Routing – Abschluss

In diesem Abschnitt wurden dynamisches und verteiltes Routing erfolgreich konfiguriert. Im nächsten Abschnitt wird das zentrale Routing mit dem Perimeter-Gateway (NSX Edge) erläutert.

 

Zentrales Routing


In diesem Abschnitt werden verschiedene Elemente näher beleuchtet, um die Konfiguration des Northbound-Routings über das NSX Edge Services Gateway (ESG) zu erläutern. Dazu zählen Steuerung, Aktualisierung und Verteilung von dynamischem Routing innerhalb der NSX-Umgebung. Sie werden prüfen, ob die Routen zwischen der ESG-Appliance des NSX-Perimeters und der virtuellen Router-Appliance (vPod-Router), die das gesamte Hands-on Lab ausführt und routet, ausgetauscht werden.

Besonderer Hinweis: Auf dem Desktop finden Sie die Datei „README.txt“. Sie enthält die für diese Lab-Übung erforderlichen CLI-Befehle. Sie müssen diese nicht manuell eingeben, sondern können sie kopieren und in die PuTTY-Sitzungen einfügen. Wenn Sie eine Zahl mit „spitzen Klammern - {1},“ sehen, finden Sie den CLI-Befehl für dieses Modul in der Textdatei.


 

Aktuelle Lab-Topologie

 

Im oben aufgeführten Diagramm wird die aktuelle Topologie gezeigt, bei der OSPF für den Austausch von Routen zwischen Perimeter-Gateway und verteiltem Router verwendet wird. Außerdem sehen Sie die Northbound-Verbindung vom Perimeter-Gateway zum vPod-Router. Diese Router tauschen Routing-Informationen über BGP aus.

 

 

OSPF-Routing im Perimeter-Gateway anzeigen

Als Erstes muss überprüft werden, ob die Webanwendung funktioniert. Anschließend melden Sie sich beim NSX-Perimeter-Gateway an, um die OSPF-Nachbarn und die bestehenden Routeninformationen anzuzeigen. Dabei werden Sie sehen, wie das Perimeter-Gateway Routen sowohl vom verteilten Router als auch vom vPod-Router erhält, der dieses Lab ausführt.

 

 

Funktionen der dreischichtigen Anwendung überprüfen

 

  1. Öffnen Sie eine neue Registerkarte in Ihrem Browser.
  2. Klicken Sie auf das Lesezeichen Customer DB App.

 

 

BGP-Nachbarn anzeigen

 

Zeigen Sie die BGP-Nachbarn von „Perimeter-Gateway-01“ an.

  1. Geben Sie show ip bgp neighbors ein.
show ip bgp neighbors

 

 

Angezeigte Informationen zu BGP-Nachbarn überprüfen

 

Überprüfen Sie die Informationen zu den BGP-Nachbarn.

  1. BGP neighbor is 192.168.100.1: Dies ist die Router-ID des vPod-Routers innerhalb der NSX-Umgebung.
  2. Remote AS 65002: Dies ist die autonome Systemnummer des externen vPod-Routernetzwerks.
  3. BGP state = Established, up: Dies bedeutet, dass die BGP-Nachbarschaft hergestellt wurde und die BGP-Router Aktualisierungspakete zum Austauschen der Routing-Informationen senden werden.

 

 

Routen auf Perimeter-Edge und deren Ursprung überprüfen

 

Beobachten Sie die verfügbaren Routen auf „Perimeter-Gateway-01“.

  1. Geben Sie show ip route ein.
show ip route

 

 

BGP-Routenverteilung steuern

Es gibt Szenarien, in denen BGP-Routen nur in der virtuellen Umgebung verteilt, jedoch nicht in der physischen Umgebung sichtbar sein sollen. Die Routenverteilung kann ganz einfach innerhalb der NSX Edge-Konfiguration gesteuert und gefiltert werden.

 

ECMP und Hochverfügbarkeit


In diesem Abschnitt fügen Sie ein zweites Perimeter-Gateway zum Netzwerk hinzu und verwenden anschließend Equal-Cost Multi-Path(ECMP)-Routing, um die Edge-Kapazität und -Verfügbarkeit horizontal zu skalieren. Mit NSX ist es möglich, ein Edge-Gerät in-place hinzuzufügen und ECMP zu aktivieren.

ECMP ist eine Routing-Funktion, mit der sich Pakete über mehrere redundante Pfade weiterleiten lassen. Diese Pfade können statisch oder als Ergebnis von Kennzahlberechnungen bei Verwendung von dynamischen Routing-Protokollen wie OSPF oder BGP hinzugefügt werden. Nachdem für eine bestimmte Quelle ein nächster Hop und ein Ziel-IP-Adresspaar ausgewählt wurden, speichert der Routen-Cache den ausgewählten Pfad. Alle Pakete für diesen Datenfluss werden an den ausgewählten nächsten Hop geleitet. Der verteilte logische Router nutzt einen XOR-Algorithmus, um den nächsten Hop aus einer Liste potenzieller ECMP-Pfade auszuwählen. Dieser Algorithmus verwendet die Quell- und Ziel-IP-Adresse auf dem ausgehenden Paket als Entropiequellen.

In diesem Modul konfigurieren Sie ein neues Perimeter-Gateway und richten einen ECMP-Cluster zwischen den Perimeter-Gateways und dem verteilten logischen Router ein, um sich die höhere Kapazität und Verfügbarkeit zunutze zu machen. Zum Testen der Verfügbarkeit wird eines der Perimeter-Gateways heruntergefahren und der daraus resultierende Routing-Pfad beobachtet.


 

Zu NSX im vSphere Web Client navigieren

 

  1. Klicken Sie auf die Browser-Registerkarte vSphere Web Client.
  2. Klicken Sie auf das Haussymbol.
  3. Klicken Sie auf Networking & Security.

 

 

Edge des Perimeter-Gateways ändern

 

Zunächst müssen Sie das vorhandene NSX Edge des Perimeter-Gateways ändern, um die sekundäre IP-Adresse zu entfernen:

  1. Klicken Sie auf NSX Edges.
  2. Doppelklicken Sie auf Perimeter-Gateway-01.

 

 

 

  1. Klicken Sie auf Manage.
  2. Klicken Sie auf Settings.
  3. Klicken Sie auf Interfaces.
  4. Wählen Sie vNIC 0 aus.
  5. Klicken Sie zum Bearbeiten auf das Stiftsymbol.

 

 

Sekundäre IP-Adresse entfernen

 

  1. Klicken Sie zum Bearbeiten auf das Stiftsymbol.
  2. Klicken Sie auf das X, um die sekundäre IP-Adresse zu löschen.

Sie werden diese sekundäre IP-Adresse kurzzeitig in den folgenden Schritten für das neue Perimeter-Gateway verwenden.

 

 

Änderung bestätigen

 

  1. Klicken Sie auf OK.

Hinweis: Wenn die Schaltflächen „OK“ und „Cancel“ nicht sichtbar sind, müssen Sie möglicherweise auf das Dialogfenster „Edit NSX Edge Interface“ klicken und es verschieben. Dies liegt an der eingeschränkten Bildschirmauflösung des Hands-on Lab.

 

 

Zu „NSX Edges“ zurückkehren

 

  1. Klicken Sie so lange auf Back, bis Sie zur Übersichtsseite NSX Edges mit der Liste der „edge“-Installationen gelangen.

 

 

Zusätzliches Perimeter-Gateway-Edge hinzufügen

 

 

 

Edge auswählen und benennen

 

  1. Wählen Sie Edge Services Gateway neben „Install Type“ aus.
  2. Geben Sie Perimeter-Gateway-02 in das Feld „Name“ ein.
  3. Klicken Sie auf Next.

 

 

Kennwort festlegen

 

  1. Geben Sie VMware1!VMware1! in das Feld „Password“ ein.
  2. Geben Sie VMware1!VMware1! in das Feld „Confirm password“ ein.
  3. Aktivieren Sie das Kontrollkästchen Enable SSH access.
  4. Klicken Sie auf Next.

Hinweis: Alle Kennwörter für NSX Edges sind komplexe Kennwörter mit mindestens 12 Zeichen.

 

 

Edge-Appliance hinzufügen

 

  1. Klicken Sie auf das grüne Pluszeichen. Daraufhin wird das Dialogfeld Add NSX Edge Appliance angezeigt.
  2. Wählen Sie aus der Dropdown-Liste „Cluster/Resource Pool“ RegionA01-MGMT01 aus.
  3. Wählen Sie RegionA01-ISCSI01-COMP01 aus der Dropdown-Liste „Datastore“ aus.
  4. Wählen Sie aus der Dropdown-Liste „Host“ esx-04a.corp.local aus.
  5. Klicken Sie auf OK.

 

 

Mit der Bereitstellung fortfahren

 

  1. Klicken Sie auf Next.

 

 

 

  1. Klicken Sie auf das grüne Pluszeichen. Dadurch wird die erste Schnittstelle hinzugefügt.

 

 

Zu verbindenden Switch auswählen

 

Für dieses Perimeter-Gateway müssen Sie die Northbound-Switch-Schnittstelle (eine verteilte Portgruppe) auswählen.

  1. Klicken Sie auf den Link Select rechts neben Connected To.
  2. Klicken Sie auf Distributed Virtual Port Group.
  3. Klicken Sie auf das Optionsfeld links neben Uplink-RegionA01-vDS-MGMT.
  4. Klicken Sie auf OK.

 

 

Name und IP hinzufügen

 

  1. Geben Sie Uplink in das Feld „Name“ ein.
  2. Wählen Sie neben „Type“ Uplink aus.
  3. Klicken Sie auf das grüne Pluszeichen.
  4. Geben Sie 192.168.100.4 unter „Primary IP Address“ ein.
  5. Geben Sie 24 unter „Subnet Prefix Length“ ein.
  6. Klicken Sie auf OK.

 

 

Edge-Transitschnittstelle hinzufügen

 

  1. Klicken Sie auf das grüne Pluszeichen. Dadurch wird die zweite Schnittstelle hinzugefügt.

 

 

Zu verbindenden Switch auswählen

 

Für dieses Perimeter-Gateway müssen Sie die Northbound-Switch-Schnittstelle (VXLAN-gestützter logischer Switch) auswählen.

  1. Klicken Sie neben Connected To auf Select.
  2. Klicken Sie auf Logical Switch.
  3. Klicken Sie auf das Optionsfeld links neben Transit_Network_01 (5005).
  4. Klicken Sie auf OK.

 

 

Name und IP hinzufügen

 

  1. Geben Sie Transit_Network_01 in das Feld „Name“ ein.
  2. Wählen Sie neben „Type“ Internal aus.
  3. Klicken Sie auf das grüne Pluszeichen.
  4. Geben Sie 192.168.5.4 unter „Primary IP Address“ ein.
  5. Geben Sie 29 unter „Subnet Prefix Length“ ein. Stellen Sie sicher, dass Sie die korrekte Subnetzpräfixlänge (29) angeben, damit das Hands-on Lab ordnungsgemäß funktioniert.
  6. Klicken Sie auf OK.

 

 

Mit der Bereitstellung fortfahren

 

Stellen Sie sicher, dass IP-Adressen und Subnetzpräfixlänge den Werten in der obigen Abbildung entsprechen.

  1. Klicken Sie auf Next.

 

 

Standard-Gateway entfernen

 

Da die Informationen über OSPF empfangen werden, muss das Standard-Gateway entfernt werden.

  1. Deaktivieren Sie das Kontrollkästchen Configure Default Gateway.
  2. Klicken Sie auf Next.

 

 

Firewall-Standardeinstellungen

 

  1. Aktivieren Sie das Kontrollkästchen Configure Firewall default policy.
  2. Wählen Sie neben „Default Traffic Policy“ Accept aus.
  3. Klicken Sie auf Next.

 

 

Bereitstellung abschließen

 

  1. Klicken Sie auf Finish. Hiermit beginnt die Bereitstellung.

 

 

Edge-Bereitstellung

 

Die Bereitstellung des NSX Edge dauert einige Minuten.

  1. Während der Bereitstellung von „Perimeter-Gateway-02“ wird im Abschnitt „NSX Edges“ 1 Installing angezeigt.
  2. Für den Status von „Perimeter-Gateway-02“ wird Busy angezeigt. Dies bedeutet, dass die Bereitstellung durchgeführt wird.
  3. Klicken Sie auf die Aktualisierungsschaltfläche im vSphere Web Client, um den Bereitstellungsstatus von „Perimeter-Gateway-02“ zu aktualisieren.

Sobald „Perimeter-Gateway-02“ den Status „Deployed“ aufweist, können Sie mit dem nächsten Schritt fortfahren.

 

 

Routing auf dem neuen Edge konfigurieren

 

Bevor ECMP aktiviert werden kann, müssen Sie OSPF auf „Perimeter-Gateway-02“ (NSX Edge) konfigurieren.

  1. Doppelklicken Sie auf Perimeter-Gateway-02.

Hinweis: Falls der Name des Gateways nicht vollständig sichtbar ist, bewegen Sie den Mauszeiger über den Namen.

 

 

ECMP aktivieren

 

Als Nächstes müssen Sie ECMP auf dem verteilten Router und den Perimeter-Gateways aktivieren.

  1. Klicken Sie so lange auf Back, bis Sie zur Übersichtsseite NSX Edges mit der Liste der „edge“-Installationen gelangen.

 

 

Topologieübersicht

 

Die Abbildung zeigt die Lab-Topologie zum jetzigen Zeitpunkt. Diese umfasst das neu hinzugefügte Perimeter-Gateway, die Routing-Konfiguration sowie die aktivierte ECMP-Funktion.

 

 

ECMP-Funktion über verteilten Router testen

 

Als Nächstes greifen Sie auf den verteilten Router zu, um sicherzustellen, dass OSPF kommuniziert und ECMP funktioniert.

  1. Klicken Sie auf das Haussymbol.
  2. Klicken Sie auf VMs and Templates.

 

 

ECMP-Funktion über vPod-Router testen

 

Hinweis: Um den Mauszeiger aus dem Fenster freizugeben, drücken Sie die Tasten Strg + Alt.

Als Nächstes testen Sie die ECMP-Funktion über den vPod-Router, der einen physischen Router in Ihrem Netzwerk simuliert.

  1. Klicken Sie auf das PuTTY-Symbol in der Taskleiste.

 

 

„Perimeter-Gateway-01“ herunterfahren

 

Im nächsten Schritt simulieren Sie den Ausfall eines Knotens, indem Sie Perimeter-Gateway-01 herunterfahren.

Kehren Sie zur Browser-Registerkarte „vSphere Web Client“ zurück.

  1. Erweitern Sie RegionA01.
  2. Klicken Sie mit der rechten Maustaste auf Perimeter-Gateway-01-0.
  3. Klicken Sie auf Power.
  4. Klicken Sie auf Shut Down Guest OS.

 

 

Hochverfügbarkeit mit ECMP testen

 

Mit den aktivierten ECMP-, BGP- und OSPF-Funktionen in der Umgebung können Sie Routen beim Ausfall eines bestimmten Pfads dynamisch ändern. Sie simulieren nun einen Ausfall eines Pfads mit anschließender Routenumverteilung.

  1. Klicken Sie in der Taskleiste auf das Symbol für die Eingabeaufforderung.

 

 

Auf VM-Konsole des verteilten Routers zugreifen

 

  1. Klicken Sie auf die Browser-Registerkarte Distributed-01-0.

Beim Starten der VM-Konsole in der Browser-Registerkarte wird ein schwarzer Bildschirm angezeigt. Klicken Sie in den schwarzen Bildschirm und drücken Sie mehrmals die Eingabetaste, damit der Bildschirmschoner ausgeblendet und die VM-Konsole angezeigt wird.

 

 

„Perimeter-Gateway-01“ einschalten

 

Kehren Sie zur Browser-Registerkarte „vSphere Web Client“ zurück.

  1. Erweitern Sie RegionA01.
  2. Klicken Sie mit der rechten Maustaste auf Perimeter-Gateway-01-0.
  3. Klicken Sie auf Power.
  4. Klicken Sie auf Power On.

 

 

Zum Ping-Test zurückkehren

 

  • Kehren Sie über die Taskleiste zurück zur Eingabeaufforderung, in der der Ping-Test ausgeführt wird.

 

 

Auf VM-Konsole des verteilten Routers zugreifen

 

  1. Klicken Sie auf die Browser-Registerkarte Distributed-01-0.

Beim Starten der VM-Konsole in der Browser-Registerkarte wird ein schwarzer Bildschirm angezeigt. Klicken Sie in den schwarzen Bildschirm und drücken Sie mehrmals die Eingabetaste, damit der Bildschirmschoner ausgeblendet und die VM-Konsole angezeigt wird.

 

Vor der Durchführung von Modul 4 – Führen Sie die folgenden Bereinigungsschritte durch


Falls Sie nach dem Abschluss von Modul 2 mit einem weiteren Modul dieses Lab fortfahren möchten, müssen Sie die folgenden Schritte ausführen, damit das Lab ordnungsgemäß funktioniert.


 

Zweites Perimeter-Edge-Gerät löschen

 

Kehren Sie zur Browser-Registerkarte „vSphere Web Client“ zurück.

  1. Klicken Sie auf das Haussymbol.
  2. Klicken Sie auf Networking & Security.

 

 

„Perimeter-Gateway-02“ löschen

 

Sie müssen das zuvor erstellte „Perimeter-Gateway-02“ löschen.

  1. Klicken Sie auf NSX Edges.
  2. Wählen Sie Perimeter-Gateway-02 aus.
  3. Klicken Sie auf das rote X, um Perimeter-Gateway-02 zu löschen.

 

 

Löschvorgang bestätigen

 

  1. Klicken Sie auf Yes.

 

 

ECMP auf DLR und „Perimeter-Gateway-01“ deaktivieren

 

  1. Doppelklicken Sie auf Distributed-Router-01.

 

 

ECMP auf verteiltem Router deaktivieren

 

  1. Klicken Sie auf Manage.
  2. Klicken Sie auf Routing.
  3. Klicken Sie auf Global Configuration.
  4. Klicken Sie auf Stop.

 

 

Änderung veröffentlichen

 

  1. Klicken Sie auf Publish Changes, um die Konfigurationsänderung zu aktivieren.

 

 

Zu Edge-Geräten zurückkehren

 

  1. Klicken Sie so lange auf Back, bis Sie zur Übersichtsseite NSX Edges mit der Liste der „edge“-Installationen gelangen.

 

 

Auf „Perimeter-Gateway-01“ zugreifen

 

  1. Doppelklicken Sie auf Perimeter-Gateway-01.

 

 

ECMP auf „Perimeter-Gateway-01“ deaktivieren

 

  1. Klicken Sie auf Manage.
  2. Klicken Sie auf Routing.
  3. Klicken Sie auf Global Configuration.
  4. Klicken Sie auf Stop.

 

 

Änderung veröffentlichen

 

  1. Klicken Sie auf Publish Changes, um die Konfigurationsänderung zu aktivieren.

 

 

Firewall auf „Perimeter-Gateway-01“ aktivieren

 

  1. Klicken Sie auf Manage.
  2. Klicken Sie auf Firewall.
  3. Klicken Sie auf Start.

 

 

Änderung veröffentlichen

 

  1. Klicken Sie auf Publish Changes, um die Konfiguration auf „Perimeter-Gateway-01“ (NSX Edge) zu aktualisieren.

 

Modul 3 – Fazit


In diesem Modul wurden die Routing-Funktionen von NSX Distributed Logical Router (DLR) und Edge Services Gateway (ESG) anhand folgender Aufgaben erläutert:

  1. Migration der logischen Switches vom Edge Services Gateway (ESG) auf den Distributed Logical Router (DLR)
  2. Konfiguration des dynamischen Routings zwischen ESG und DLR mittels OSPF
  3. Überprüfen der zentralen Routing-Funktionen von ESG, einschließlich dynamischem Routen-Peering
  4. Veranschaulichen der ESG-Skalierbarkeit sowie -Verfügbarkeit durch Bereitstellen eines zweiten ESG und Einrichten von Routen-Peering zwischen den ESGs über eine Equal-Cost Multi-Path(ECMP)-Routing-Konfiguration
  5. Entfernen der ESG2- und ECMP-Routing-Konfigurationen

 

Abschluss von Modul 3

Sie haben Modul 3 abgeschlossen.

Weitere Informationen zum Bereitstellen von NSX finden Sie im NSX 6.4 Documentation Center unter der folgenden URL:

Fahren Sie mit einem der folgenden Module fort:

Liste der Module des Hands-on Lab:

Hands-on Lab-Dozenten:

  • Module 1 – 4: Joe Collon, Staff NSX Systems Engineer, USA

 

 

Hands-on Lab beenden

 

Klicken Sie auf die Schaltfläche END, wenn Sie Ihr Hands-on Lab beenden möchten.  

 

Modul 4 – Edge Services Gateway (60 Minuten)

Edge Services Gateway – Modulübersicht


Das NSX Edge Services Gateway (ESG) bietet Sicherheits- und Routing-Services am Netzwerk-Edge für eingehenden und ausgehenden Datenverkehr der virtualisierten Umgebung. Wie in vorherigen Modulen erläutert, verfügt ESG über eine Vielzahl von Optionen für eine skalierbare, stabile Weiterleitung des North-South-Traffic.

Der NSX Edge Distributed Logical Router (DLR) bietet kernelbasiertes, optimiertes East-West-Routing innerhalb der NSX-Umgebung. Durch verteiltes Routing können Workloads innerhalb der NSX-Umgebung effektiv und direkt miteinander kommunizieren, ohne dass Datenverkehr über eine herkömmliche Routing-Schnittstelle geleitet werden muss.

Neben seinen Routing-Funktionen bietet das NSX Edge Services Gateway außerdem viele erweiterte Gateway-Services. Zu diesen zählen DHCP, VPN, NAT, Lastausgleich sowie eine herkömmliche Layer 3-Firewall. Diese Funktionen müssen lediglich in der ESG-Konfiguration aktiviert werden.

In diesem Modul werden einige ESG-Services erläutert. Nach Abschluss dieses Moduls können Sie Folgendes:

  • Bereitstellen eines neuen Edge Services Gateways
  • Konfigurieren des Lastausgleichs auf dem Edge Services Gateway
  • Überprüfen der Lastausgleichskonfiguration
  • Konfigurieren der Layer 3-Firewall des Edge Services Gateways
  • Konfigurieren des DHCP-Relay
  • Konfigurieren von L2VPN

Eine vollständige Beschreibung dieser und weiterer Edge Services Gateway-Funktionen erhalten Sie über einen Link am Ende dieses Moduls.


Bereitstellen eines Edge Services Gateways für den Lastausgleich


Das NSX Edge Services Gateway verfügt über Lastausgleichsfunktionen. Die Implementierung des Lastausgleichs bietet viele Vorteile, darunter effiziente Ressourcenauslastung, Skalierbarkeit und Stabilität auf Anwendungsebene. Somit können Sie die Reaktionszeiten von Anwendungen beschleunigen, eine Anwendung über einen einzigen Server hinaus skalieren und mithilfe von HTTPS-Offloading Ihre Back-End-Server entlasten.

Mit dem Lastausgleichsservice lassen sich TCP- oder UDP-Lasten auf Layer 4 sowie HTTP- oder HTTPS-Lasten auf Layer 7 ausgleichen.

In diesem Abschnitt stellen Sie eine neue NSX Edge-Appliance bereit und konfigurieren diese als „einarmigen“ Lastausgleich.


 

Lab-Bereitschaft überprüfen

 

  • Der Lab-Status wird auf dem Desktop der Windows-VM in der Hauptkonsole angezeigt.

Mit der Validierungsprüfung wird gewährleistet, dass alle Lab-Komponenten ordnungsgemäß bereitgestellt wurden. Nach Abschluss der Prüfung wird der Status „Ready“ in Grün angezeigt. Es kann passieren, dass eine Lab-Bereitstellung aufgrund begrenzter Umgebungsressourcen fehlschlägt.

 

 

Mehr Platz auf dem Bildschirm durch Ausblenden des rechten Aufgabenfensters

 

Mit einem Klick auf die Stecknadelsymbole werden die Aufgabenfenster ausgeblendet. Dadurch steht mehr Platz auf dem Hauptbildschirm zur Verfügung. Um den Platz auf dem Bildschirm zu maximieren, können Sie das linke Fenster ausblenden.

 

 

Zum Bereich „Networking & Security“ im vSphere Web Client navigieren

 

  1. Klicken Sie auf das Haussymbol.
  2. Klicken Sie auf Networking & Security.

 

 

Neues Edge Services Gateway erstellen

 

Nun konfigurieren Sie den Lastausgleichsservice auf einem neuen Edge Services Gateway. Gehen Sie folgendermaßen vor, um ein neues Edge Services Gateway bereitzustellen:

  1. Klicken Sie auf NSX Edges.
  2. Klicken Sie auf das grüne Pluszeichen.

 

 

Name und Typ definieren

 

  1. Geben Sie in das Feld „Name“ OneArm-LoadBalancer ein.
  2. Klicken Sie auf Next.

 

 

Administratorkonto konfigurieren

 

  1. Geben Sie VMware1!VMware1! in das Feld „Password“ ein.
  2. Geben Sie VMware1!VMware1! in das Feld „Confirm password“ ein.
  3. Aktivieren Sie das Kontrollkästchen Enable SSH access.
  4. Klicken Sie auf Next.

Hinweis: Alle Kennwörter für NSX Edges sind komplexe Kennwörter mit mindestens 12 Zeichen.

 

 

Edge-Größe und VM-Platzierung definieren

 

Es gibt vier verschiedene Appliance-Größen für Edge Service Gateways. Die Spezifikationen lauten wie folgt:

  • Compact: 1 vCPU, 512 MB RAM
  • Large: 2 vCPUs, 1024 MB RAM
  • Quad Large: 4 vCPUs, 2 GB RAM
  • X-Large: 6 vCPUs, 8 GB RAM

Wählen Sie für das neue Edge Services Gateway die Größe „Compact“ aus. Beachten Sie, dass Edge Services Gateways nach der Bereitstellung auf jede andere Größe umkonfiguriert werden können. Fahren Sie wie folgt mit dem Erstellen des neuen Edge Services Gateways fort:

  1. Klicken Sie auf das grüne Pluszeichen. Daraufhin wird das Pop-up-Fenster Add NSX Edge Appliance geöffnet.

 

 

Cluster-/Datastore-Platzierung

 

  1. Wählen Sie aus der Dropdown-Liste „Cluster/Resource Pool“ RegionA01-MGMT01 aus.
  2. Wählen Sie aus der Dropdown-Liste „Datastore“ RegionA01-ISCSI01-COMP01 aus.
  3. Wählen Sie aus der Dropdown-Liste „Host“ esx-05a.corp.local aus.
  4. Klicken Sie auf OK.

 

 

Bereitstellung konfigurieren

 

  1. Klicken Sie auf Next.

 

 

Neue Netzwerkschnittstelle auf NSX Edge platzieren

 

Da es sich um einen einarmigen Lastausgleich handelt, benötigt dieser nur eine einzelne Netzwerkschnittstelle.

  1. Klicken Sie auf das grüne Pluszeichen.

 

 

Neue Netzwerkschnittstelle für NSX Edge konfigurieren

 

Als Nächstes konfigurieren Sie die erste Netzwerkschnittstelle für dieses neue NSX Edge.  

  1. Geben Sie in das Feld „Name“ WebNetwork ein.
  2. Wählen Sie neben „Type“ Uplink aus.
  3. Klicken Sie auf Select.

 

 

Netzwerk für die neue Edge-Schnittstelle auswählen

 

Die Schnittstelle des einarmigen Lastausgleichs befindet sich auf demselben Netzwerk wie die beiden Webserver, für die sie Lastausgleichsservices bereitstellt.

  1. Klicken Sie auf Logical Switch.
  2. Wählen Sie das Optionsfeld links neben Web_Tier_Logical_Switch (5006) aus.
  3. Klicken Sie auf OK.

 

 

Subnetze konfigurieren

 

  1. Klicken Sie auf das grüne Pluszeichen. So können Sie die IP-Adresse dieser Schnittstelle konfigurieren.

 

 

IP-Adresse und Subnetz konfigurieren

 

So fügen Sie eine neue IP-Adresse zur Schnittstelle hinzu:

  1. Geben Sie unter „Primary IP Address“ 172.16.10.10 ein.
  2. Geben Sie 24 in das Feld „Subnet Prefix Length“ ein.
  3. Klicken Sie auf OK.

 

 

Schnittstellenliste überprüfen

 

Stellen Sie sicher, dass IP-Adresse und Subnetzpräfixlänge der obigen Abbildung entsprechen.

  1. Klicken Sie auf Next.

 

 

Standard-Gateway konfigurieren

 

  1. Geben Sie in das Feld „Gateway IP“ 172.16.10.1 ein.
  2. Klicken Sie auf Next.

 

 

Firewall- und HA-Optionen konfigurieren

 

  1. Aktivieren Sie das Kontrollkästchen Configure Firewall default policy.
  2. Wählen Sie neben „Default Traffic Policy“ Accept aus.
  3. Klicken Sie auf Next.

 

 

Allgemeine Konfiguration prüfen und abschließen

 

  1. Klicken Sie auf Finish, um mit der Bereitstellung zu beginnen.

 

 

Bereitstellung überwachen

 

Die Bereitstellung von NSX Edge kann einen Moment dauern.

  1. Während der Bereitstellung von „OneArm-LoadBalancer“ wird im Abschnitt „NSX Edges“ 1 Installing angezeigt.
  2. Für den Status von „OneArm-LoadBalancer“ wird Busy angezeigt. Dies bedeutet, dass die Bereitstellung durchgeführt wird.
  3. Klicken Sie auf die Aktualisierungsschaltfläche im vSphere Web Client, um den Bereitstellungsstatus von „OneArm-LoadBalancer“ zu aktualisieren.

Sobald „OneArm-LoadBalancer“ den Status Deployed anzeigt, können Sie mit dem nächsten Schritt fortfahren.

 

Konfigurieren des Edge Services Gateways für den Lastausgleich


Nachdem das Edge Services Gateway bereitgestellt wurde, können Sie mit der Konfiguration der Lastausgleichsservices fortfahren.


 

Lastausgleichsservice konfigurieren

 

Die obige Abbildung zeigt die endgültige Topologie für den Lastausgleich, der vom neuen NSX Edge Services Gateway (ESG) OneArm-LoadBalancer bereitgestellt wird. Dieses ESG befindet sich nach der Konfiguration auf dem bereits vorhandenen „Web_Tier_Logical_Switch“. Gateway und logischer Switch sind über das bestehende ESG Perimeter-Gateway-01 miteinander verbunden.

Der Lastausgleichsservice dieses ESG empfängt eingehende Client-Verbindungen auf einem virtuellen Server mit der IP-Adresse 172.16.10.10. Sobald eine neue, eingehende Verbindungsanfrage empfangen wird, weist der Lastausgleich diese Anfrage einem internen Server aus einer Liste vordefinierter Poolmitglieder zu. In diesem Beispiel gibt es zwei Poolmitglieder: web-01a.corp.local (172.16.10.11) und web-02a.corp.local (172.16.10.12).

Dadurch stellt der Lastausgleich einen zentralen Endpunkt für eingehende Clients bereit und verteilt diese Verbindungen gleichzeitig über mehrere interne Webserver. Falls ein Webserver ausfällt oder nicht verfügbar ist, wird dies vom Lastausgleich erkannt und der Server aus der Liste der aktiven Poolmitglieder entfernt. Der Systemzustand von Poolmitgliedern wird regelmäßig von der Serviceüberwachung geprüft. Sobald der ausgefallene Server wieder betriebsbereit ist, wird er als aktives Poolmitglied aufgeführt.

 

 

Lastausgleichsfunktion auf „OneArm-Load Balancer“ konfigurieren

 

  1. Doppelklicken Sie auf OneArm-LoadBalancer.

 

 

Zum neuen NSX Edge navigieren

 

  1. Klicken Sie auf Manage.
  2. Klicken Sie auf Load Balancer.
  3. Klicken Sie auf Global Configuration.
  4. Klicken Sie auf Edit, um die globale Lastausgleichskonfiguration zu ändern.

 

 

Globale Lastausgleichskonfiguration ändern

 

So aktivieren Sie den Lastausgleichsservice:

  1. Aktivieren Sie das Kontrollkästchen Enable Load Balancer.
  2. Klicken Sie auf OK.

 

 

Neues Anwendungsprofil erstellen

 

Mit einem Anwendungsprofil wird das Verhalten einer typischen Art von Netzwerkverkehr definiert. Diese Profile werden auf einen virtuellen Server (VIP) angewendet, der den Datenverkehr anhand der im Anwendungsprofil festgelegten Werte behandelt.  

Durch die Nutzung von Profilen können Aufgaben für das Datenverkehrsmanagement weniger fehleranfällig und effizienter gestaltet werden.  

  1. Klicken Sie auf Application Profiles.
  2. Klicken Sie auf das grüne Pluszeichen. Daraufhin wird das Fenster „New Profile“ geöffnet.

 

 

Neues Anwendungsprofil für HTTPS konfigurieren

 

Konfigurieren Sie das neue Anwendungsprofil wie folgt:

  1. Geben Sie OneArmWeb-01 in das Feld „Name“ ein.
  2. Wählen Sie aus der Dropdown-Liste „Type“ HTTPS aus.
  3. Aktivieren Sie das Kontrollkästchen Enable SSL Passthrough. Mit dieser Konfiguration werden HTTPS-Verbindungen vom Lastausgleichsservice ungeprüft an den Endpunkt auf dem Poolserver weitergeleitet.
  4. Klicken Sie auf OK.

 

 

Benutzerdefinierte HTTPS-Serviceüberwachung definieren

 

Überwachungsfunktionen stellen sicher, dass die Poolmitglieder eines virtuellen Servers ordnungsgemäß funktionieren. Die standardmäßige HTTPS-Überwachungsfunktion führt eine einfache HTTP GET-Abfrage („GET /“) durch. Nachfolgend definieren Sie eine benutzerdefinierte Überwachungsfunktion, die eine Systemdiagnose für eine anwendungsspezifische URL durchführt. Damit wird geprüft, ob der Webserver auf Verbindungen antwortet und ob die Anwendung ordnungsgemäß funktioniert.

  1. Klicken Sie auf Service Monitoring.
  2. Klicken Sie auf das grüne Pluszeichen, um eine neue Überwachungsfunktion zu definieren.

 

 

Neue Überwachungsfunktion definieren

 

Geben Sie die folgenden Informationen ein, um die neue Überwachungsfunktion zu definieren:

  1. Geben Sie custom_https_monitor in das Feld „Name“ ein.
  2. Wählen Sie HTTPS aus der Dropdown-Liste „Type“ aus.
  3. Geben Sie /cgi-bin/app.py in das Feld „URL“ ein.
  4. Klicken Sie auf OK.

 

 

Neuen Pool erstellen

 

Ein Pool besteht aus einer Gruppe von Servern, die die Entität der Knoten darstellt, mit denen die Datenverkehrslast ausgeglichen wird. Als Nächstes fügen Sie die beiden Webserver „web-01a“ und „web-02a“ zu einem neuen Pool hinzu. So erstellen Sie einen neuen Pool:

  1. Klicken Sie auf Pools.
  2. Klicken Sie auf das grüne Pluszeichen. Daraufhin wird das Pop-up-Fenster „New Pool“ geöffnet.

 

 

Neuen Pool konfigurieren

 

Konfigurieren Sie die Einstellungen des neuen Pools wie folgt:

  1. Geben Sie in das Feld „Name“ Web-Tier-Pool-01 ein.
  2. Wählen Sie custom_https_monitor aus der Dropdown-Liste „Monitors“ aus.
  3. Klicken Sie auf das grüne Pluszeichen.

 

 

Mitglieder zum Pool hinzufügen

 

  1. Geben Sie in das Feld „Name“ web-01a ein.
  2. Geben Sie in das Feld „IP Address / VC Container“ 172.16.10.11 ein.
  3. Geben Sie in das Feld „Port“ 443 ein.
  4. Geben Sie in das Feld „Monitor Port“ 443 ein.
  5. Klicken Sie auf OK.

Wiederholen Sie diese Schritte, um ein zweites Poolmitglied mit den folgenden Informationen hinzuzufügen:

  • Name: web-02a
  • IP Address: 172.16.10.12
  • Port: 443
  • Monitor Port: 443

 

 

Pooleinstellungen speichern

 

  1. Klicken Sie auf OK.

 

 

Neuen virtuellen Server erstellen

 

Ein virtueller Server ist die Entität, die eingehende Verbindungen aus dem „Front-End“ einer Lastausgleichskonfiguration empfängt. Anwenderdatenverkehr wird an die IP-Adresse des virtuellen Servers geleitet und von dort an die Poolmitglieder auf dem „Back-End“ des Lastausgleichs umverteilt. Gehen Sie folgendermaßen vor, um einen neuen virtuellen Server auf diesem Edge Services Gateway zu konfigurieren und die Konfiguration des Lastausgleichs abzuschließen:

  1. Klicken Sie auf Virtual Servers.
  2. Klicken Sie auf das grüne Pluszeichen. Daraufhin wird das Pop-up-Fenster „New Virtual Server“ geöffnet.

 

 

Neuen virtuellen Server konfigurieren

 

Konfigurieren Sie den neuen virtuellen Server wie folgt:

  1. Geben Sie in das Feld „Name“ Web-Tier-VIP-01 ein.
  2. Geben Sie 172.16.10.10 in das Feld „IP Address“ ein.
  3. Wählen Sie für „Protocol“ HTTPS aus.
  4. Wählen Sie Web-Tier-Pool-01 aus.
  5. Klicken Sie auf OK.

 

Edge Services Gateway-Lastausgleich – Prüfen der Konfiguration


Nachdem die Konfiguration der Lastausgleichsservices abgeschlossen wurde, müssen Sie jetzt die Konfiguration überprüfen.


 

Zugriff auf virtuellen Server testen

 

  1. Öffnen Sie eine neue Registerkarte in Ihrem Browser.
  2. Erweitern Sie die Liste der Lesezeichen.
  3. Klicken Sie auf das Lesezeichen 1-Arm LB Customer DB.
  4. Klicken Sie auf Advanced.

 

 

SSL-Fehler ignorieren

 

  1. Klicken Sie auf Proceed to 172.16.10.10 (unsafe).

 

 

Zugriff auf virtuellen Server testen

 

Der Zugriff auf den einarmigen Lastausgleich sollte erfolgreich sein.

  1. Klicken Sie auf das Aktualisierungssymbol. Damit sehen Sie, wie Verbindungen vom Lastausgleich auf beide Poolmitglieder verteilt werden.

Hinweis: Aufgrund des Browser-Caching in Chrome können weitere Aktualisierungen den Anschein erwecken, als würden nicht beide Server genutzt.

 

 

Poolstatistiken anzeigen

 

Kehren Sie zur Browser-Registerkarte „vSphere Web Client“ zurück.

So zeigen Sie den Status der einzelnen Poolmitglieder an:

  1. Klicken Sie auf Pools.
  2. Klicken Sie auf Show Pool Statistics.
  3. Klicken Sie auf pool-1. Hier wird der aktuelle Status der einzelnen Mitglieder angezeigt.
  4. Schließen Sie das Fenster, indem Sie auf das X klicken.

 

 

Verbesserte Reaktion der Überwachung (Systemdiagnose)

 

Für eine leichtere Fehlerbehebung können mit den „show ...pool“-Befehlen des NSX-Lastausgleichs detaillierte Informationen zu Fehlerursachen ausgefallener Poolmitglieder angezeigt werden. Im nächsten Schritt verursachen Sie zwei verschiedene Ausfälle und prüfen die Reaktion mithilfe der show-Befehle auf dem Edge Gateway OneArm-LoadBalancer-0

  1. Geben Sie loadbalancer in das Suchfeld ein. Das Suchfeld befindet sich in der oberen rechten Ecke des vSphere Web Client.
  2. Klicken Sie auf OneArm-LoadBalancer-0.

 

 

Lastausgleichskonsole öffnen

 

  1. Klicken Sie auf Summary.
  2. Klicken Sie auf die VM-Konsole.

 

 

Bei „OneArm-LoadBalancer-0“ anmelden

 

  1. Melden Sie sich als admin an.
  2. Geben Sie VMware1!VMware1! in das Feld „Password“ ein.

 

 

Poolstatus vor dem Ausfall ermitteln

 

  1. Geben Sie show service loadbalancer pool ein.
show service loadbalancer pool

Hinweis: Der Status der Poolmitglieder „web-01a“ und „web-02a“ lautet „UP“.

 

 

PuTTY starten

 

  1. Klicken Sie in der Taskleiste auf PuTTY.

 

 

SSH für „web-01a.corp.local“

 

  1. Scrollen Sie nach unten zu web-01a.corp.local.
  2. Wählen Sie web-01a.corp.local aus.
  3. Klicken Sie auf Load.
  4. Klicken Sie auf Open.

 

 

„NGINX“-Service anhalten

 

Als Nächstes beenden Sie HTTPS, um die erste Ausfallbedingung zu simulieren.

  1. Geben Sie systemctl stop nginx ein.
systemctl stop nginx

 

 

Lastausgleichskonsole

 

  1. Geben Sie show service loadbalancer pool ein.
show service loadbalancer pool

Da der Service ausgefallen ist, wird unter den Fehlerinformationen angegeben, dass der „Health Monitor“-Prozess des Lastausgleichs keine SSL-Sitzung einrichten konnte.

 

 

„NGINX“-Service starten

 

Wechseln Sie zurück zur PuTTY-SSH-Sitzung für web-01a.

1. Geben Sie systemctl start nginx ein.

systemctl start nginx

 

 

„web-01a“ herunterfahren

 

Kehren Sie zur Browser-Registerkarte „vSphere Web Client“ zurück.

  1. Geben Sie web-01a in das Suchfeld ein. Das Suchfeld befindet sich in der oberen rechten Ecke des vSphere Web Client.
  2. Klicken Sie auf web-01a.

 

 

„web-01a“ ausschalten

 

  1. Klicken Sie auf Actions.
  2. Klicken Sie auf Power.
  3. Klicken Sie auf Power Off.
  4. Klicken Sie zur Bestätigung auf Yes.

 

 

Poolstatus prüfen

 

  1. Geben Sie show service loadbalancer pool ein.
show service loadbalancer pool

Da die VM ausgefallen ist, wird in den Fehlerinformationen angegeben, dass der Client – anders als bei der L7(SSL)-Verbindung im vorangegangenen Schritt – keine L4-Verbindung herstellen konnte.

 

 

„web-01a“ einschalten

 

Kehren Sie zur Browser-Registerkarte „vSphere Web Client“ zurück.

  1. Klicken Sie auf Actions.
  2. Klicken Sie auf Power.
  3. Klicken Sie auf Power On.

 

 

Fazit

Im Rahmen dieses Lab haben Sie ein neues Edge Services Gateway bereitgestellt sowie konfiguriert und darüber hinaus Lastausgleichsservices für die Anwendung 1-Arm LB Customer DB aktiviert.

Damit ist die Lektion zum Edge Services Gateway-Lastausgleich abgeschlossen. Als Nächstes wird die Edge Services Gateway-Firewall näher erläutert.

 

Edge Services Gateway-Firewall


Die NSX Edge-Firewall überwacht den North-South-Traffic und stellt Perimeter-Sicherheitsfunktionen bereit. Dadurch unterscheidet sie sich von der verteilten NSX-Firewall, die Richtlinien auf die virtuelle NIC jeder einzelnen VM anwendet.

Die Edge-Firewall hilft beim Erfüllen wichtiger Anforderungen an die Perimetersicherheit. Dazu gehört das Erstellen von DMZs auf Basis von IP-/VLAN-Konstrukten, Mandantenisolierung in mandantenfähigen virtuellen Rechenzentren sowie das Bereitstellen herkömmlicher, gerouteter Firewall-Regeln für physische Geräte, bei denen die eine verteilte Firewall nicht eingesetzt werden kann.


 

Mit NSX Edge-Firewall-Regeln arbeiten

Sowohl das Edge Services Gateway als auch der logische Router besitzen eine Registerkarte für die Firewall-Konfiguration. Allerdings wird die Richtlinie an unterschiedlichen Stellen angewendet. Beim Anwenden von Firewall-Regeln auf einen logischen Router werden diese Richtlinien auf die Steuerungs-VM des logischen Routers angewendet und stellen keine Komponente der Datenebene dar. Zum Schutz des Datenverkehrs der Datenebene können logische (verteilte) Firewall-Regeln für den East-West-Schutz auf Ebene der virtuellen NIC genutzt werden. Alternativ können Regeln auf Ebene des NSX Edge Services Gateways für North-South-Schutz bzw. das Routing zwischen physischen VLAN-gestützten Portgruppen angewendet werden.

Wenn Regeln in der Benutzeroberfläche der NSX-Firewall erstellt werden, die auf ein NSX Edge Gateway anwendbar sind, werden sie schreibgeschützt auf dem Edge angezeigt. Wenn Regeln an mehreren Orten existieren, werden sie in der folgenden Reihenfolge angezeigt und durchgesetzt:

  1. Benutzerdefinierte Regeln von der Firewall-Benutzeroberfläche (schreibgeschützt)
  2. Automatisch konfigurierte Regeln (automatisch erstellte Regeln im Hinblick auf Steuerungsdatenverkehr für Edge-Services)
  3. Benutzerdefinierte Regeln in der NSX Edge-Firewall-Benutzeroberfläche
  4. Standardregel

 

 

„Networking & Security“ öffnen

 

  1. Klicken Sie auf das Haussymbol.
  2. Klicken Sie auf Networking & Security.

 

 

NSX Edge öffnen

 

  1. Klicken Sie auf NSX Edges.
  2. Doppelklicken Sie auf Perimeter-Gateway-01.

 

 

Registerkarte „Manage“ öffnen

 

  1. Klicken Sie auf Manage.
  2. Klicken Sie auf Firewall.
  3. Klicken Sie auf Default Rule.
  4. Klicken Sie auf das Stiftsymbol unter der Spalte „Action“.
  5. Wählen Sie Deny im Feld „Action“ aus.

Hinweis: NSX bietet die folgenden drei Aktionen für Firewall-Regeln:

  • Accept: Der einer Regel entsprechende Datenverkehr wird normal weitergeleitet.
  • Deny: Der einer Regel entsprechende Datenverkehr wird verworfen und es wird keine Benachrichtigung an die Datenverkehrsquelle gesendet.
  • Reject: Der einer Regel entsprechende Datenverkehr wird ähnlich wie bei „Deny“ verworfen, jedoch wird eine Nachricht an die Quell-IP-Adresse des ursprünglichen Pakets gesendet, dass das ICMP nicht erreichbar ist.

 

 

Änderungen veröffentlichen

 

Sie nehmen keine dauerhaften Änderungen an den Firewall-Einstellungen des Edge Services Gateways vor.

  1. Klicken Sie auf Revert, um die Änderungen zurückzusetzen.

 

 

Regel zur Edge Services Gateway-Firewall hinzufügen

 

Da Sie nun mit dem Bearbeiten einer bestehenden Edge Services Gateway-Firewall-Regel vertraut sind, fügen Sie als Nächstes eine neue Edge-Firewall-Regel hinzu, die den Control Center-Zugriff auf die „Customer DB“-Anwendung blockiert.

  1. Klicken Sie auf das grüne Pluszeichen, um eine neue Firewall-Regel hinzuzufügen.
  2. Bewegen Sie den Mauszeiger in die obere rechte Ecke der Spalte „Name“ und klicken Sie auf das Stiftsymbol.
  3. Geben Sie Main Console FW Rule unter „Rule Name“ ein.
  4. Klicken Sie auf OK.

 

 

Quelle angeben

 

Bewegen Sie den Mauszeiger in die obere rechte Ecke der Spalte Source und klicken Sie auf das Stiftsymbol.

  1. Klicken Sie auf das Dropdown-Menü Object Type und wählen Sie IP Sets aus.
  2. Klicken Sie auf den Hyperlink New IP Set...
  3. Geben Sie Main Console in das Feld „Name“ ein.
  4. Geben Sie 192.168.110.10 in das Feld „IP Addresses“ ein.
  5. Klicken Sie auf OK.

 

 

Quelle angeben

 

  1. Wählen Sie IP Sets in der Liste „Object Type“ aus.
  2. Wählen Sie Main Console in der Liste „Available Objects“ aus.
  3. Klicken Sie auf den Rechtspfeil. Dadurch wird das Objekt in die Liste „Selected Objects“ verschoben.
  4. Prüfen Sie, ob „Main Console“ unter „Selected Objects“ aufgeführt wird, und klicken Sie auf OK.

 

 

Ziel angeben

 

Bewegen Sie den Mauszeiger in die obere rechte Ecke der Spalte Destination und klicken Sie auf das Stiftsymbol.

  1. Wählen Sie Logical Switch in der Liste „Object Type“ aus.
  2. Wählen Sie Web_Tier_Logical_Switch in der Liste „Available Objects“ aus.
  3. Klicken Sie auf den Rechtspfeil. Dadurch wird das Objekt in die Liste Selected Objects verschoben.
  4. Prüfen Sie, ob „Web_Tier_Logical_Switch“ unter „Selected Objects“ aufgeführt wird, und klicken Sie auf OK.

 

 

Aktion konfigurieren

 

  1. Klicken Sie auf das Stiftsymbol unter der Spalte „Action“.
  2. Wählen Sie Reject im Feld „Action“ aus.
  3. Klicken Sie auf OK.

Hinweis: Es wurde „Reject“ statt „Deny“ ausgewählt, um den Ausfall des Webservers in den nachfolgenden Schritten zu beschleunigen. Wird „Deny“ ausgewählt, wird der Datenfluss verworfen, was schließlich zu einer Zeitüberschreitung führt. Da oben „Reject“ ausgewählt wurde, wird beim Verbindungsversuch eine ICMP-Nachricht an die Hauptkonsole gesendet, die das Betriebssystem sofort über die fehlgeschlagene Verbindung informiert. Die Verwendung von „Deny“ wird als allgemeine Best Practice für die Sicherheit empfohlen.

 

 

Änderungen veröffentlichen

 

  1. Klicken Sie auf Publish Changes, um die Konfiguration auf „Perimeter-Gateway-01“ (NSX Edge) zu aktualisieren.

 

 

Neue Firewall-Regel testen

 

Als Nächstes testen Sie die von Ihnen konfigurierte Firewall-Regel, die den Control Center-Zugriff auf den logischen Switch der Webschicht verhindert:

  1. Öffnen Sie eine neue Registerkarte in Ihrem Browser.
  2. Klicken Sie auf das Lesezeichen Customer DB App.

Vergewissern Sie sich, dass Sie nicht über die Hauptkonsole auf Customer DB App zugreifen können. Im Browser sollte eine Seite angezeigt werden, die angibt, dass die Website nicht erreichbar ist. Als Nächstes bearbeiten Sie die Firewall-Regel so, dass Sie über die Hauptkonsole auf die „Customer DB“-Anwendung zugreifen können.

 

 

„Main Console FW Rule“ in „Accept“ ändern

 

Kehren Sie zur Browser-Registerkarte „vSphere Web Client“ zurück.

  1. Klicken Sie auf das Stiftsymbol in der Spalte „Action“ der Regel Main Console FW Rule.
  2. Wählen Sie Accept im Feld „Action“ aus.
  3. Klicken Sie auf OK.

 

 

 

Änderungen veröffentlichen

 

  1. Klicken Sie auf Publish Changes, um die Konfiguration auf „Perimeter-Gateway-01“ (NSX Edge) zu aktualisieren.

 

 

Zugriff auf „Customer DB“-Anwendung prüfen

 

Kehren Sie zur Browser-Registerkarte „Customer DB App“ zurück.

  1. Klicken Sie auf das Aktualisierungssymbol.

Da Main Console FW Rule in „Accept“ geändert wurde, können Sie nun über die Hauptkonsole auf Customer DB App zugreifen.

 

 

„Main Console FW Rule“ löschen

 

  1. Klicken Sie auf Main Console FW Rule.
  2. Klicken Sie auf das rote X, um die ausgewählte Firewall-Regel zu löschen.
  3. Klicken Sie auf OK, um den Löschvorgang zu bestätigen.

 

 

Änderungen veröffentlichen

 

  1. Klicken Sie auf Publish Changes, um die Konfiguration auf „Perimeter-Gateway-01“ (NSX Edge) zu aktualisieren.

 

 

Fazit

In diesem Hands-on Lab haben Sie gelernt, wie Sie eine bestehende Edge Services Gateway-Firewall-Regel bearbeiten und eine neue Edge Services Gateway-Firewall-Regel konfigurieren, die den externen Zugriff auf Customer DB App blockiert.

Damit ist die Lektion zur Edge Services Gateway-Firewall abgeschlossen. Als Nächstes wird das Management von DHCP-Services mithilfe des Edge Services Gateways näher erläutert.

 

DHCP-Relay


In einem Netzwerk, in dem es nur einzelne Netzwerksegmente gibt, kommunizieren DHCP-Clients direkt mit ihrem DHCP-Server. DHCP-Server können außerdem IP-Adressen für mehrere Netzwerke bereitstellen – auch für Netzwerke, die sich nicht im selben Segment wie der Server befinden. Aufgrund der Art und Weise der Vergabe von IP-Adressen, die sich außerhalb des Bereichs seines lokalen Netzwerks befinden, kann der DHCP-Server nicht direkt mit anfragenden Clients kommunizieren.

In einem solchen Fall wird ein DCHP-Relay-Agent verwendet, um die von den Clients gesendete DHCP-Anfrage weiterzugeben. Dies erfolgt durch Umleitung der Anfrage an einen designierten DHCP-Server als Unicast-Paket. Der vom DHCP-Server ausgewählte DHCP-Umfang basiert auf dem Adressbereich des Unicast-Ursprungs. Das DHCP-Antwortpaket wird an die Relay-Adresse übergeben, die dann über das ursprüngliche Netzwerk zurück an den Client übertragen wird.

In diesem Lab wird Folgendes behandelt:

  • Erstellen eines neuen Netzwerksegments in NSX
  • Aktivieren des DHCP-Relay-Agent im neuen Netzwerksegment
  • Verwenden eines vordefinierten DHCP-Umfangs auf einem DHCP-Server, der DHCP-Relay erfordert
  • Netzwerkstart (PXE) einer leeren VM mithilfe der DHCP-Umfangsoptionen

Im Rahmen dieses Lab wurden folgende Elemente vorkonfiguriert:

  • Windows Server-basierter DHCP-Server mit entsprechendem DHCP-Umfang und festgelegten Umfangsoptionen
  • TFTP-Server für die PXE-Startdateien. Dieser Server wurde installiert, konfiguriert und mit OS-Dateien ausgestattet.

 

Lab-Topologie

 

In diesem Diagramm wird die Topologie abgebildet, die im Rahmen dieses Hands-on Lab-Moduls erstellt und verwendet wird.

 

 

Über vSphere Web Client auf NSX zugreifen

 

  1. Klicken Sie auf das Haussymbol.
  2. Klicken Sie auf Networking & Security.

 

 

Neuen logischen Switch erstellen

 

Sie müssen zunächst einen neuen logischen Switch erstellen, der das neue 172.16.50.0/24-Netzwerk ausführt.

  1. Klicken Sie auf Logical Switches.
  2. Klicken Sie auf das grüne Pluszeichen, um einen neuen logischen Switch zu erstellen.

 

 

Logischen Switch mit Perimeter-Gateway verbinden

 

Als Nächstes verbinden Sie den logischen Switch mit einer Schnittstelle auf dem Perimeter-Gateway. Diese Schnittstelle fungiert als Standard-Gateway für das 172.16.50.0/24-Netzwerk und besitzt die Adresse 172.16.50.1.

  1. Klicken Sie auf NSX Edges.
  2. Doppelklicken Sie auf Perimeter-Gateway-01.

 

 

DHCP-Relay konfigurieren

 

Bleiben Sie im Fenster „Perimeter-Gateway“ und nehmen Sie als Nächstes die globale Konfiguration des DHCP-Relay vor.

  1. Klicken Sie auf Manage.
  2. Klicken Sie auf DHCP.
  3. Klicken Sie auf Relay.
  4. Klicken Sie auf Edit.

 

 

Leere VM für PXE-Start erstellen

 

Als Nächstes erstellen Sie eine leere VM, die mittels PXE von dem als Relay angegebenen DHCP-Server gestartet wird.

  1. Klicken Sie auf das Haussymbol.
  2. Klicken Sie auf Hosts and Clusters.

 

 

Auf die neu erstellte VM zugreifen

 

Als Nächstes öffnen Sie eine Konsole für diese VM und beobachten den Startvorgang über das PXE-Image. Die VM erhält diese Informationen über den von Ihnen zuvor konfigurierten Remote-DHCP-Server.

  1. Klicken Sie auf PXE VM.
  2. Klicken Sie auf Summary.
  3. Klicken Sie auf die VM-Konsole.

 

 

DHCP-Lease prüfen

 

Während Sie warten, bis die VM startet, können Sie die verwendete Adresse in den DHCP-Leases prüfen.

  1. Navigieren Sie zum Desktop der Hauptkonsole und doppelklicken Sie auf das DHCP-Symbol.

 

 

Auf gestartete VM zugreifen

 

  1. Klicken Sie auf die Browser-Registerkarte PXE VM.

 

 

Adresse und Konnektivität überprüfen

 

Das Widget in der oberen rechten Ecke der VM zeigt neben Statistiken unter anderem auch die IP-Adresse an. Diese sollte mit der vorher in DHCP angezeigten IP-Adresse übereinstimmen.

 

 

Fazit

In diesem Abschnitt haben Sie ein neues Netzwerksegment erstellt und anschließend die DHCP-Anfragen aus diesem Netzwerk an einen externen DHCP-Server weitergeleitet. Dadurch könnten Sie auf zusätzliche Startoptionen für diesen externen DHCP-Server zugreifen und ein Linux-Betriebssystem mittels PXE starten.

Als Nächstes werden Edge Services Gateway-L2VPN-Services näher erläutert.

 

Konfigurieren von L2VPN


In diesem Abschnitt verwenden Sie die L2VPN-Funktionen des NSX Edge Gateways, um eine L2-Grenze zwischen zwei getrennten vSphere-Clustern zu erweitern. Zur Demonstration dieser Funktion werden ein NSX Edge-L2VPN-Server auf dem „RegionA01-MGMT01“-Cluster und ein NSX Edge-L2VPN-Client auf dem „RegionA01-COMP01“-Cluster bereitgestellt. Anschließend wird der Tunnelstatus getestet, um die Konfiguration zu prüfen.


 

Google Chrome öffnen und zum vSphere Web Client navigieren

 

  1. Öffnen Sie den Google Chrome-Webbrowser auf dem Desktop, falls dieser noch nicht geöffnet ist.

 

 

Zum Bereich „Networking & Security“ des vSphere Web Client navigieren

 

  1. Klicken Sie auf das Haussymbol.
  2. Klicken Sie auf Networking & Security.

 

 

NSX Edge Gateway für den L2VPN-Server erstellen

 

Um den L2VPN-Serverservice zu erstellen, müssen Sie zunächst ein NSX Edge Gateway bereitstellen, auf dem der Service ausgeführt werden kann.  

  1. Klicken Sie auf NSX Edges.
  2. Klicken Sie auf das grüne Pluszeichen.

 

 

Neues NSX Edge Gateway konfigurieren: L2VPN-Server

 

  1. Geben Sie L2VPN-Server in das Feld Name ein.
  2. Klicken Sie auf Next.

 

 

Einstellungen für das neue NSX Edge Gateway konfigurieren: L2VPN-Server

 

  1. Geben Sie VMware1!VMware1! in das Feld „Password“ ein.
  2. Geben Sie VMware1!VMware1! in das Feld „Confirm password“ ein.
  3. Aktivieren Sie das Kontrollkästchen Enable SSH access.
  4. Klicken Sie auf Next.

 

 

NSX Edge des L2VPN-Servers für L2VPN-Verbindungen vorbereiten

Vor dem Konfigurieren der neuen NSX Edge-Bereitstellung für L2VPN-Verbindungen müssen Sie die folgenden Schritte ausführen:

  1. Hinzufügen einer Trunk-Schnittstelle zum Edge Gateway des L2VPN-Servers
  2. Hinzufügen einer Subschnittstelle zum Edge Gateway des L2VPN-Servers
  3. Konfigurieren des dynamischen Routings (OSPF) auf dem Edge Gateway des L2VPN-Servers

 

 

Router-ID für dieses NSX Edge festlegen

 

Als Nächstes konfigurieren Sie dynamisches Routing auf diesem Edge Gateway.

  1. Klicken Sie auf Routing.
  2. Klicken Sie auf Global Configuration.
  3. Klicken Sie auf Edit, um den Abschnitt „Dynamic Routing Configuration“ zu bearbeiten.

 

 

OSPF für das NSX Edge des L2VPN-Servers konfigurieren

 

  1. Klicken Sie auf OSPF.
  2. Klicken Sie unter „Area to Interface Mapping“ auf das grüne Pluszeichen.

 

 

OSPF-Routenumverteilung aktivieren

 

  1. Klicken Sie auf Route Redistribution.
  2. Klicken Sie auf Edit, um den Abschnitt „Route Redistribution Status“ zu bearbeiten.
  3. Aktivieren Sie das Kontrollkästchen OSPF.
  4. Klicken Sie auf OK.

 

 

L2VPN-Service auf dem NSX Edge des L2VPN-Servers konfigurieren

Die Adresse 172.16.10.1 gehört zum Edge Gateway des L2VPN-Servers und Routen werden dynamisch über OSPF verteilt. Als Nächstes konfigurieren Sie den L2VPN-Service auf diesem Edge Gateway so, dass NSX Edge als „Server“ in der L2VPN-Verbindung fungiert.

 

 

Bereitstellen des NSX Edge Gateways als L2VPN-Client

Nach der serverseitigen L2VPN-Konfiguration können Sie nun mit der Bereitstellung eines neuen NSX Edge Gateways als L2VPN-Client fortfahren. Vor der Bereitstellung des NSX Edge Gateways als L2VPN-Client müssen Sie die verteilten Uplink- und Trunk-Portgruppen auf dem verteilten virtuellen Switch konfigurieren.

 

 

NSX Edge Gateway als L2VPN-Client konfigurieren

 

  1. Doppelklicken Sie auf L2VPN-Client.

 

Natives Bridging


NSX bietet softwarebasiertes L2 Bridging im Kernel, damit Unternehmen herkömmliche Workloads auf Legacy-VLANs nahtlos mit VXLAN-basierten virtualisierten Netzwerken verbinden können. L2 Bridging wird häufig in Brownfield-Umgebungen verwendet, wenn logische Netzwerke eingeführt werden sollen oder physische Systeme L2-Verbindungen mit virtuellen Maschinen auf einem logischen NSX-Switch benötigen.

In diesem Modul wird die Konfiguration einer L2 Bridging-Instanz zwischen einem herkömmlichen VLAN und einem logischen NSX-Netzwerk-Switch behandelt.


 

Spezielle Anweisungen für CLI-Befehle

 

Bei vielen Modulen müssen Sie Command Line Interface(CLI)-Befehle eingeben. Zum Senden von CLI-Befehlen an das Hands-on Lab stehen zwei Methoden zur Verfügung.

Bei der ersten Methode senden Sie einen CLI-Befehl an die Lab-Konsole:

  1. Markieren Sie den CLI-Befehl im Handbuch und kopieren Sie ihn mit STRG+C in die Zwischenablage.
  2. Klicken Sie im Konsolenmenü auf „SEND TEXT“.
  3. Drücken Sie STRG+V, um den Befehl aus der Zwischenablage in das Fenster einzufügen.
  4. Klicken Sie auf die Schaltfläche „SEND“.

Zweite Methode: Eine Textdatei (README.txt) wurde auf dem Desktop der Umgebung abgelegt. Mit dieser können Sie komplexe Befehle oder Kennwörter ganz einfach kopieren und in die jeweiligen Dienstprogramme (CMD, PuTTY, Konsole etc.) einfügen. Bestimmte Zeichen sind nicht auf allen Tastaturen weltweit vorhanden. Diese Textdatei ist auch für Tastaturen vorgesehen, die solche Zeichen nicht enthalten.

Die Textdatei heißt „README.txt“ und befindet sich auf dem Desktop.  

 

 

Auf vSphere Web Client zugreifen

 

  • Starten Sie den vSphere Web Client über das Chrome-Symbol auf dem Desktop.

 

 

Erstkonfiguration überprüfen

 

Überprüfen Sie, ob die Erstkonfiguration der obigen Abbildung entspricht. Die Lab-Umgebung umfasst auf dem Cluster „Management & Edge“ die Portgruppe Bridged-Net-RegionA01-vDS-MGMT. Die Webserver-VMs web-01a und web-02a sind mit dem logischen Switch „Web-Tier-01“ verbunden. Der logische Switch „Web-Tier-01“ ist von „Bridged-Net“ isoliert.

 

 

„web-01a“ auf den Cluster „RegionA01-MGMT01“ migrieren

 

  1. Klicken Sie auf das Haussymbol.
  2. Klicken Sie auf VMs and Templates.

 

 

Verbundene VMs anzeigen

 

  1. Klicken Sie auf das Haussymbol.
  2. Klicken Sie auf Networking.

 

 

„Web_Tier_Logical_Switch“ auf den verteilten logischen Router migrieren

 

  1. Klicken Sie auf das Haussymbol.
  2. Klicken Sie auf Networking & Security.

 

 

NSX L2 Bridging konfigurieren

 

Damit „web-01a.corp.local“ mit dem restlichen Netzwerk kommunizieren kann, muss NSX L2 Bridging zwischen VLAN 101 und dem logischen Switch „Web-Tier-01“ aktiviert werden. Diese Konfiguration unterstützt sowohl eine L2-Bridge als auch eine verteilte logische Router-Schnittstelle auf demselben logischen „Web-Tier“-Switch.

 

 

L2 Bridging überprüfen

NSX L2 Bridging wurde nun konfiguriert. Als Nächstes überprüfen Sie die L2-Konnektivität zwischen der VM web-01a, die mit VLAN 101 verbunden ist, und der VM web-02a, die mit Web_Tier_Logical_Switch verbunden ist.

 

 

L2 Bridging-Modul bereinigen

Wenn Sie mit anderen Modulen dieses Hands-on Lab fortfahren möchten, müssen Sie die folgenden Schritte ausführen, um L2 Bridging zu deaktivieren. Die in diesem speziellen Szenario verwendete Beispielkonfiguration könnte zu Konflikten mit anderen Abschnitten, z.B. L2VPN, führen.

 

 

„web-01a“ zurück auf den Cluster „RegionA01-COMP01“ migrieren

 

  1. Klicken Sie auf das Haussymbol.
  2. Klicken Sie auf VMs and Templates.

 

Modul 4 – Fazit


In diesem Modul wurden die erweiterten Funktionen des NSX Edge Services Gateways behandelt:

  1. Bereitstellen eines neuen Edge Services Gateways (ESG) und Konfigurieren als einarmiger Lastausgleich
  2. Ändern und Erstellen von Firewall-Regeln auf dem vorhandenen ESG
  3. Konfigurieren des DCHP-Relay über das ESG
  4. Konfigurieren von L2VPN über das ESG

 

Abschluss von Modul 4

Sie haben Modul 4 abgeschlossen.

Weitere Informationen zum Bereitstellen von NSX finden Sie im NSX 6.4 Documentation Center unter der folgenden URL:

Fahren Sie mit einem der folgenden Module fort:

Liste der Module des Hands-on Lab:

Hands-on Lab-Dozenten:

  • Module 1 – 4: Joe Collon, Staff NSX Systems Engineer, USA

 

 

Hands-on Lab beenden

 

Klicken Sie auf die Schaltfläche END, wenn Sie Ihr Hands-on Lab beenden möchten.  

 

Schlussbemerkung

Vielen Dank für Ihre Teilnahme an den VMware Hands-on Labs. Besuchen Sie http://hol.vmware.com/ um an weiteren Online-Labs teilzunehmen.

Lab SKU: HOL-1903-01-NET

Version: 20181005-132016