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.

In Abbildung 1 ist ein Beispiel für das Virtual Connect-Bereitstellungsmodell für die Option 2-Geber auf Kundenseite dargestellt.

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 partnern wird erwartet, dass sie eng mit den Kunden zusammenarbeiten und sicherstellen, dass der optimale Pfad für die "Virtual Connect"-Serviceregion gewählt wird.

Abbildung 2 zeigt die Peering-Regionen für dedizierte Cloudkonnektivität.

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 IKEv2-Phase-Verhandlung nicht abgeschlossen ist, dann gibt es 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 eines Drittanbieters aus, um zu überprüfen, ob die IKEv2-Sitzung aktiv ist. Wenn die IKEv2-Sitzung nicht aktiv ist, können die möglichen Gründe dafür sein:

• Interessanter Verkehr 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 zwischen der Seite der dedizierten Instanz und der Kundenseite nicht überein.

• Eine Firewall blockiert die IKEv2 UDP-Pakete.

Prüfen Sie zunächst die IPsec-Protokolle auf alle Nachrichten, die den Fortschritt der IKEv2-Tunnelverhandlung anzeigen. Die Protokolle können anzeigen, wo es ein Problem mit der IKEv2-Verhandlung gibt. Ein Mangel an Protokollierungsnachrichten 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 der Cisco-Seite überein. Überprüfen Sie die genannten Einstellungen:

  • Überprüfen Sie, ob 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 Einstellung für die Lebensdauer.

  • Überprüfen Sie die Diffie Hellman Modulgruppe.

  • Überprüfen Sie die Einstellungen für die Pseudo-Zufallsfunktion.

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

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

    Die Zugriffsliste muss speziell für das "GRE"-Protokoll sein und das "IP"-Protokoll funktioniert nicht.

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

Bei ordnungsgemäßer Konfiguration beginnen die folgenden Schritte mit dem IPsec-Tunnel und der IKEv2-Verhandlung der ersten Phase:

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

• BGP-Nachbar-TCP-Sitzung von der CPE-Seite BGP-Nachbar zur Seite der dedizierten Instanz BGP-Nachbar.

• Ping von der IP-Adresse des CPE-Seitentunnels zur 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 benötigt wird, legen Sie den Filter für UDP und 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 wird) fest.

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

Stellen Sie sicher, dass die erste IPsec-Phase (d. h. IKEv2-Sicherheitsverknüpfung) aktiv ist, bevor Sie die zweite IPsec-Phase beheben. Führen Sie einen Befehl "show crypto ikev2 sa" oder einen entsprechenden Befehl aus, um die IKEv2-Sitzung zu überprüfen. Überprüfen Sie in der Ausgabe, ob die IKEv2-Sitzung mehr als ein paar Sekunden lang aktiv war und nicht abprallt. Die Verfügbarkeit der Sitzung wird als „Aktive Zeit“ der Sitzung oder gleichwertig in der Ausgabe angezeigt.

Sobald die IKEv2-Sitzung als aktiv verifiziert wurde, Untersuchen Sie die IPsec-Sitzung. Führen Sie wie bei der IKEv2-Sitzung einen Befehl "show crypto ipsec sa" oder einen entsprechenden 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 Aushandlungsfehler.

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:

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

• Überprüfen Sie die Perfect Forward Secrecy-Einstellungen und die Übereinstimmungseinstellungen auf der Seite der dedizierten Instanz.

• Überprüfen Sie die Lifetime-Einstellungen.

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

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

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

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

  Wenn die VRF-Konfiguration nicht auf der Tunnelschnittstelle 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 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 Transportadresse für den Quell- oder Zieltunnel ist nicht korrekt und stimmt nicht mit den erwarteten Werten der dedizierten Instanz überein.

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

Ein Ping-Test sollte überprüfen, ob die lokale Tunnelschnittstelle funktioniert und die Konnektivität zur entfernten Tunnelschnittstelle gut ist. Führen Sie eine Ping-Prüfung von der Tunnel-IP (nicht der Transport-IP) zur Remote-Tunnel-IP durch.

Die Ping-Prüfung ergibt ein GRE-Paket, das vom Quell-Tunnel-Transport IP zum Ziel-Tunnel-Transport IP generiert wird, während die Nutzlast des GRE-Pakets (die innere IP) die Quell- und Ziel-Tunnel-IP ist.

Wenn der Ping-Test nicht erfolgreich ist und die vorhergehenden Elemente überprüft werden, muss möglicherweise eine Paketerfassung durchgeführt werden, um sicherzustellen, dass der 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. Zähler auf der GRE-Tunnelschnittstelle und die IPsec-Sitzungszähler können ebenfalls helfen zu zeigen, ob die Sende- und Empfangspakete inkrementieren.

Neben dem Ping-Verkehr sollte die Erfassung auch keepalive GRE-Pakete auch während des inaktiven Datenverkehrs anzeigen. Wenn BGP konfiguriert ist, sollten BGP-Keepalive-Pakete auch als GRE-Pakete gesendet werden, die in IPSEC-Paketen sowie über das VPN eingeschlossen sind.

Auf der Seite der dedizierten Instanz können zwei Funktionen die MTU bei großen Paketgrößen dynamisch anpassen. Der GRE-Tunnel fügt weitere Header zu den IP-Paketen hinzu, die durch die VPN-Sitzung fließen. Durch den IPsec-Tunnel mit den zusätzlichen Headern auf den GRE-Headern wird die größte über dem Tunnel zulässige MTU 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 äquivalenter Befehl sowie "Tunnel path\u0002mtu-discovery" oder äquivalenter Befehl auf Kundenseite, um die dynamische Anpassung der MTU des Datenverkehrs durch den VPN-Tunnel zu unterstützen.