NSX-V-Funktionen und Konfigurationen, die migriert werden können, werden nachfolgend aufgeführt.

Plattformunterstützung

Weitere Informationen finden Sie in der VMware-Interoperabilitätsmatrix für unterstützte Versionen von ESXi und VMware vCenter.

NSX-V-Konfiguration

Unterstützt

Details

NSX-V mit vSAN oder iSCSI auf vSphere Distributed Switch

Ja

Bereits vorhandene NSX-Konfiguration

Nein

Sie müssen eine neue NSX-Umgebung bereitstellen.

Wenn der Migrationsmodus nicht für eine benutzerdefinierte Topologie gilt, werden während des Schritts Konfiguration importieren alle NSX Edge-Knotenschnittstellen in der NSX-Umgebung heruntergefahren. Wenn die NSX-Umgebung verwendet wird, wird der Datenverkehr dadurch unterbrochen.

Cross-vCenter NSX

Ja

Wird nur unterstützt, wenn Sie den Modus NSX for vSphere migrieren und Benutzerdefinierte Topologie auswählen.

NSX-V mit einer Cloud Management-Plattform, einer Integrated Stack- oder PaaS-Lösung.

Ja

Die Migration von NSX-V mit Aria Automation wird unterstützt.

Wenden Sie sich an Ihren VMware-Vertreter, bevor Sie mit der Migration fortfahren. Skripts und Integrationen werden bei der Migration der integrierten Umgebungen unter Umständen abgebrochen:

Beispiel:
  • NSX-V und vCloud Director

  • NSX-V mit Integrated Stack-Lösung

  • NSX-V mit PaaS-Lösung wie Pivotal Cloud Foundry, RedHat OpenShift

  • NSX-V mit Aria Operations-Workflows

vSphere- und ESXi-Funktionen

NSX-V-Konfiguration

Unterstützt

Details

ESXi-Host befindet sich bereits im Wartungsmodus (keine VMs)

Ja

Network I/O Control (NIOC) Version 3

Ja

Network I/O Control (NIOC) Version 2

Nein

Network I/O Control (NIOC) mit vNIC mit Reservierung

Nein

vSphere Standard-Switch

Nein

VMs und VMkernel-Schnittstellen auf VSS werden nicht migriert. NSX-V-Funktionen, die auf den VSS angewendet werden, können nicht migriert werden.

vSphere Distributed Switch

Ja

ESXi statusfrei

Nein

Hostprofile

Nein

ESXi-Sperrmodus

Nein

Wird in NSX nicht unterstützt.

Wartungsmodusaufgabe des ESXi-Hosts ausstehend.

Nein

Getrennter ESXi-Host im vCenter-Cluster

Nein

vSphere FT

Nein

vSphere DRS vollständig automatisiert

Ja

Unterstützt ab vSphere 7.0

vSphere High Availability

Ja

Zugriffskontrollliste für Datenverkehrsfilterung

Nein

vSphere-Systemdiagnose

Nein

SRIOV

Nein

vmknic an physische Netzwerkkarte anheften

Nein

Privates VLAN

Nein

Flüchtige dvPortGroup

Nein

DirectPath IO

Nein

L2-Sicherheit

Nein

Switch auf virtuellem Kabel erlernen

Nein

Hardware-Gateway (Tunnel-Endpoint-Integration mit physischer Switching-Hardware)

Nein

SNMP

Nein

Getrennte vNIC in VM

Nein

Aufgrund der ESX 6.5-Einschränkung können veraltete Einträge in DVFilter für getrennte VMs vorhanden sein. Starten Sie zur Problemumgehung die VM neu.

Andere VXLAN-Portnummer als 4789

Nein

Multicast-Filtermodus

Nein

Hosts mit mehreren VTEPs

Ja

Systemkonfiguration der NSX Manager-Appliance

NSX-V-Konfiguration

Unterstützt

Details

NTP-Server/Zeiteinstellung

Ja

Syslog-Serverkonfiguration

Ja

Konfiguration sichern

Ja

Ändern Sie bei Bedarf die NSX-V Passphrase entsprechend den NSX Anforderungen. Sie muss mindestens 8 Zeichen lang sein und Folgendes enthalten:

  • Mindestens ein Kleinbuchstabe

  • Mindestens ein Großbuchstabe

  • Mindestens ein numerisches Zeichen

  • mindestens ein Sonderzeichen

FIPS

Nein

FIPS ein/aus wird von NSX nicht unterstützt.

Gebietsschema

Nein

NSX unterstützt nur das englische Gebietsschema

Appliance-Zertifikat

Nein

Rollenbasierte Zugriffssteuerung

NSX-V-Konfiguration

Unterstützt

Details

Lokale Benutzer

Nein

NSX-Rollen, die einem vCenter-Benutzer, der über LDAP hinzugefügt wurde, zugewiesen werden

Ja

VMware Identity Manager muss installiert und konfiguriert sein, um Benutzerrollen für LDAP-Benutzer zu migrieren.

Einer vCenter-Gruppe zugewiesene NSX-Rollen

Nein

Zertifikate

NSX-V-Konfiguration

Unterstützt

Details

Zertifikate (Server, von Zertifizierungsstelle signiert)

Ja

Dies gilt nur für Zertifikate, die nur über Truststore-APIs hinzugefügt werden.

Zertifikatsänderungen während der Migration

Ja

Zertifikatsänderungen werden unterstützt, wenn die Migration für alle Migrationsmodi außer der Migration des vSphere-Netzwerks angehalten wird. Wird nicht unterstützt, wenn Hosts und Arbeitslasten migriert werden.

Betrieb

Details

Unterstützt

Anmerkungen

Discovery-Protokoll CDP

Siehe Hinweise.

Ja, wenn Sie zu VDS 7.0 migrieren. Nein, wenn Sie zu N-VDS migrieren.

Discovery-Protokoll LLDP

Ja

Der Überwachungsmodus ist standardmäßig aktiviert und kann in NSX nicht geändert werden. Es kann nur der Advertise-Modus geändert werden.

PortMirroring:

  • Gekapselte Remotespiegelungsquelle (L3)

Ja

Nur L3-Sitzungstyp wird für die Migration unterstützt

PortMirroring:

  • Verteiltes PortMirroring

  • Remotespiegelungsquelle

  • Remotespiegelungsziel

  • Mirroring verteilter Ports (Legacy)

Nein

L2-IPFIX

Ja

LAG mit IPFIX wird nicht unterstützt

Verteilte Firewall und IPFIX

Nein

MAC Learning

Ja

Sie müssen gefälschte Übertragungen aktivieren (akzeptieren).

Hardware-VTEP

Nein

Promiskuitiver Modus

Nein

Ressourcenzuteilung

Nein

vNIC mit aktivierter Ressourcenzuteilung wird nicht unterstützt

IPFIX – Interne Flows

Nein

IPFIX mit InternalFlows wird nicht unterstützt

Switch

NSX-V-Konfiguration

Unterstützt

Details

L2-Bridging

Nein

Trunk-VLAN

Ja für direkte Migration

Nein für Lift-and-Shift-Migration

Trunk-Uplink-Portgruppen muss mit einem VLAN-Bereich von 0–4094 konfiguriert werden.

VLAN-Konfiguration

Ja

Die Konfiguration nur mit VLAN (kein VXLAN) wird unterstützt.

Teaming und Failover:

  • Load Balancing

  • Uplink-Failover-Reihenfolge

Ja

Unterstützte Load Balancing-Optionen (Teaming-Richtlinie):

  • Ausdrückliche Failover-Reihenfolge verwenden

  • Anhand des Quell-MAC-Hashs routen

Andere Load Balancing-Optionen werden nicht unterstützt.

Teaming und Failover:

  • Netzwerkausfallerkennung

  • Switches benachrichtigen

  • Umkehrrichtlinie

  • Fortlaufende Reihenfolge

Nein

LACP Ja

Für VDS 7.0 und höher wird die LACP-Funktionalität während der Migration nicht geändert. Bei früheren Versionen von VDS ersetzt ein neuer N-VDS-Switch den VDS. Dies führt während der Hostmigration zu einem Verlust des Datenverkehrs.

IPFIX auf DVS (nicht DFW IPFIX) wird mit LACP nicht unterstützt

Switch-Sicherheit und IP Discovery

NSX-V-Konfiguration

Für die Migration unterstützt

Details

IP Discovery (ARP, ND, DHCPv4 und DHCPv6)

Ja

Die folgenden Bindungsgrenzwerte gelten für NSX für die Migration:

  • 128 für per ARP erkannte IPs

  • 128 für per DHCPv4 erkannte IPs

  • 15 für per DHCPv6 erkannte IPs

  • 15 für per ND erkannte IPs

SpoofGuard (manuell, TOFU, deaktiviert)

Ja

Switch-Sicherheit (BPDU-Filter, DHCP-Clientblock, DHCP-Serverblock, RA-Guard)

Ja

Migrieren von Datenpfadbindungen vom Switch-Sicherheitsmodul in NSX-V zum Switch-Sicherheitsmodul in NSX

Ja

Wenn SpoofGuard aktiviert ist, werden Bindungen aus dem Switch-Sicherheitsmodul migriert, um die ARP-Unterdrückung zu unterstützen.

VSIP – Switch-Sicherheit wird nicht unterstützt, da VSIP-Bindungen als statisch konfigurierte Regeln migriert werden.

Ermittlungsprofile

Ja

Die ipdiscovery-Profile werden nach der Migration mithilfe der IP Discovery-Konfiguration für den logischen Switch und der globalen und Cluster-ARP- und DHCP-Konfiguration erstellt.

Zentrale Control Plane

NSX-V-Konfiguration

Unterstützt

Details

VTEP-Replikation pro logischem Switch (VNI) und Routing-Domäne

Ja

MAC/IP-Replikation

Nein

NSX-V-Transportzonen mit Multicast- oder Hybrid-Replikationsmodus

Nein

NSX-V-Transportzonen mit Unicast-Replikationsmodus

Ja

Funktionen von NSX Edge

Ausführliche Informationen zu unterstützten Topologien finden Sie unter Unterstützte Topologien.

NSX-V-Konfiguration

Unterstützt

Details

Routing zwischen Edge Service Gateway und Northbound Router

Ja

BGP wird unterstützt.

Statische Routen werden unterstützt.

OSPF wird unterstützt.

Routing zwischen Edge Services Gateway und Distributed Logical Router

Ja

Routen werden nach der Migration in statische Routen umgewandelt.

Load Balancer

Ja

VLAN-gestützte Mikrosegmentierungs-Umgebung

Ja

Weitere Informationen finden Sie unter Unterstützte Topologien.

NAT64

Nein

Wird in NSX nicht unterstützt.

Einstellungen auf Knotenebene auf einem Edge Services Gateway oder einem Distributed Logical Router

Nein

Einstellungen auf Knotenebene, z. B. syslog oder NTP-Server, werden nicht unterstützt. Sie können Syslog und NTP manuell auf den NSX Edge-Knoten konfigurieren.

IPv6

Nein

Konfiguration für umgekehrten Unicast-Pfadfilter (URPF) für Edge Services Gateway-Schnittstellen

Nein

URPF auf NSX-Gateway-Schnittstellen ist auf „Streng“ festgelegt.

Konfiguration der maximalen Übertragungseinheit (MTU) für Edge Services Gateway-Schnittstellen

Nein

Informationen zum Ändern der Standard-MTU auf NSX finden Sie unter Ändern der globalen MTU-Einstellung.

IP-Multicast-Routing

Nein

Präfixfilter für Route Redistribution

Nein

Default Originate

Nein

Wird in NSX nicht unterstützt.

Edge-Firewall

NSX-V-Konfiguration

Unterstützt

Details

Abschnitt "Firewall": Anzeigename

Ja

Firewallabschnitte können maximal 1000 Regel aufweisen. Wenn ein Abschnitt mehr als 1000 Regeln enthält, wird er als mehrere Abschnitte migriert.

Aktion für Standardregel

Ja

NSX-V-API: GatewayPolicy/action

NSX-API: SecurityPolicy.action

Globale Firewallkonfiguration

Nein

Standard-Zeitüberschreitungen werden verwendet

Firewallregel

Ja

NSX-V-API: firewallRule

NSX-API: SecurityPolicy

Firewallregel: Name

Ja

Firewallregel: Regel-Tag

Ja

NSX-V-API: ruleTag

NSX-API: Rule_tag

Quellen und Ziele in Firewallregeln:

  • Objekte werden gruppiert

  • IP-Adressen

Ja

NSX-V-API:

  • source/groupingObjectId

  • source/ipAddress

NSX-API:

  • source_groups

NSX-V-API:

  • destination/groupingObjectId

  • destination/ipAddress

NSX-API:

  • destination_groups

Firewallregelquellen und -ziele:

  • vNIC-Gruppe

Nein

Dienste (Anwendungen) in Firewallregeln:

  • Dienst

  • Dienstgruppe

  • Protokoll/Port/Quellport

Ja

NSX-V-API:

  • application/applicationId

  • application/service/protocol

  • application/service/port

  • application/service/sourcePort

NSX-API:

  • Dienste

Firewallregel: Übersetzung zuordnen

Nein

Übersetzungszuordnung muss „false“ sein.

Firewallregel: Richtung

Ja

Beide APIs: direction

Firewallregel: Aktion

Ja

Beide APIs: action

Firewallregel: Aktiviert

Ja

Beide APIs: enabled

Firewallregel: Protokollierung

Ja

NSX-V-API: Protokollierung

NSX-API: protokolliert

Firewallregel: Beschreibung

Ja

Beide APIs: description

Edge-NAT

NSX-V-Konfiguration

Unterstützt

Details

NAT-Regel

Ja

NSX-V-API: natRule

NSX-API: /nat/USER/nat-rules

NAT-Regel: Regel-Tag

Ja

NSX-V-API: ruleTag

NSX-API: rule_tag

NAT-Regel: Aktion

Ja

NSX-V-API: Aktion

NSX-API: Aktion

NAT-Regel: ursprüngliche Adresse (Quelladresse für SNAT-

Regeln und die Zieladresse für DNAT-Regeln.)

Ja

NSX-V-API: originalAddress

NSX-API: source_network für SNAT-Regel oder destination_network für DNAT-Regel

NAT-Regel: translatedAddress

Ja

NSX-V-API: translatedAddress

NSX-API: translated_network

NAT-Regel: Anwenden einer NAT-Regel auf eine bestimmte Schnittstelle

Nein

„Angewendet auf“ muss „Alle“ sein.

NAT-Regel: Protokollierung

Ja

NSX-V-API: loggingEnabled

NSX-API: Protokollierung

NAT-Regel: aktiviert

Ja

NSX-V-API: aktiviert

NSX-API: deaktiviert

NAT-Regel: Beschreibung

Ja

NSX-V-API: Beschreibung

NSX-API: Beschreibung

NAT-Regel: Protokoll

Ja

NSX-V-API: Protokoll

NSX-API: Dienst

NAT-Regel: ursprünglicher Port (Quellport für SNAT-Regeln, Zielport für DNAT-Regeln)

Ja

NSX-V-API: originalPort

NSX-API: Dienst

NAT-Regel: übersetzter Port

Ja

NSX-V-API: translatedPort

NSX-API: Translated_ports

NAT-Regel: Quelladresse in DNAT-Regel

Ja

NSX-V-API: dnatMatchSourceAddress

NSX-API: source_network

NAT-Regel:

Zieladresse in SNAT-Regel

Ja

NSX-V-API: snatMatchDestinationAddress

NSX-API: destination_network

NAT-Regel:

Quellport in DNAT-Regel

Ja

NSX-V-API: dnatMatchSourcePort

NSX-API: Dienst

NAT-Regel:

Zielport in SNAT-Regel

Ja

NSX-V-API: snatMatchDestinationPort

NSX-API: Dienst

NAT-Regel: Regel-ID

Ja

NSX-V-API: ruleID

NSX-API: ID und display_name

L2 VPN

NSX-V-Konfiguration

Unterstützt

Details

L2VPN-Konfiguration basierend auf IPSec mithilfe von Pre-Shared Key (PSK)

Ja

Wird unterstützt, wenn das Netzwerk, das über L2VPN ausgedehnt wird, ein logischer Overlay-Switch ist. Wird nicht für VLAN-Netzwerke unterstützt.

L2VPN-Konfiguration basierend auf IPSec mithilfe der zertifikatbasierten Authentifizierung

Nein

L2VPN-Konfiguration basierend auf SSL

Nein

L2VPN-Konfigurationen mit lokalen Egress-Optimierungen

Nein

L2VPN-Clientmodus

Nein

L3VPN

NSX-V-Konfiguration

Unterstützt

Details

Erkennung inaktiver Peers

Ja

Die Erkennung inaktiver Peers unterstützt verschiedene Optionen für NSX-V und NSX. Möglicherweise sollten Sie die Verwendung von BGP für eine schnellere Konvergenz erwägen oder einen Peer so konfigurieren, dass er DPD ausführt, sofern dies unterstützt wird.

Die Standardwerte für die Erkennung inaktiver Peers (Dead Peer Detection, DPD) wurden geändert für:

  • dpdtimeout

  • dpdaction

Nein

In NSX ist dpdaction auf „restart“ festgelegt und kann nicht geändert werden.

Wenn die NSX-V-Einstellung für dpdtimeout auf 0 gesetzt ist, ist DPD in NSX deaktiviert. Andernfalls werden die dpdtimeout-Einstellungen ignoriert und der Standardwert wird verwendet.

Die Standardwerte für die Erkennung inaktiver Peers (Dead Peer Detection, DPD) wurden geändert für:

  • dpddelay 

Ja

NSX-V dpdelay wird NSX dpdinternal zugeordnet.

Überlappende lokale und Peer-Subnetze von zwei oder mehr Sitzungen.

Nein

NSX-V unterstützt richtlinienbasierte IPSec-VPN-Sitzungen, in denen lokale und Peer-Subnetze von zwei oder mehr Sitzungen miteinander überlappen. Dieses Verhalten wird in NSX nicht unterstützt. Sie müssen die Subnetze vor dem Start der Migration neu konfigurieren, damit sie sich nicht überlappen. Wenn dieses Konfigurationsproblem nicht behoben wird, schlägt der Schritt „Konfiguration migrieren“ fehl.

IPsec-Sitzungen mit Peer-Endpoint als „Alle“ festgelegt.

Nein

Konfiguration wird nicht migriert.

Änderungen an der Erweiterung securelocaltrafficbyip.

Nein

Der NSX-Dienstrouter verfügt über keinen lokalen generierten Datenverkehr, der über den Tunnel gesendet werden muss.

Änderungen an diesen Erweiterungen:

auto, sha2_truncbug, sareftrack, leftid, leftsendcert, leftxauthserver, leftxauthclient, leftxauthusername, leftmodecfgserver, leftmodecfgclient, modecfgpull, modecfgdns1, modecfgdns2, modecfgwins1, modecfgwins2, remote_peer_type, nm_configured, forceencaps,overlapip, aggrmode, rekey, rekeymargin, rekeyfuzz, compress, metric,disablearrivalcheck, failureshunt,leftnexthop, keyingtries

Nein

Diese Erweiterungen werden von NSX nicht unterstützt und Änderungen an ihnen werden nicht migriert.

Load Balancer

NSX-V-Konfiguration

Unterstützt

Details

Überwachung/Integritätsprüfungen für:

  • LDAP

  • DNS

  • MSSQL

Siehe Details.

Die Monitore werden nicht migriert.

Anwendungsregeln

Nein

NSX-V verwendet Anwendungsregeln auf Basis von HAProxy zur Unterstützung von L7. In NSX basieren die Regeln auf NGINX. Die Anwendungsregeln können nicht migriert werden. Nach der Migration müssen Sie neue Regeln erstellen.

Portbereich des virtuellen L7-Servers

Nein

IPv6

Nein

Wenn IPv6 in einem virtuellen Server verwendet wird, wird der gesamte virtuelle Server ignoriert.

Wenn IPv6 im Pool verwendet wird, wird der Pool migriert, aber das zugehörige Poolmitglied entfernt.

URL-, URI-, HTTPHEADER-Algorithmen

Siehe Details.

Pools mit diesen Algorithmen werden nicht migriert.

Isolierter Pool

Nein

LB-Poolmitglied mit anderem Überwachungsport

Siehe Details.

Das Poolmitglied mit einem anderen Überwachungsport wird nicht migriert.

Poolmitglied minConn

Nein

Überwachungserweiterung

Nein

SSL-sessionID-Persistenz/-Tabelle

Nein

MSRDP-Persistenz/-Sitzungstabelle

Nein

Cookie-App-Sitzung/-Sitzungstabelle

Nein

App-Persistenz

Nein

Überwachen auf:

  • Explizites Escape

  • Beenden

  • Verzögerung

Nein

Überwachen auf:

  • Senden

  • Erwarten

  • Zeitüberschreitung

  • Intervall

  • maxRetries

Ja

Haproxy-Tuning/IPVS-Tuning

Nein

Pool-IP-Filter

  • IPv4-Adressen

Ja

IPv4-IP-Adressen werden unterstützt.

Wenn „Alle“ verwendet wird, werden nur die IPv4-Adressen des IP-Pools migriert.

Pool-IP-Filter

  • IPv6-Adressen

Nein

Pool mit nicht unterstütztem Gruppierungsobjekt:

  • Cluster

  • Datencenter

  • Verteilte Portgruppe

  • MAC-Set

  • Virtuelle App

Nein

Wenn ein Pool ein nicht unterstütztes Gruppierungsobjekt enthält, werden diese Objekte ignoriert, und der Pool wird mit unterstützten Gruppierungsobjektmitgliedern erstellt. Wenn keine unterstützten Gruppierungsobjektmitglieder vorhanden sind, wird ein leerer Pool erstellt.

DHCP und DNS

Tabelle 1. DHCP-Konfigurationstopologien

NSX-V-Konfiguration

Unterstützt

Details

DHCP-Relay, das auf Distributed Logical Router konfiguriert ist und auf einen DHCP-Server verweist, der auf einem direkt verbundenen Edge Services Gateway konfiguriert ist

Ja

Die IP des DHCP-Relay-Servers muss eine der internen Schnittstellen-IPs des Edge Services Gateway sein.

Der DHCP-Server muss auf einem Edge Services Gateway konfiguriert werden, das direkt mit dem Distributed Logical Router verbunden ist, der mit dem DHCP-Relay konfiguriert ist.

DHCP-Relay, das auf mehreren verteilten logischen Routern konfiguriert ist und auf denselben DHCP-Server verweist, der auf einem Edge Services Gateway konfiguriert ist, wird nicht unterstützt.

DNAT kann nicht zum Übersetzen einer DHCP-Relay-IP verwendet werden, die nicht mit einer internen Schnittstelle des Edge Services Gateway übereinstimmt.

DHCP-Relay, das nur auf Distributed Logical Router konfiguriert ist, keine DHCP-Serverkonfiguration auf verbundenem Edge Services Gateway

Nein

DHCP-Server, der nur auf Edge Services Gateway konfiguriert ist, keine DHCP-Relay-Konfiguration auf verbundenem Distributed Logical Router

Nein

Tabelle 2. DHCP-Funktionen

NSX-V-Konfiguration

Unterstützt

Details

IP-Pools

Ja

Statische Bindungen

Ja

DHCP-Leases

Ja

Allgemeine DHCP-Optionen

Ja

DHCP-Dienst deaktiviert

Nein

In NSX können Sie den DHCP-Dienst nicht deaktivieren. Deaktivierte DHCP-Dienste auf NSX-V werden nicht migriert.

DHCP-Option: „Andere“

Nein

Das Feld „Andere“ in den DHCP-Optionen wird für die Migration nicht unterstützt.

Beispielsweise wird die DHCP-Option „80“ nicht migriert.

<dhcpOptions>
  <other>
    <code>80</code>
    <value>2f766172</value> 
  </other>
</dhcpOptions>  

Verwaiste IP-Pools/Bindungen

Nein

Wenn IP-Pools oder statische Bindungen auf einem DHCP-Server konfiguriert sind, aber nicht von verbundenen logischen Switches verwendet werden, werden diese Objekte bei der Migration übersprungen.

DHCP, das auf dem Edge Services Gateway mit direkt verbundenen logischen Switches konfiguriert ist

Nein

Während der Migration werden direkt verbundene Edge Services Gateway-Schnittstellen als zentralisierte Dienstports migriert. NSX unterstützt jedoch nicht den DHCP-Dienst auf einem zentralisierten Dienstport, sodass die DHCP-Dienstkonfiguration für diese Schnittstellen nicht migriert wird.

Tabelle 3. DNS-Funktionen

NSX-V-Konfiguration

Unterstützt

Details

DNS-Ansichten

Ja

Nur die erste dnsView wird in die standardmäßige DNS-Weiterleitungszone von NSX migriert.

DNS-Konfiguration

Ja

Sie müssen verfügbare DNS-Listener-IPs für alle Edge-Knoten bereitstellen. Während „Konfiguration auflösen“ wird eine Meldung angezeigt, die dazu auffordert.

DNS – L3-VPN

Ja

Sie müssen die neu konfigurierten NSX-DNS-Listener-IPs der Remote-L3-VPN-Präfixliste hinzufügen. Während „Konfiguration auflösen“ wird eine Meldung angezeigt, die dazu auffordert.

DNS, das auf dem Edge Services Gateway mit direkt verbundenen logischen Switches konfiguriert ist

Nein

Während der Migration werden direkt verbundene Edge Services Gateway-Schnittstellen als zentralisierte Dienstports migriert. NSX unterstützt jedoch nicht den DNS-Dienst auf einem zentralisierten Dienstport, sodass die DNS-Dienstkonfiguration für diese Schnittstellen nicht migriert wird.

Verteilte Firewall (Distributed Firewall, DFW)

NSX-V-Konfiguration

Unterstützt

Details

Identitätsbasierte Firewall

Ja

Abschnitt –

  • Name

  • Beschreibung

  • Strenges TCP

  • Stateless Firewall

Ja

Wenn ein Firewallabschnitt über mehr als 1000 Regeln verfügt, migriert der Migrator die Regeln in mehreren Abschnitten von jeweils 1000 Regeln.

Universelle Abschnitte

Ja, wenn die NSX-V-Bereitstellung über einen NSX Manager im primären Modus und keine sekundären NSX Manager verfügt.

Regel – Quelle/Ziel:

  • IP-Adresse/Bereich/CIDR

  • Logischer Port

  • Logischer Switch

Ja

Regel – Quelle/Ziel:

  • VM

  • Logischer Port

  • Sicherheitsgruppe/IP Set/MAC Set

Ja

wird Sicherheitsgruppe zugewiesen

Regel – Quelle/Ziel:

  • Cluster

  • Datencenter

  • DVPG

  • vSS

  • Host

Nein

Regel – Quelle/Ziel:

  • Globaler logischer Switch

Ja, wenn die NSX-V-Bereitstellung über einen NSX Manager im primären Modus und keine sekundären NSX Manager verfügt.

Regel – Quelle/Ziel:

  • VMs nicht auf NSX-V-Hosts

Nein NSX unterstützt keine Referenzobjekte, die nicht mit NSX-Portgruppen oder -Netzwerken verbunden sind. Diese Objekte gehen vom Quell- oder Zielort verloren, wenn die Migration abgeschlossen ist. Um dieses Problem zu vermeiden, verwenden Sie IP-Adressen in NSX-V, um vor der Migration auf diese Objekte zu verweisen.

Regel – Angewendet auf:

  • ANY

Ja

Zuordnung zur verteilten Firewall

Regel – Angewendet auf:

  • Sicherheitsgruppe

  • Logischer Port

  • Logischer Switch

  • VM

Ja

wird Sicherheitsgruppe zugewiesen

Regel – Angewendet auf:

  • Cluster

  • Datencenter

  • DVPG

  • vSS

  • Host

Nein

Regel – Angewendet auf:

  • Globaler logischer Switch

Nein

Ja, wenn die NSX-V-Bereitstellung über einen NSX Manager im primären Modus und keine sekundären NSX Manager verfügt.

Regeln in verteilter Firewall deaktiviert

Ja

Deaktivieren der verteilten Firewall auf Clusterebene

Nein

Wenn die verteilte Firewall auf NSX aktiviert ist, wird sie auf allen Clustern aktiviert. Sie können sie nicht auf einigen Clustern aktivieren und auf anderen deaktivieren.

DFW-Ausschlussliste Nein DFW-Ausschlusslisten werden nicht migriert. Sie müssen diese nach der Migration auf NSX erneut erstellen.

Partnerdienste: Vertikale Netzwerk-Introspektion

NSX-V-Konfiguration Unterstützt Details

Dienst

Nein

Die Dienstregistrierung wird nicht migriert. Der Partner muss den Dienst vor der Migration bei NSX registrieren.

Anbietervorlage

Nein

Anbietervorlage wird nicht migriert. Der Partner muss die Anbietervorlage vor der Migration bei NSX registrieren.

Dienstprofil

Nein

Dienstprofile werden nicht migriert. Entweder Sie oder der Partner muss vor der Migration die Dienstprofile erstellen.

Im Migrationsschritt „Konfiguration auflösen“ werden Sie aufgefordert, alle NSX-V-Dienstprofile einem NSX-Dienstprofil zuzuordnen. Wenn Sie die Zuordnung von Dienstprofilen überspringen, werden die Regeln, die diese Dienstprofile verwenden, nicht migriert.

Eine Dienstkette in NSX wird für jedes Dienstprofil in NSX-V erstellt. Die Dienstkette wird gemäß folgender Namenskonvention erstellt:

Service-Chain-service_profile_name

Im Weiterleitungspfad und im umgekehrten Pfad der Dienstkette wird dasselbe Dienstprofil verwendet.

Dienstinstanz

Nein

Die virtuellen Maschinen für Partnerdienste (SVMs) werden nicht migriert. Die NSX-V-Partner-SVMs können in NSX nicht verwendet werden.

Für den horizontalen Netzwerk-Introspektionsdienst in NSX müssen die Partner-SVMs auf einem Overlay-Segment bereitgestellt werden.

Abschnitt
  • Name
  • ID
  • Beschreibung
  • Strenges TCP
  • Stateless Firewall

Ja

Ein Abschnitt wird einer Umleitungsrichtlinie zugeordnet.

Die ID ist benutzerdefiniert und wird nicht automatisch in NSX generiert.

Wenn ein Firewallabschnitt in NSX-V über mehr als 1000 Regeln verfügt, werden die Regeln in mehreren Abschnitten von jeweils 1000 Regeln migriert. Wenn z. B. ein Abschnitt 2500 Regeln enthält, werden drei Richtlinien erstellt: Richtlinie 1 mit 1000 Regeln, Richtlinie 2 mit 1000 Regeln und Richtlinie 3 mit 500 Regeln.

Stateful oder Stateless Firewallregeln in NSX-V werden als statusbehaftete oder statusfreie Umleitungsregeln in NSX migriert.

Partnerdienste: Regeln

Name

Ja

Regel-ID

Ja

Die Regel-ID wird vom System generiert. Sie kann sich von der Regel-ID in NSX-V unterscheiden.

Quelle ablehnen

Ja

Ziel ablehnen

Ja

Quelle/Ziel
  • VM
  • Sicherheitsgruppe
  • IP Set
  • vNIC

Ja

Dienste/Dienstgruppen

Ja

Weitere Informationen finden Sie in der Tabelle „Dienste und Dienstgruppen“.
Erweiterte Einstellungen
  • Richtung
  • Pakettyp
  • Regel-Tag
  • Kommentare
  • Protokoll

Ja

Dienstprofil und Aktion
  • Dienstname
  • Dienstprofil
  • Aktion
  • Dienstprofil-Bindungen

Ja

Eine Dienstprofil-Bindung kann verteilte virtuelle Portgruppen (DVPG), logische Switches und Sicherheitsgruppen als Mitglieder besitzen. Eine Dienstprofil-Bindung in NSX-V wird dem Feld „Angewendet auf“ einer Umleitungsregel in NSX zugeordnet. Das Feld „Angewendet auf“ akzeptiert ausschließlich Gruppen. Dieses Feld bestimmt außerdem den Geltungsbereich der Regel.

In NSX findet die Regelumleitung auf Richtlinienebene statt. Alle in einer Umleitungsrichtlinie enthaltenen Regeln haben denselben Geltungsbereich („Angewendet auf“).

Das Feld „Angewendet auf“ in einer NSX-Umleitungsregel darf maximal 128 Mitglieder aufweisen. Falls die Anzahl der Mitglieder in einer Dienstprofil-Bindung 128 überschreitet, reduzieren Sie sie auf einen Wert <= 128, bevor Sie die Migration starten.

Nehmen wir beispielsweise an, dass eine Dienstprofil-Bindung 140 Mitglieder (Sicherheitsgruppen) aufweist. Führen Sie in NSX-V die folgenden Schritte aus, bevor Sie mit der Migration beginnen:
  1. Erstellen Sie eine Dummy-Sicherheitsgruppe
  2. Verschieben Sie 13 Sicherheitsgruppen in diese Dummy-Sicherheitsgruppe. Das heißt, die Dummy-Sicherheitsgruppe hat dann 13 Mitglieder.
  3. Entfernen Sie die Bindung dieser 13 Sicherheitsgruppen aus dem Dienstprofil. Sie verfügen nun über 127 Mitglieder in der Dienstprofil-Bindung (140-13).
  4. Fügen Sie die Dummy-Sicherheitsgruppe zur Dienstprofil-Bindung hinzu.

Jetzt beträgt die Gesamtzahl der Mitglieder in der Dienstprofilbindung 128 (127 + 1).

Regel aktivieren/deaktivieren

Ja

Dienstsegment
Ein Dienstsegment wird in der Overlay-Transportzone erstellt, die Sie im Migrationsschritt „Konfiguration auflösen“ auswählen. Wenn in der NSX-V-Umgebung die VXLAN-Transportzone nicht mit NSX-V vorbereitet wurde, haben Sie die Option, die standardmäßige Overlay-Transportzone in NSX auszuwählen, um das Dienstsegment zu erstellen. Wenn eine oder mehrere VXLAN-Transportzonen mit NSX-V vorbereitet wurden, müssen Sie eine beliebige Overlay-Transportzone auswählen, um das Dienstsegment in NSX zu erstellen.
Dienstprofil-Priorität
In NSX-V besitzt ein Dienstprofil eine Priorität. Wenn ein Dienst über mehrere Dienstprofile verfügt und mehrere Profile an dieselbe vNIC gebunden sind, wird zuerst das Dienstprofil mit der höheren Priorität auf die vNIC angewendet. In NSX weist ein Dienstprofil jedoch keine Priorität auf. Wenn mehrere Umleitungsregeln dieselbe „Angewendet auf“-Einstellung besitzen, entscheidet die Reihenfolge der Regeln, welche Regel zuerst ausgeführt wird. Mit anderen Worten: Die Regeln mit einer höheren Profilpriorität werden vor den Regeln mit einer niedrigeren Profilpriorität in der NSX-Regeltabelle platziert. Ein detailliertes Beispiel finden Sie in Szenario 2 unter Reihenfolge der migrierten Netzwerk-Introspektionsregeln in NSX.
Dienstvorrang

Um den Datenverkehr an mehrere Dienste umzuleiten, verwendet NSX-V im Service Insertion-Pfad mehrere DVFilter-Slots. Ein DVFilter-Slot wird für die Umleitung des Datenverkehrs zu einem Dienst verwendet. Ein Dienst mit hohem Vorrang wird höher im Slot platziert, als ein Dienst mit niedrigem Vorrang. In NSX wird nur ein einzelner DVFilter-Slot verwendet, der den Datenverkehr an eine Dienstkette umleitet. Nach der Migration zu NSX werden die Regeln, die einen Partnerdienst mit höherem Vorrang verwenden, vor den Regeln platziert, die einen Partnerdienst mit niedrigerem Vorrang verwenden. Ein detailliertes Beispiel finden Sie in Szenario 3 unter Reihenfolge der migrierten Netzwerk-Introspektionsregeln in NSX.

Die Umleitung des Datenverkehrs auf einer vNIC zu mehreren Partnerdiensten wird nicht unterstützt. Die Umleitung an einen einzigen Partnerdienst wird unterstützt. Obwohl alle NSX-V-Regeln zu NSX migriert werden, verwenden die migrierten Regelkonfigurationen eine Dienstkette mit nur einem Dienstprofil. Eine vorhandene Dienstkette, die in Umleitungsregeln verwendet wird, kann nicht bearbeitet werden.

Problemumgehung: Um den Datenverkehr auf einer vNIC an mehrere Dienste umzuleiten, erstellen Sie eine neue Dienstkette und definieren Sie die Reihenfolge der Dienstprofile in der Dienstkette. Aktualisieren Sie die migrierten Regeln, damit sie diese neue Dienstkette verwenden.

Netzwerk-Introspektionsdienst auf VMs, die mit einem VM-Netzwerk verbunden sind
Wenn in der NSX-V-Umgebung die Regeln des Netzwerk-Introspektionsdienstes auf VMs ausgeführt werden, die mit einem VM-Netzwerk verbunden sind, verlieren diese VMs nach der Hostmigration den Sicherheitsschutz. Um sicherzustellen, dass die Netzwerk-Introspektionsregeln nach der Hostmigration auf den vNICs dieser VMs durchgesetzt werden, müssen Sie diese VMs mit einem NSX-Segment verbinden.

Gruppieren von Objekten und Service Composer

IP Sets und MAC Sets werden als Gruppen zu NSX migriert. Weitere Informationen finden Sie unter Bestand > Gruppen auf der NSX Manager-Weboberfläche.

Tabelle 4. IP Sets und MAC Sets

NSX-V-Konfiguration

Unterstützt

Details

IP Sets

Ja

IP Sets mit bis zu 2 Millionen Mitgliedern (IP-Adressen, Subnetze von IP-Adressen, IP-Bereiche) können migriert werden. IP Sets mit mehr Mitgliedern werden nicht migriert.

Mac Sets

Ja

MAC Sets mit bis zu 2 Millionen Mitgliedern können migriert werden. MAC Sets mit mehr Mitgliedern werden nicht migriert.

Sicherheitsgruppen werden für die Migration mit den aufgeführten Einschränkungen unterstützt. Sicherheitsgruppen werden als Gruppen zu NSX migriert. Weitere Informationen finden Sie unter Bestand > Gruppen auf der NSX Manager-Weboberfläche.

NSX-V verfügt über systemdefinierte und benutzerdefinierte Sicherheitsgruppen. Diese werden alle als benutzerdefinierte Gruppen zu NSX migriert.

Die Gesamtanzahl der „Gruppen“ nach der Migration ist möglicherweise nicht gleich der Anzahl der Sicherheitsgruppen auf NSX-V. Beispielsweise würde eine Regel für eine verteilte Firewall, die eine virtuelle Maschine als Quelle enthält, in eine Regel migriert werden, die eine neue Gruppe mit der VM als Mitglied enthält. Dadurch wird die Gesamtanzahl der Gruppen auf NSX nach der Migration erhöht.

Tabelle 5. Sicherheitsgruppen

NSX-V-Konfiguration

Unterstützt

Details

Sicherheitsgruppe mit Mitgliedern, die nicht vorhanden sind

Nein

Wenn eines der Mitglieder der Sicherheitsgruppe nicht vorhanden ist, wird die Sicherheitsgruppe nicht migriert.

Sicherheitsgruppe, die eine Sicherheitsgruppe mit nicht unterstützten Mitgliedern enthält

Nein

Wenn Mitglieder der Sicherheitsgruppe nicht für die Migration unterstützt werden, wird die Sicherheitsgruppe nicht migriert.

Wenn eine Sicherheitsgruppe eine Sicherheitsgruppe mit nicht unterstützten Mitgliedern enthält, wird die übergeordnete Sicherheitsgruppe nicht migriert.

Mitgliedschaft in Sicherheitsgruppe ausschließen

Nein

Sicherheitsgruppen mit einem direkt oder indirekt (über Schachtelung) auszuschließenden Mitglied werden nicht migriert

Statische Mitgliedschaft in einer Sicherheitsgruppe

Ja

Eine Sicherheitsgruppe kann bis zu 500 statische Mitglieder enthalten. Allerdings werden vom System generierte statische Mitglieder hinzugefügt, wenn die Sicherheitsgruppe in den Regeln der verteilten Firewall verwendet wird, wodurch der effektive Grenzwert auf 499 oder 498 gesenkt wird.

  • Wenn die Sicherheitsgruppe in Layer-2- oder Layer-3-Regeln verwendet wird, wird ein vom System generiertes statisches Mitglied zur Sicherheitsgruppe hinzugefügt.

  • Wenn die Sicherheitsgruppe sowohl in Layer-2- als auch in Layer-3-Regeln verwendet wird, werden zwei vom System generierte statische Mitglieder hinzugefügt.

Wenn Mitglieder während des Schritts „Konfiguration auflösen“ nicht vorhanden sind, wird die Sicherheitsgruppe nicht migriert.

Mitgliedertypen der Sicherheitsgruppe („Statisch“ oder „Entität“ gehört zu):

  • Cluster

  • Datencenter

  • Verzeichnisgruppe

  • Verteilte Portgruppe

  • Legacy-Portgruppe/-Netzwerk

  • Ressourcenpool

  • vApp

Nein

Wenn eine Sicherheitsgruppe einen der nicht unterstützten Mitgliedstypen enthält, wird die Sicherheitsgruppe nicht migriert.

Mitgliedertypen der Sicherheitsgruppe („Statisch“ oder „Entität“ gehört zu):

  • Sicherheitsgruppe

  • IP Sets

  • MAC Sets

Ja

Sicherheitsgruppen, IP Sets und MAC Sets werden als Gruppen zu NSX migriert. Wenn eine NSX-V-Sicherheitsgruppe ein IP Set, ein MAC Set oder eine verschachtelte Sicherheitsgruppe als statisches Mitglied enthält, werden die entsprechenden Gruppen der übergeordneten Gruppe hinzugefügt.

Wenn eines dieser statischen Mitglieder nicht zu NSX migriert wurde, wird die übergeordnete Sicherheitsgruppe nicht zu NSX migriert.

Beispiel: Ein IP Set mit mehr als 2 Millionen Mitgliedern kann nicht zu NSX migriert werden. Aus diesem Grund ist für eine Sicherheitsgruppe, die ein IP Set mit mehr als 2 Millionen Mitgliedern enthält, keine Migration möglich.

Mitgliedertypen der Sicherheitsgruppe („Statisch“ oder „Entität“ gehört zu):

  • Logischer Switch (virtuelle Leitung)

Ja

Wenn eine Sicherheitsgruppe logische Switches enthält, die nicht zu NSX-Segmenten migriert werden, wird die Sicherheitsgruppe nicht zu NSX migriert.

Mitgliedertypen der Sicherheitsgruppe („Statisch“ oder „Entität“ gehört zu):

  • Sicherheits-Tag

Ja

Wenn der Sicherheitsgruppe ein Sicherheits-Tag als statisches Mitglied oder als dynamisches Mitglied mit „Entität gehört zu“ hinzugefügt wird, muss das Sicherheits-Tag vorhanden sein, damit die Sicherheitsgruppe migriert werden kann.

Wenn das Sicherheits-Tag der Sicherheitsgruppe nicht als dynamisches Mitglied hinzugefügt wird (ohne „Entität gehört zu“), wird das Vorhandensein des Sicherheits-Tags vor der Migration der Sicherheitsgruppe nicht überprüft.

Mitgliedertypen der Sicherheitsgruppe („Statisch“ oder „Entität“ gehört zu):

  • vNIC

  • Virtuelle Maschine

Ja

  • vNICs und VMs werden als ExternalIDExpression migriert.

  • Verwaiste VMs (von Hosts gelöschte VMs) werden bei der Migration von Sicherheitsgruppen ignoriert.

  • Sobald die Gruppen auf NSX angezeigt werden, werden die VM- und vNIC-Mitgliedschaften nach einiger Zeit aktualisiert. Während dieser Zwischenzeit können temporäre Gruppen vorhanden sein, und ihre temporären Gruppen werden möglicherweise als Mitglieder angezeigt. Wenn die Hostmigration jedoch abgeschlossen ist, werden diese zusätzlichen temporären Gruppen nicht mehr angezeigt.

Verwenden des Operators „Stimmt mit regulärem Ausdruck überein“ für die dynamische Mitgliedschaft

Nein

Dies betrifft nur das Sicherheits-Tag und den VM-Namen. „Stimmt mit regulärem Ausdruck überein“ ist für andere Attribute nicht verfügbar.

Verwenden anderer verfügbarer Operatoren für dynamische Mitgliedschaftskriterien für Attribute:

  • Sicherheits-Tag

  • VM-Name

  • Computername

  • Name des Computer-Betriebssystems

Ja

Die verfügbaren Operatoren für VM-Name, Computername und Name des Computer-Betriebssystems sind „Enthält“, „Endet mit“, „Gleich“, „Ungleich“, „Beginnt mit“.

Die verfügbaren Operatoren für das Sicherheits-Tag sind „Enthält“, „Endet mit“, „Gleich“, „Beginnt mit“.

Kriterien für „Entität gehört zu“

Ja

Dieselben Einschränkungen für die Migration statischer Mitglieder gelten für die Kriterien für „Entität gehört zu“. Wenn beispielsweise eine Sicherheitsgruppe „Entität gehört zu“ für einen Cluster in der Definition verwendet, wird diese Sicherheitsgruppe nicht migriert.

Sicherheitsgruppen, die Kriterien für „Entität gehört zu“ enthalten, die mit UND kombiniert werden, werden nicht migriert.

Operatoren für dynamische Mitgliedschaftskriterien (UND, ODER) in der Sicherheitsgruppe

Ja.

Wenn Sie die dynamische Mitgliedschaft für eine NSX-V-Sicherheitsgruppe definieren, können Sie Folgendes konfigurieren:

  • einen oder mehrere dynamische Sätze.

  • Jeder dynamische Satz kann mehrere dynamische Kriterien enthalten. Beispiel: „VM-Name enthält web“.

  • Sie können auswählen, ob beliebige oder alle dynamischen Kriterien innerhalb eines dynamischen Satzes übereinstimmen sollen.

  • Sie können auswählen, ob Sie dynamische Sätze mit UND oder ODER abgleichen.

NSX-V begrenzt nicht die Anzahl der dynamischen Kriterien und dynamischen Sätze. Sie können beliebige Kombinationen aus UND und ODER verwenden.

In NSX können Sie eine Gruppe mit fünf Ausdrücken verwenden. NSX-V-Sicherheitsgruppen, die mehr als fünf Ausdrücke enthalten, werden nicht migriert.

Beispiele für Sicherheitsgruppen, die migriert werden können:

  • Bis zu 5 dynamische Sätze, die mit ODER verknüpft sind, bei denen jeder dynamische Satz bis zu 5 dynamische Kriterien beinhaltet, die mit UND verknüpft sind („Alle“ in NSX-V).

  • 1 dynamischer Satz mit 5 dynamischen Kriterien, die mit ODER verknüpft sind („Beliebig“ in NSX-V).

  • 1 dynamischer Satz mit 5 dynamischen Kriterien, die mit UND verknüpft sind („Alle“ in NSX-V). Alle Mitgliedstypen müssen identisch sein.

  • 5 dynamische Sätze, die mit UND verknüpft sind und von denen jeder dynamische Satz genau 1 dynamisches Kriterium enthält. Alle Mitgliedstypen müssen identisch sein.

Die Verwendung von Kriterien für „Entität gehört zu“ mit UND-Operatoren wird nicht unterstützt.

Alle anderen Kombinationen oder Definitionen einer Sicherheitsgruppe, die nicht unterstützte Szenarien enthält, werden nicht migriert.

In NSX-V sind Sicherheits-Tags Objekte, die auf VMs angewendet werden können. Bei der Migration zu NSX sind Sicherheits-Tags Attribute einer VM.

Tabelle 6. Sicherheits-Tags

NSX-V-Konfiguration

Unterstützt

Details

Sicherheits-Tags

Ja

Wenn auf eine VM 25 oder weniger Sicherheits-Tags angewendet werden, wird die Migration von Sicherheits-Tags unterstützt. Wenn mehr als 25 Sicherheits-Tags angewendet werden, werden keine Tags migriert.

Hinweis: Wenn Sicherheits-Tags nicht migriert werden, ist die VM nicht in Gruppen enthalten, die durch die Tag-Mitgliedschaft definiert sind.

Sicherheits-Tags, die nicht auf eine VM angewendet werden, werden nicht migriert.

Dienste und Dienstgruppen werden als Dienste zu NSX migriert. Weitere Informationen finden Sie unter Bestand > Dienste auf der NSX Manager-Weboberfläche.

Tabelle 7. Dienste und Dienstgruppen

NSX-V-Konfiguration

Unterstützt

Details

Dienste und Dienstgruppen (Anwendungen und Anwendungsgruppen)

Ja

Die meisten Standarddienste und Dienstgruppen werden NSX-Diensten zugeordnet. Wenn ein Dienst oder eine Dienstgruppe in NSX nicht vorhanden ist, wird ein neuer Dienst in NSX erstellt.

APP_ALL- und APP_POP2-Dienstgruppen

Nein

Diese vom System definierten Dienstgruppen werden nicht migriert.

Dienste und Dienstgruppen mit Benennungskonflikten

Ja

Wenn in NSX ein Namenskonflikt für einen geänderten Dienst oder eine geänderte Dienstgruppe identifiziert wird, wird ein neuer Dienst in NSX mit einem Namen im folgenden Format erstellt: <NSXv-Anwendungsname> migriert aus NSX-v

Dienstgruppen, die Layer-2-Dienste mit Diensten in anderen Layern kombinieren

Nein

Leere Dienstgruppen

Nein

NSX unterstützt keine leeren Dienste.

Layer-2-Dienste

Ja

NSX-V Layer 2-Dienste werden als NSX-Diensteintrag „EtherTypeServiceEntry“ migriert.

Layer-3-Dienste

Ja

Basierend auf dem Protokoll werden NSX-V Layer-3-Dienste wie folgt zum NSX-Diensteintrag migriert:

  • TCP/UDP-Protokoll: L4PortSetServiceEntry

  • ICMP/IPV6ICMP-Protokoll:

ICMPTypeServiceEntry

  • IGMP-Protokoll: IGMPTypeServiceEntry

  • Andere Protokolle: IPProtocolServiceEntry

Layer-4-Dienste

Ja

Als NSX-Diensteintrag „ALGTypeServiceEntry“ migriert.

Layer-7-Dienste

Ja

Als NSX-Diensteintrag „PolicyContextProfile“ migriert.

Wenn für eine NSX-V Layer-7-Anwendung ein Port und ein Protokoll definiert sind, wird ein Dienst in NSX mit der entsprechenden Port- und Protokollkonfiguration erstellt und dem PolicyContextProfile zugeordnet.

Layer-7-Dienstgruppen

Nein

Regeln für verteilte Firewall, Edge-Firewall oder NAT, die Port und Protokoll enthalten

Ja

NSX erfordert einen Dienst zum Erstellen dieser Regeln. Wenn ein angemessener Dienst vorhanden ist, wird er verwendet. Wenn kein angemessener Dienst vorhanden ist, wird ein Dienst mit dem in der Regel angegebenen Port und Protokoll erstellt.

Tabelle 8. Service Composer

NSX-V-Konfiguration

Unterstützt

Details

Service Composer-Sicherheitsrichtlinien

Ja

In einer Sicherheitsrichtlinie definierte Firewallregeln werden als Regeln für eine verteilte Firewall zu NSX migriert.

Deaktivierte Firewallregeln, die in einer Service Composer-Sicherheitsrichtlinie definiert sind, werden nicht migriert.

Guest Introspection-Regeln oder Netzwerk-Introspektionsregeln, die in einer Service Composer-Sicherheitsrichtlinie definiert sind, werden migriert.

Wenn der Service Composer-Status nicht synchronisiert ist, wird im Schritt „Konfiguration auflösen“ eine Warnung angezeigt. Sie können die Migration von Service Composer-Richtlinien überspringen, indem Sie die relevanten Abschnitte der verteilten Firewall überspringen. Alternativ können Sie die Migration zurücksetzen, Service Composer mit der verteilten Firewall synchronisieren und die Migration neu starten.

Service Composer-Sicherheitsrichtlinien werden nicht auf Sicherheitsgruppen angewendet

Nein

Active Directory-Serverkonfiguration

Konfiguration

Unterstützt

Details

Active Directory-(AD-)Server

Nein