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 Bereitstellungsmodells für virtuelle Verbindung für die Option 2-Konzentrator auf 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 für die Virtual Connect -Dienstregion der optimale Pfad gewählt wird.

Die folgende Abbildung zeigt die Cloud-Konnektivität-Peering-Regionen 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-Tunnelverhandlung umfasst zwei Phasen, die IKEv2-Phase und die IPsec-Phase. Wenn die Aushandlung der IKEv2-Phase nicht abgeschlossen ist, erfolgt keine zweite IPsec-Phase. Geben Sie zunächst den Befehl „show crypto ikev2 sa“ (auf Cisco-Geräten) oder einen ähnlichen Befehl auf der Drittanbieterausrüstung aus, um zu überprüfen, ob die IKEv2-Sitzung aktiv ist. Wenn die IKEv2-Sitzung nicht aktiv ist, könnten folgende Gründe vorliegen:

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

• Die IPsec-Tunnel-Zugriffsliste ist falsch konfiguriert.

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

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

• Eine Firewall blockiert die IKEv2 UDP-Pakete.

Prüfen Sie zunächst die IPsec-Protokolle auf Nachrichten, die den Fortschritt der IKEv2-Tunnel-Aushandlung anzeigen. Die Protokolle können anzeigen, wo ein Problem mit der IKEv2-Verhandlung vorliegt. Das Fehlen von Protokollierungsmeldungen kann auch darauf hinweisen, dass die IKEv2-Sitzung nicht aktiviert wird.

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

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

  • Stellen Sie sicher, dass die IKE-Version Version 2 ist.

  • Stellen Sie sicher, dass die Verschlüsselungs- und Authentifizierungsparameter mit der erwarteten Verschlüsselung auf der Seite der dedizierten Instanz übereinstimmen.

    Wenn die GCM-Verschlüsselung verwendet wird, verarbeitet das GCM-Protokoll die Authentifizierung und legt den Authentifizierungsparameter auf NULL fest.

  • Überprüfen Sie die Lebenszeiteinstellung.

  • Überprüfen Sie die Diffie-Hellman-Modul-Gruppe.

  • Überprüfen Sie die Einstellungen der Pseudozufallsfunktion.

• Die Zugriffsliste für die Kryptokarte ist nicht festgelegt auf:

  • 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, und das „IP“-Protokoll funktioniert nicht.

Wenn in den Protokollnachrichten keine Aushandlungsaktivität für die IKEv2-Phase angezeigt wird, kann eine Paketerfassung erforderlich sein.

Bei ordnungsgemäßer Konfiguration beginnt Folgendes mit dem IPsec-Tunnel und der ersten Phase der IKEv2-Aushandlung:

• GRE-Keepalives von der CPE-seitigen GRE-Tunnelschnittstelle zur GRE-Tunnelschnittstelle der dedizierten Instanz.

• BGP-Nachbar-TCP-Sitzung vom BGP-Nachbar der CPE-Seite zum BGP-Nachbar der dedizierten Instanz.

• Pingen Sie die IP-Adresse des CPE-Seitentunnels an die IP-Adresse des Seitentunnels der dedizierten Instanz.

  Ping kann nicht die Tunnel-Transport-IP zu Tunnel-Transport-IP sein, es muss Tunnel-IP zu Tunnel-IP sein.

Wenn für den IKEv2-Datenverkehr eine Paketverfolgung erforderlich ist, legen 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 befindet) fest.

Stellen Sie sicher, dass IKEv2 UDP-Pakete mit Port 500 oder 4500 an und von der DI IPsec-IP-Adresse gesendet und empfangen werden.

Überprüfen Sie, ob die erste IPsec-Phase (d. h. IKEv2-Sicherheitszuordnung) aktiv ist, bevor Sie die zweite IPsec-Phase beheben. Führen Sie den Befehl "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 seit mehr als ein paar Sekunden aktiv ist und nicht springt. Die Betriebszeit der Sitzung wird als „Aktive Zeit“ der Sitzung oder gleichwertige Ausgabe angezeigt.

Nachdem die IKEv2-Sitzung verifiziert wurde, Untersuchen Sie die IPsec-Sitzung. Führen Sie wie bei der IKEv2-Sitzung den Befehl "show crypto ipsec sa" oder einen 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 eingerichtet wird. Wenn die IPsec-Sitzung nicht als aktiv angezeigt wird, überprüfen Sie die IPsec-Protokolle auf Fehlermeldungen oder Verhandlungsfehler.

Einige der häufigsten Probleme, die während der IPsec-Verhandlungen auftreten können, sind:

Die Einstellungen auf der CPE-Seite stimmen nicht mit der Seite 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 Einstellungen für die perfekte Weiterleitung der Geheimhaltung und vergewissern Sie sich, dass die Einstellungen auf der Seite der dedizierten Instanz übereinstimmen.

• Überprüfen Sie die Lifetime-Einstellungen.

• Stellen Sie sicher, dass IPsec im Tunnel-Modus konfiguriert wurde.

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

Wenn die IPsec- und IKEv2-Sitzungen als aktiv und aktiv überprüft werden, können die GRE-Tunnel-Keepalive-Pakete zwischen den dedizierten Instanzen und den CPE-Tunnel-Endpunkten fließen. Wenn die Tunnelschnittstelle keinen Status anzeigt, sind einige häufige Probleme:

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

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

• Keepalives sind auf der CPE-Seitentunnelschnittstelle nicht aktiviert

  Wenn Keepalives auf dem CPE-Gerät nicht unterstützt werden, muss Cisco benachrichtigt werden, damit die Standard-Keepalives auf der Seite der dedizierten Instanz ebenfalls deaktiviert sind.

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

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

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

• Eine Firewall verhindert, dass GRE-Pakete in den IPsec-Tunnel gesendet oder vom IPsec-Tunnel empfangen werden (der GRE-Tunnel wird über den IPsec-Tunnel transportiert)

Ein Ping-Test sollte sicherstellen, dass die lokale Tunnelschnittstelle aktiviert ist und die Verbindung zur entfernten Tunnelschnittstelle gut ist. Führen Sie die Ping-Prüfung von der Tunnel-IP (nicht von der Transport-IP) zur entfernten Tunnel-IP durch.

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

Wenn der Ping-Test nicht erfolgreich ist und die vorhergehenden Elemente verifiziert sind, kann eine Paketerfassung erforderlich sein, um sicherzustellen, dass das icmp-Ping zu einem GRE-Paket führt, das dann in ein IPsec-Paket eingekapselt und dann von der Quell-IPsec-Adresse an die Ziel-IPsec-Adresse gesendet wird. Die Zähler auf der GRE-Tunnelschnittstelle und den IPsec-Sitzungszählern können ebenfalls hilfreich sein, um anzuzeigen, ob die Sende- und Empfangspakete inkrementieren.

Zusätzlich zum Ping-Datenverkehr sollte die Erfassung auch bei inaktivem Datenverkehr keepalive GRE-Pakete anzeigen. Wenn BGP konfiguriert ist, sollten BGP-Keepalive-Pakete auch als GRE-Pakete gesendet werden, die in IPSEC-Paketen eingeschlossen sind, sowie über das VPN.

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-Header hinzu. Dadurch wird die größte MTU, die über den Tunnel erlaubt ist, weiter reduziert.

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 „Tunnelpfad\u0002mtu-discovery“ oder einen gleichwertigen Befehl auf Kundenseite, um die dynamische Anpassung der MTU des Datenverkehrs durch den VPN-Tunnel zu unterstützen.