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

Nach Abschluss der Virtual Connect-Verbindung werden zwischen dem Unternehmensnetzwerk des Kunden und den Rechenzentren der dedizierten Instanz von Cisco zwei GRE-over-IPSec-Tunnel erstellt. Eines zu jedem redundanten Rechenzentrum innerhalb der jeweiligen Region. Weitere für das Peering erforderliche Netzwerkelemente werden vom Partner oder Kunden über das Aktivierungsformular für Control Hub Virtual Connect an Cisco ausgetauscht.

Abbildung 1 zeigt ein Beispiel des Virtual Connect-Bereitstellungsmodells für die 2-Konzentrator-Option auf Kundenseite.

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

Zwei Hub-Standorte werden für eine bessere Redundanz empfohlen, aber Ein Hub-Standort mit zwei Tunneln ist auch ein unterstütztes Bereitstellungsmodell.

Die Bandbreite pro Tunnel ist auf 250 MBit/s begrenzt.

Die Remote-Standorte des Kunden innerhalb derselben Region müssten über das WAN des Kunden wieder mit den Hub-Standorten verbunden werden, und Cisco ist nicht für diese Konnektivität verantwortlich.

Von den Partnern wird eine enge Zusammenarbeit mit den Kunden erwartet, um sicherzustellen, dass der optimale Weg für die „Virtual Connect“-Serviceregion gewählt wird.

Abbildung 2 zeigt die Peering-Regionen für die Cloud-Konnektivität der dedizierten Instanz.

Das Routing für das Virtual Connect Add-on wird mithilfe eines externen BGP (eBGP) zwischen der dedizierten Instanz und dem CPE (Customer Premise Equipment) implementiert. Cisco kündigt sein jeweiliges Netzwerk für jedes redundante DC in einer Region an den CPE des Kunden an, und der CPE ist erforderlich, um eine Standardroute an Cisco anzukündigen.

• Cisco pflegt und weist zu

  • IP-Adressierung der Tunnelschnittstelle (transienter Link für das Routing), die Cisco von einem festgelegten gemeinsam genutzten Adressbereich zuweist (nicht öffentlich routbar)

  • Adresse für Tunneltransport-Desitination (von Cisco)

  • Private autonome Systemnummern (ASNs) für die BGP-Routing-Konfiguration des Kunden

    • Cisco weist aus dem angegebenen privaten Nutzungsbereich zu: 64512 bis 65534

• eBGP verwendet, um Routen zwischen Dedicated Instance und CPE auszutauschen

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

  • In Virtual Connect wird jedes /25-Netzwerk von Cisco über die jeweiligen Punkt-zu-Punkt-VPN-Tunnel an CPE zurückgemeldet (transiente Verbindung).

  • CPE muss mit den entsprechenden eBGP-Nachbarn konfiguriert werden. Wenn Sie ein CPE verwenden, werden zwei eBGP-Nachbarn verwendet, einer zeigt auf jeden entfernten Tunnel. Wenn Sie zwei CPE verwenden, dann wird jeder CPE einen eBGP-Nachbarn haben, der zum einzigen Remote-Tunnel für den CPE peilt.

  • Die Cisco-Seite jedes GRE-Tunnels (Tunnel Interface IP) ist als BGP-Nachbar auf dem CPE konfiguriert.

  • CPE ist erforderlich, um eine Standardroute über jeden Tunnel anzukündigen

  • CPE kann die erlernten Routen innerhalb des Unternehmensnetzwerks des Cutomers nach Bedarf umverteilen.

• Unter "Nicht-Fehler-Link-Fehler"-Bedingung wird ein einzelnes CPE zwei aktive/aktive Tunnel haben. Für zwei CPE-Knoten hat jeder CPE einen aktiven Tunnel, und beide CPE-Knoten sollten aktiv und passierender Datenverkehr sein. Bei Nichtausfall muss der Verkehr in zwei Tunnel aufgeteilt werden, die zu den korrekten /25 Zielen gehen, wenn einer der Tunnel abfällt, kann der restliche Tunnel den Verkehr für beide tragen. Bei einem solchen Fehlerszenario wird das /24-Netzwerk als Backup-Route verwendet, wenn das /25-Netzwerk ausgefallen ist. Cisco sendet Kundendatenverkehr über das interne WAN an das DC, bei dem 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.

Die Seite der dedizierten Instanz beginnt möglicherweise nicht immer mit dem IKEv2-Austausch und kann manchmal erwarten, dass die CPE-Seite des Kunden der Initiator ist. Überprüfen Sie die CPE-Seitenkonfiguration für die folgenden Voraussetzungen für die IKEv2-Sitzungsinitiierung: Suchen Sie nach einer IPsec-Verschlüsselungszugriffsliste für GRE-Datenverkehr (Protokoll 50) von der CPE-Tunneltransport-IP zur dedizierten Instanztunnel-Transport-IP. Stellen Sie sicher, dass die GRE-Tunnelschnittstelle für GRE-Keepalives aktiviert ist. Wenn das Gerät GRE-Keepalives nicht unterstützt, wird Cisco benachrichtigt, da GRE-Keepalives standardmäßig auf der Seite der dedizierten Instanz aktiviert werden. Stellen Sie sicher, dass BGP aktiviert und mit der Nachbaradresse der Tunnel-IP der dedizierten Instanz konfiguriert ist.

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.

Das Rechenzentrum der dedizierten Instanz startet möglicherweise nicht immer das erste IKEv2-Paket. Die Anforderung ist, dass das CPE-Gerät das erste IKEv2-Paket in Richtung der dedizierten Instanz initiieren kann. Wenn die lokale Firewall dies zulässt, versuchen Sie auch, einen Ping an die Remote-IPsec-Adresse zu senden. Wenn der Ping von einer lokalen IPsec-Adresse zur Remote-IPsec-Adresse nicht erfolgreich ist, führen Sie eine Nachverfolgungsroute aus, um zu helfen, und bestimmen Sie, wo das Paket gelöscht wird. Einige Firewalls und Internetgeräte erlauben möglicherweise keine Nachverfolgungsroute.

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 Crypto-Zugriffsliste für den IPsec-Tunnel, der den GRE-Tunnelverkehr trägt, erlaubt nur das Überqueren von GRE-Paketen. Infolgedessen funktionieren Pings nicht vom Tunneltransport-IP zum entfernten Tunneltransport-IP.

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.