Virtual Connect verwendet eine Dual-Tier-Kopfend-Architektur, bei der die Routing- und VIRTUELL-Steuerungsebenen von einem Gerät bereitgestellt werden und die IPSec-Steuerungsebene von einem anderen Gerät bereitgestellt wird.

Nach Abschluss der Virtual Connect-Konnektivität werden zwei SEKTE-Tunnel über IPSec zwischen dem Unternehmensnetzwerk des Kunden und den Cisco-Datenzentren der dedizierten Instanz erstellt. Eins zu jedem redundanten Rechenzentrum innerhalb der jeweiligen Region. Zusätzliche für das Peering erforderliche Netzwerkelemente werden vom Partner oder Kunden über das Aktivierungsformular für den virtuellen Control Hub Connect an Cisco ausgetauscht.

Die folgende Abbildung zeigt das Beispiel des Virtual Connect-Bereitstellungsmodells für die 2-Konzentrator-Option auf der Kundenseite.

Virtual Connect – VPN ist ein Hub-Design, bei dem die Hub-Sites des Kunden mit dc1 und DC2 der Datenzentren der dedizierten Instanz innerhalb einer bestimmten Region verbunden sind.

Für eine bessere Redundanz werden zwei Hub-Sites empfohlen. Ein Hub-Standort mit zwei Tunnels wird jedoch ebenfalls als Bereitstellungsmodell unterstützt.

Von den Partnern wird erwartet, dass sie eng mit den Kunden zusammenarbeiten und sicherstellen, dass der optimale Pfad für die Serviceregion von Virtual Connect gewählt wird.

Die folgende Abbildung zeigt die Peering-Regionen der Cloud-Konnektivität der dedizierten Instanz.

Das Routing für das Virtual Connect-Add-on wird mithilfe einer externen BGP (eBGP) zwischen dedizierter Instanz und dem Customer Premise Equipment (CPE) implementiert. Cisco wird das entsprechende Netzwerk für jeden redundanten DC innerhalb einer Region für den CPE des Kunden ankämten, und der CPE ist erforderlich, um eine Standard-Route an Cisco zu angekündigt.

• Cisco verwaltet und weist zu

  • Tunnel-Interface-IP-Adressierung (vorübergehende Weiterleitungsverbindung) Cisco-Zuweisungen von einem bestimmten gemeinsam genutzten Adressbereich (nicht öffentlich routingfähig)

  • Tunneltransportdeitierungsadresse (Seite von Cisco)

  • Private AsNs (Private Routing System Numbers) für BGP-Routing-Konfiguration des Kunden

    • Cisco weist aus dem angegebenen Bereich für die private Nutzung: 64512 bis 65534

• eBGP zum Austausch von Routen zwischen dedizierter Instanz und CPE

  • Cisco teilt das zugewiesene /24-Netzwerk für jeden DC in der jeweiligen Region in 2 /25.

  • In Virtual Connect wird jedes /25-Netzwerk von Cisco über die entsprechenden Point-to-Point-VPN-Tunnel (vorübergehende Verbindung) dem CPE zurück angekündigt

  • CPE muss mit den entsprechenden eBGP-Neighbors konfiguriert werden. Wenn Sie einen CPE verwenden, werden zwei eBGP-Neighbors verwendet, die jeweils einen zu jedem Ferntunnel zeigen. Wenn sie zwei CPE verwenden, dann hat jeder CPE einen eBGP-Nachbar, der zum einzigen Remote-Tunnel der CPE wird.

  • Die Cisco-Seite jedes TUNNEL-Tunnels (Tunnel-Schnittstellen-IP) ist als BGP-Nachbar des CPE konfiguriert.

  • CPE ist erforderlich, um eine Standardroute über jeden Tunnel zu stellen

  • CPE kann, wie erforderlich, für die Neuverteilung der Lernrouten innerhalb des Unternehmensnetzwerks der Cutomer verantwortlich sein.

• Unter der Bedingung eines Ausfallausfalls der Verbindung wird ein einzelner CPE zwei Aktive/Aktiv-Tunnel haben. Für zwei CPE-Knoten hat jeder CPE einen aktiven Tunnel, und beide CPE-Knoten sollten aktiv sein und den Datenverkehr übergeben. Unter Nicht-Ausfall-Szenarios muss sich der Verkehr in zwei Tunnels teilen, die zu den korrekten /25-Zielen gehen. Wenn einer der Tunnels abläuft, kann der verbleibende Tunnel den Verkehr für beide Personen führen. Bei einem solchen Ausfallszenario wird bei Ausfällen des /25-Netzwerks das /24-Netzwerk als Backup-Route verwendet. Cisco sendet den Kundenverkehr über sein internes WAN nach DC, wodurch die Konnektivität verloren geht.

Die IPsec-Tunnelaushandlung umfasst zwei Phasen, die IKEv2-Phase und die IPsec-Phase. Wenn die Aushandlung der IKEv2-Phase nicht abgeschlossen wird, erfolgt keine Einleitung einer zweiten IPsec-Phase. Geben Sie zunächst den Befehl „show crypto ikev2 sa“ (auf Cisco-Geräten) oder einen ähnlichen Befehl auf Geräten von Drittanbietern ein, um zu überprüfen, ob die IKEv2-Sitzung aktiv ist. Wenn die IKEv2-Sitzung nicht aktiv ist, kann dies folgende Gründe haben:

• Interessanter Datenverkehr löst den IPsec-Tunnel nicht aus.

• Die IPsec-Tunnelzugriffsliste ist falsch konfiguriert.

• Es besteht keine Verbindung zwischen dem Kunden und der IPsec-Tunnel-Endpunkt-IP der dedizierten Instanz.

• Die IKEv2-Sitzungsparameter stimmen auf der Seite der dedizierten Instanz und auf der Kundenseite nicht überein.

• Eine Firewall blockiert die IKEv2-UDP-Pakete.

Überprüfen Sie zunächst die IPsec-Protokolle auf Meldungen, die den Fortschritt der IKEv2-Tunnelaushandlung anzeigen. Die Protokolle können Hinweise darauf geben, wo bei der IKEv2-Aushandlung ein Problem vorliegt. Das Fehlen von Protokollierungsmeldungen kann auch darauf hinweisen, dass die IKEv2-Sitzung nicht aktiviert wird.

Einige häufige Fehler bei der IKEv2-Aushandlung sind:

• Die Einstellungen für IKEv2 auf der CPE-Seite stimmen nicht mit denen von Cisco überein. Überprüfen Sie die genannten Einstellungen erneut:

  • Überprüfen Sie, ob die IKE-Version Version 2 ist.

  • Überprüfen Sie, ob die Verschlüsselungs- und Authentifizierungsparameter mit der erwarteten Verschlüsselung auf der Seite der dedizierten Instanz übereinstimmen.

    Wenn die „GCM“-Verschlüsselung verwendet wird, übernimmt das GCM-Protokoll die Authentifizierung und setzt den Authentifizierungsparameter auf NULL.

  • Überprüfen Sie die Lebensdauereinstellung.

  • Überprüfen Sie die Diffie-Hellman-Modulgruppe.

  • Überprüfen Sie die Einstellungen der Pseudozufallsfunktion.

• Die Zugriffsliste für die Crypto Map ist nicht auf Folgendes eingestellt:

  • Permit GRE (local_tunnel_transport_ip) 255.255.255.255 (remote_tunnel_transport_ip) 255.255.255.255" (oder gleichwertiger Befehl)

    Die Zugriffsliste muss speziell für das „GRE“-Protokoll sein, das „IP“-Protokoll funktioniert nicht.

Wenn die Protokollmeldungen keine Verhandlungsaktivität für die IKEv2-Phase anzeigen, ist möglicherweise eine Paketerfassung erforderlich.

Bei richtiger Konfiguration beginnt der IPsec-Tunnel und die erste Phase der IKEv2-Aushandlung mit Folgendem:

• GRE-Keepalives von der GRE-Tunnelschnittstelle auf der CPE-Seite zur GRE-Tunnelschnittstelle auf der Dedicated Instance-Seite.

• BGP-Nachbar-TCP-Sitzung vom BGP-Nachbarn auf der CPE-Seite zum BGP-Nachbarn auf der Dedicated Instance-Seite.

• Ping von der Tunnel-IP-Adresse auf der CPE-Seite zur Tunnel-IP-Adresse auf der Dedicated Instance-Seite.

  Der Ping kann nicht von Tunnel-Transport-IP zu Tunnel-Transport-IP erfolgen, er muss von Tunnel-IP zu Tunnel-IP erfolgen.

Wenn eine Paketverfolgung für den IKEv2-Verkehr erforderlich ist, stellen Sie den Filter für UDP und entweder Port 500 (wenn sich kein NAT-Gerät in der Mitte der IPsec-Endpunkte befindet) oder Port 4500 (wenn ein NAT-Gerät in der Mitte der IPsec-Endpunkte eingefügt ist) ein.

Überprüfen Sie, ob IKEv2-UDP-Pakete mit Port 500 oder 4500 an die DI-IPsec-IP-Adresse gesendet und von dieser empfangen werden.

Stellen Sie sicher, dass die erste Phase von IPsec (d. h. die IKEv2-Sicherheitszuordnung) aktiv ist, bevor Sie die Fehlerbehebung für die zweite Phase von IPsec durchführen. Führen Sie „show crypto ikev2 sa“ oder einen gleichwertigen Befehl aus, um die IKEv2-Sitzung zu überprüfen. Überprüfen Sie in der Ausgabe, ob die IKEv2-Sitzung länger als ein paar Sekunden aktiv ist und nicht abprallt. Die Sitzungsverfügbarkeit wird in der Ausgabe als „Aktive Zeit“ der Sitzung oder als Äquivalent angezeigt.

Sobald bestätigt wurde, dass die IKEv2-Sitzung aktiv ist, untersuchen Sie die IPsec-Sitzung. Führen Sie wie bei der IKEv2-Sitzung einen „show crypto ipsec sa“- oder gleichwertigen Befehl aus, um die IPsec-Sitzung zu überprüfen. Sowohl die IKEv2-Sitzung als auch die IPsec-Sitzung müssen aktiv sein, bevor der GRE-Tunnel hergestellt wird. Wenn die IPsec-Sitzung nicht als aktiv angezeigt wird, überprüfen Sie die IPsec-Protokolle auf Fehlermeldungen oder Verhandlungsfehler.

Zu den häufigeren Problemen, die während der IPsec-Verhandlungen auftreten können, gehören:

Die Einstellungen auf der CPE-Seite stimmen nicht mit denen der dedizierten Instanz überein. Überprüfen Sie die Einstellungen erneut:

• Überprüfen Sie, ob die Verschlüsselungs- und Authentifizierungsparameter mit den Einstellungen auf der Seite der dedizierten Instanz übereinstimmen.

• Überprüfen Sie die Perfect Forward Secrecy-Einstellungen und stellen Sie sicher, dass die Einstellungen auf der Seite der dedizierten Instanz übereinstimmen.

• Überprüfen Sie die Lebensdauereinstellungen.

• Stellen Sie sicher, dass IPsec im Tunnelmodus konfiguriert wurde.

• Überprüfen Sie die Quell- und Ziel-IPsec-Adressen.

Wenn die IPsec- und IKEv2-Sitzungen als aktiv und aufrecht verifiziert sind, können die Keepalive-Pakete des GRE-Tunnels zwischen den Endpunkten der dedizierten Instanz und des CPE-Tunnels fließen. Wenn der Status der Tunnelschnittstelle nicht angezeigt wird, können dies einige häufige Probleme sein:

• Das Transport-VRF der Tunnelschnittstelle stimmt nicht mit dem VRF der Loopback-Schnittstelle überein (wenn auf der Tunnelschnittstelle eine VRF-Konfiguration verwendet wird).

  Wenn die VRF-Konfiguration auf der Tunnelschnittstelle nicht verwendet wird, kann diese Prüfung ignoriert werden.

• Keepalives sind auf der CPE-seitigen Tunnelschnittstelle nicht aktiviert

  Wenn Keepalives auf der CPE-Ausrüstung nicht unterstützt werden, muss Cisco benachrichtigt werden, damit die Standard-Keepalives auf der Seite der dedizierten Instanz ebenfalls deaktiviert werden.

  Wenn Keepalives unterstützt werden, überprüfen Sie, ob die Keepalives aktiviert sind.

• Die Maske oder IP-Adresse der Tunnelschnittstelle ist nicht korrekt und stimmt nicht mit den erwarteten Werten der dedizierten Instanz überein.

• Die Quell- oder Ziel-Tunneltransportadresse ist nicht korrekt und stimmt nicht mit den erwarteten Werten der dedizierten Instanz überein.

• Eine Firewall blockiert das Senden und Empfangen von GRE-Paketen in den IPsec-Tunnel (der GRE-Tunnel wird über den IPsec-Tunnel transportiert).

Ein Ping-Test sollte bestätigen, dass die lokale Tunnelschnittstelle aktiv ist und eine gute Verbindung zur Remote-Tunnelschnittstelle besteht. Führen Sie den Ping-Check von der Tunnel-IP (nicht der Transport-IP) zur Remote-Tunnel-IP durch.

Die Ping-Prüfung führt zu einem GRE-Paket, das von der Quell-Tunneltransport-IP zur Ziel-Tunneltransport-IP generiert wird, während die Nutzlast des GRE-Pakets (die interne IP) die Quell- und Ziel-Tunnel-IP ist.

Wenn der Ping-Test nicht erfolgreich ist und die vorhergehenden Elemente überprüft werden, ist möglicherweise eine Paketerfassung erforderlich, um sicherzustellen, dass der ICMP-Ping zu einem GRE-Paket führt, das dann in ein IPsec-Paket gekapselt und dann von der Quell-IPsec-Adresse an die Ziel-IPsec-Adresse gesendet wird. Zähler auf der GRE-Tunnelschnittstelle und die IPsec-Sitzungszähler können ebenfalls dabei helfen, anzuzeigen, ob die gesendeten und empfangenen Pakete inkrementell sind.

Zusätzlich zum Ping-Verkehr sollte die Erfassung auch Keepalive-GRE-Pakete anzeigen, selbst während des Leerlaufverkehrs. Wenn BGP konfiguriert ist, sollten BGP-Keepalive-Pakete schließlich auch als in IPSEC-Paketen gekapselte GRE-Pakete über das VPN gesendet werden.

Auf der Seite der dedizierten Instanz sind zwei Funktionen aktiviert, um die MTU für große Paketgrößen dynamisch anzupassen. Der GRE-Tunnel fügt den IP-Paketen, die durch die VPN-Sitzung fließen, weitere Header hinzu. Der IPsec-Tunnel fügt die zusätzlichen Header über den GRE-Headern hinzu und reduziert so die größte über den Tunnel zulässige MTU weiter.

Der GRE-Tunnel passt die MSS-Funktion an und der GRE-Tunnelpfad in der MTU-Erkennungsfunktion ist auf der Seite der dedizierten Instanz aktiviert. Konfigurieren Sie "ip tcp adjust-mss 1350" oder einen gleichwertigen Befehl sowie "tunnel path\u0002mtu-discovery" oder ein gleichwertiger Befehl auf der Kundenseite, um die dynamische Anpassung der MTU des Datenverkehrs durch den VPN-Tunnel zu unterstützen.