Die Option „Virtual Connect“ hilft bei der sicheren Erweiterung des privaten Netzwerks über das Internet mithilfe von Punkt-zu-Punkt- IP - VPN -Tunneln.
Einführung
Virtual Connect ist eine zusätzliche Add-On Option für die Cloud-Konnektivität zu einer dedizierten Instanz für Webex Calling (dedizierte Instanz). Virtual Connect ermöglicht es Kunden, ihr privates Netzwerk mithilfe von Point-to-Point- IP - VPN -Tunneln sicher über das Internet zu erweitern. Diese Konnektivitätsoption ermöglicht eine schnelle Einrichtung einer privaten Netzwerkverbindung unter Verwendung der vorhandenen Customer Premise Equipment (CPE)- und Internetkonnektivität.
Cisco hostet, verwaltet und stellt redundante IP VPN -Tunnel und den erforderlichen Internetzugang in den Regionen des Rechenzentrums der dedizierten Instanz von Cisco sicher, in denen der Dienst erforderlich ist. Ebenso ist der Administrator für die entsprechenden CPE- und Internetdienste verantwortlich, die für die Einrichtung von Virtual Connect erforderlich sind.
Jede Virtual Connect-Bestellung in einer bestimmten Region der dedizierten Instanz enthält zwei GRE-Tunnel, die durch IPSec -Verschlüsselung geschützt sind (GRE über IPSec), und zwar einen zu jedem Cisco-Rechenzentrum in der ausgewählten Region.
Virtual Connect hat eine Bandbreitenbegrenzung von 250 MBit/s pro Tunnel und wird für kleinere Bereitstellungen empfohlen. Da zwei Punkt-zu-Punkt- VPN -Tunnel verwendet werden, muss der gesamte Datenverkehr zur Cloud über die Kopfstellen-CPE des Kunden laufen. Daher ist sie möglicherweise nicht für Standorte mit vielen Remote-Standorten geeignet. Weitere alternative Peering-Optionen finden Sie unter Cloud-Konnektivität .
 |
Stellen Sie vor dem Senden der Peering-Anfrage für Virtual Connect sicher, dass der Dienst der dedizierten Instanz in der jeweiligen Region aktiviert ist. |
Voraussetzungen
Voraussetzungen für die Einrichtung von Virtual Connect sind:
Kunde stellt
Internetverbindung mit ausreichender verfügbarer Bandbreite, um die Bereitstellung zu unterstützen
Öffentliche IP-Adresse(n) für zwei IPSec -Tunnel
Kundenseitige GRE-Transport- IP -Adressen für die beiden GRE-Tunnel
Partner und Kunde
Ermitteln Sie die Bandbreitenanforderungen gemeinsam
Stellen Sie sicher, dass Netzwerkgerät das Border Gateway Protocol (BGP)-Routing und ein GRE über IPSec -Tunneldesign unterstützen
Partner oder Kunde stellt
Netzwerkteam mit Kenntnissen der Site-to-Site- VPN -Tunneltechnologien
Netzwerkteam mit Kenntnissen von BGP, eBGP und allgemeinen Routing-Prinzipien
Cisco
Cisco hat ASNs (Private Autonomous System Numbers) und vorübergehende IP -Adressierung für GRE-Tunnelschnittstellen zugewiesen
Cisco hat ein öffentliches, aber nicht über das Internet routbares Netzwerk der Klasse C (/24) für die dedizierte Instanz-Cloud-Adressierung zugewiesen
|
Wenn ein Kunde nur 1 CPE-Gerät besitzt, werden die beiden Tunnel zu den Cisco-Rechenzentren (DC1 und DC2) in jeder Region von diesem CPE-Gerät aus hergestellt. Der Kunde hat auch eine Option für 2 CPE-Geräte. Anschließend sollte jedes CPE-Gerät nur mit einem Tunnel zu den Cisco-Rechenzentren (DC1 und DC2) in jeder Region verbunden werden. Zusätzliche Redundanz kann erreicht werden, indem jeder Tunnel an einem separaten physischen Standort innerhalb der Infrastruktur des Kunden abgeschlossen wird. |
Technische Angaben
Bereitstellungsmodell
Virtual Connect verwendet eine zweischichtige Kopfstellenarchitektur, bei der die Routing- und GRE-Steuerungsebenen von einem Gerät bereitgestellt werden und die IPSec -Steuerungsebene von einem anderen Gerät.
Nach Abschluss des Virtuelle Verbindung Konnektivität werden zwei GRE über IPSec -Tunnel zwischen dem Unternehmensnetzwerk des Kunden und den Rechenzentren der dedizierten Instanz von Cisco erstellt. Eine für jedes redundante Rechenzentrum innerhalb der jeweiligen Region. Zusätzliche für das Peering erforderliche Netzwerkelemente werden vom Partner oder Kunden über das Control Hub Virtual Connect-Aktivierungsformular an Cisco ausgetauscht.
Abbildung 1 zeigt ein Beispiel für das Virtual Connect- Deployment Modell für die Option mit 2 Konvertern 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 innerhalb einer bestimmten Region verbunden sind.
Für eine bessere Redundanz werden zwei Hub-Sites empfohlen, aber auch eine Hub-Site mit zwei Tunneln wird als Deployment Modell unterstützt.
|
Die Bandbreite pro Tunnel ist auf 250 MBit/s beschränkt. |
 |
Die Remote-Standorte des Kunden in derselben Region müssen sich über das WAN des Kunden wieder mit den Hub-Sites verbinden, und Cisco ist nicht für diese Konnektivität verantwortlich. |
Von Partnern wird erwartet, dass sie eng mit den Kunden zusammenarbeiten und sicherstellen, dass der optimale Pfad für die Serviceregion „Virtual Connect“ gewählt wird.
Abbildung 2 zeigt die Peering-Regionen der Cloud Connectivity der dedizierten Instanz.
Weiterleitung
Das Routing für das Virtual Connect Add-On wird mithilfe von externem BGP (eBGP) zwischen der dedizierten Instanz und der Customer Premise Equipment (CPE) implementiert. Cisco kündigt das jeweilige Netzwerk für jedes redundante DC innerhalb einer Region dem CPE des Kunden an, und das CPE muss eine Standardroute zu Cisco.
Cisco pflegt und weist
IP -Adressierung der Tunnelschnittstelle (vorübergehender Link für Routing) Zuweisung von Cisco über einen festgelegten freigegebenen Adressraum (nicht öffentlich routbar)
Adresse des Tunnel-Transportziels (Cisco-Seite)
Private Autonomous System Numbers (ASNs) für die BGP-Routing-Konfiguration des Kunden
Cisco weist aus dem festgelegten privaten Nutzungsbereich zu: 64512 bis 65534
eBGP zum Austausch von Routen zwischen dedizierter Instanz und CPE
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 (vorübergehende Verbindung) zurück an CPE angekündigt.
CPE muss mit den entsprechenden eBGP-Nachbarn konfiguriert sein. Wenn Sie ein CPE verwenden, werden zwei eBGP-Nachbarn verwendet, von denen einer auf jeden Remote-Tunnel zeigt. Wenn Sie zwei CPE verwenden, hat jede CPE einen eBGP-Nachbarn, der zum einzelnen Remote-Tunnel für die CPE führt.
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 der Tunnel anzukündigen
CPE ist verantwortlich für die Neuverteilung der gelernten Routen innerhalb des Unternehmensnetzwerks des Kunden bei Bedarf.
Unter der Bedingung „Keine fehlerhafte Verbindung“ verfügt ein einzelnes CPE über zwei Aktiv/Aktiv-Tunnel. Bei zwei CPE-Knoten hat jedes CPE einen aktiven Tunnel, und beide CPE-Knoten sollten aktiv sein und Datenverkehr passieren. In einem Nicht-Ausfall-Szenario muss sich der Datenverkehr in zwei Tunnel aufteilen, die zu den richtigen /25-Zielen gehen. Wenn einer der Tunnel ausfällt, kann der verbleibende Tunnel den Datenverkehr für beide transportieren. In einem solchen Ausfallszenario, wenn das /25-Netzwerk ausfällt, wird das /24-Netzwerk als Backup-Route verwendet. Cisco sendet Kundendatenverkehr über sein internes WAN an das DC, das die Konnektivität verloren hat.
Konnektivitätsprozess
| 1 | |
| 2 | |
| 3 | |
| 4 |
Schritt 1: CCW-Reihenfolge
Virtual Connect ist ein Add-On für die dedizierte Instanz in CCW.
| 1 | Navigieren Sie zur Website für Bestellungen nach CCW und klicken Sie dann auf Anmelden, um sich bei der Website anzumelden: |
||
| 2 | Schätzung erstellen. |
||
| 3 | Fügen Sie die SKU „A-FLEX-3“ hinzu. |
||
| 4 | Wählen Sie Optionen bearbeiten aus. |
||
| 5 | Wählen Sie auf der angezeigten Registerkarte „Abonnement“ Optionen und Add-ons aus. |
||
| 6 | Aktivieren Sie unter „Zusätzliche Add-ons“ das Kontrollkästchen neben „Virtual Connect für dedizierte Instanz“. Der SKU-Name lautet „A-FLEX-DI-VC“. |
||
| 7 | Geben Sie die Anzahl und Anzahl der Regionen ein, in denen Virtual Connect erforderlich ist.
|
||
| 8 | Wenn Sie mit Ihrer Auswahl zufrieden sind, klicken Sie oben rechts auf der Seite auf Überprüfen und speichern. |
||
| 9 | Klicken Sie auf Speichern und fortfahren, um Ihre Bestellung abzuschließen. Ihre abgeschlossene Bestellung wird jetzt im Bestellraster angezeigt. |
Schritt 2: Aktivierung von Virtual Connect in Control Hub
| 1 | Bei Control Hub anmeldenhttps://admin.webex.com/login . |
||||||||
| 2 | Im Dienste navigieren Sie zu Calling > Dedizierte Instanz > Cloud-Konnektivität . |
||||||||
| 3 | Auf der Virtual Connect-Karte wird die erworbene Virtual Connect-Menge aufgeführt. Der Administrator kann jetzt auf klicken Aktivieren um die Virtual Connect-Aktivierung zu initiieren. 
|
||||||||
| 4 | Beim Klicken auf Aktivieren Schaltfläche, Virtual Connect aktivieren wird angezeigt, damit der Administrator die technischen Details zu Virtual Connect für die Peering-Konfigurationen auf Seiten von Cisco eingeben kann.
|
||||||||
| 5 | Klicken Sie auf das Aktivieren sobald alle Pflichtfelder ausgefüllt sind. |
||||||||
| 6 | Nachdem das Virtual Connect-Aktivierungsformular für eine bestimmte Region ausgefüllt wurde, kann der Kunde das Aktivierungsformular in Control Hub auf die Registerkarte Calling > Dedizierte Instanz > Cloud-Konnektivität Exportieren und auf Exporteinstellungen klicken. 
|
Schritt 3: Cisco führt die Netzwerkkonfiguration durch
| 1 | Sobald das Virtual Connect-Aktivierungsformular ausgefüllt ist, wird der Status in geändert Aktivierung läuft in Calling > Dedizierte Instanz > Cloud Connectivity Virtual Connect-Karte. |
| 2 | Cisco nimmt die erforderlichen Konfigurationen auf den Nebengeräten von Cisco innerhalb von 5 Werktage . Nach erfolgreichem Abschluss wird der Status für diese bestimmte Region in Control Hub auf „Aktiviert“ aktualisiert. |
Schritt 4: Kunde führt Netzwerkkonfiguration durch
Der Status wird in „Aktiviert“ geändert, um den Kundenadministrator zu benachrichtigen, dass die Cisco-Seite der Konfigurationen für die IP - VPN -Konnektivität basierend auf den Eingaben des Kunden abgeschlossen wurde. Vom Kundenadministrator wird jedoch erwartet, dass er die Konfigurationen auf den CPEs abschließt und die Konnektivitätsrouten testet, damit der Virtual Connect-Tunnel online ist. Bei Problemen mit der Konfiguration oder Konnektivität kann sich der Kunde an Cisco TAC , um Unterstützung zu erhalten. |
Fehlerbehebung
Erste IPSec-Phase (IKEv2-Verhandlung) – Fehlerbehebung und Validierung
Die IPSec-Tunnelverhandlung umfasst zwei Phasen, die IKEv2-Phase und die IPSec-Phase. Wenn die IKEv2-Phasenverhandlung nicht abgeschlossen wird, wird keine zweite IPSec-Phase initiiert. Geben Sie zunächst den Befehl „show Crypto ikev2 sa“ (auf Geräten von Cisco ) oder einen ähnlichen Befehl auf Geräten des Drittanbieters 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-Tunnel- Zugriffsliste ist falsch konfiguriert.
Es besteht keine Konnektivität zwischen dem Kunden und dem IPsec-Tunnelendpunkt IP der dedizierten Instanz.
Die IKEv2-Sitzungsparameter auf der Seite der dedizierten Instanz und der Seite des Kunden stimmen nicht überein.
Eine Firewall blockiert die IKEv2- UDP -Pakete.
Überprüfen Sie zunächst die IPSec-Protokolle auf Meldungen, die den Fortschritt der IKEv2-Tunnelverhandlung anzeigen. Die Protokolle können Hinweise auf ein Problem mit der IKEv2-Aushandlung geben. Fehlende Protokollmeldungen können auch darauf hindeuten, dass die IKEv2-Sitzung nicht aktiviert wird.
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 der "GCM"-Schlüssel 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-Modulus-Gruppe.
Überprüfen Sie die Einstellungen für die Pseudo-Zufallsfunktion.
Die Zugriffsliste für die Crypto Map ist nicht festgelegt auf:
GRE zulassen (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 Protokoll „GRE“ erstellt werden, damit das Protokoll „IP“ nicht funktioniert.
Wenn die Protokollmeldungen keine Aushandlungsaktivität für die IKEv2-Phase anzeigen, ist möglicherweise eine Paketerfassung erforderlich.
|
Die Seite der dedizierten Instanz beginnt möglicherweise nicht immer mit dem IKEv2-Austausch und kann manchmal erwarten, dass die Seite der Kunden-CPE der Initiator ist. Überprüfen Sie die CPE-seitige Konfiguration auf die folgenden Voraussetzungen für die IKEv2-Sitzungsinitiierung:
|
Bei ordnungsgemäßer Konfiguration werden der IPSec-Tunnel und die IKEv2-Aushandlung der ersten Phase wie folgt gestartet:
GRE-Keepalives von der CPE-seitigen GRE-Tunnelschnittstelle zur GRE-Tunnelschnittstelle der Seite der dedizierten Instanz.
BGP-Nachbar- TCP -Sitzung vom CPE-seitigen BGP-Nachbarn zum BGP-Nachbarn der dedizierten Instanz.
Pingen Sie von der CPE-seitigen Tunnel- IP-Adresse an die Tunnel-IP-Adresse der dedizierten Instanz .
Ping kann nicht die Tunnel-Transport- IP zur Tunnel-Transport- IP sein, es muss jedoch die Tunnel- IP zur Tunnel- IP sein.
Wenn eine Paketverfolgung für den IKEv2-Verkehr erforderlich ist, legen Sie den Filter auf UDP und entweder Port 500 (wenn sich kein NAT-Gerät in der Mitte der IPSec-Endpunkte befindet) oder Port 4500 (wenn sich ein NAT-Gerät in der Mitte der IPSec-Endpunkte befindet) fest Endpunkte).
Stellen Sie sicher, dass IKEv2- UDP -Pakete mit Port 500 oder 4500 gesendet und von der IPsec IP-Adresse des IP empfangen werden.
|
Das Rechenzentrum der dedizierten Instanz beginnt möglicherweise nicht immer mit dem ersten IKEv2-Paket. Voraussetzung ist, dass das CPE-Gerät in der Lage ist, das erste IKEv2-Paket in Richtung der Seite der dedizierten Instanz zu initiieren. Wenn die lokale Firewall dies zulässt, versuchen Sie auch einen Ping an die Remote-IPsec-Adresse zu senden. Wenn der Ping von der lokalen zur Remote-IPsec-Adresse nicht erfolgreich ist, führen Sie eine Trace Route durch, um festzustellen, wo das Paket verworfen wird. Einige Firewalls und Internet-Geräte erlauben keine Trace-Route. |
Zweite IPSec-Phase (IPsec-Aushandlung) – Fehlerbehebung und Validierung
Stellen Sie sicher, dass die erste IPSec-Phase (d. h. die IKEv2-Sicherheitszuordnung) aktiv ist, bevor Sie die Fehlerbehebung für die zweite IPSec-Phase durchführen. Führen Sie „show Crypto ikev2 sa“ oder einen gleichwertigen Befehl aus, um die IKEv2-Sitzung zu überprüfen. Stellen Sie in der Ausgabe sicher, dass die IKEv2-Sitzung länger als einige Sekunden aktiv ist und nicht zurückspringt. Die Betriebszeit der Sitzung wird als „Aktive Zeit“ der Sitzung oder als Äquivalent in der Ausgabe angezeigt.
Sobald die IKEv2-Sitzung überprüft wurde, dass sie aktiv ist, Untersuchen Sie die IPSec-Sitzung. Führen Sie wie bei der IKEv2-Sitzung „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 Aushandlungsfehler.
Einige der häufigsten Probleme, die während der IPSec-Verhandlungen auftreten können, sind:
Die Einstellungen auf der CPE-Seite stimmen nicht auf 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, ob die Einstellungen für „Perfect Forward Secrecy“ und die Einstellungen auf der Seite der dedizierten Instanz übereinstimmen.
Überprüfen Sie die Einstellungen für die Lebensdauer.
Stellen Sie sicher, dass IPsec im Tunnelmodus konfiguriert wurde.
Überprüfen Sie die Quell- und Ziel-IPsec-Adressen.
Fehlerbehebung und Validierung der Tunnel-Schnittstelle
Wenn die IPsec- und IKEv2-Sitzungen als aktiv verifiziert werden, können die GRE-Tunnel-Keepalive-Pakete zwischen der dedizierten Instanz und den CPE-Tunnelendpunkten fließen. Wenn der Status der Tunnel-Schnittstelle nicht angezeigt wird, gibt es einige häufige Probleme:
Die Transport-VRF der Tunnelschnittstelle stimmt nicht mit der VRF der Loopback-Schnittstelle überein (wenn die VRF-Konfiguration für die Tunnelschnittstelle verwendet wird).
Wenn die VRF-Konfiguration nicht für die Tunnelschnittstelle verwendet wird, kann diese Überprüfung ignoriert werden.
Keepalives sind auf der CPE-seitigen Tunnelschnittstelle nicht aktiviert
Wenn auf der CPE-Ausrüstung keine Keepalives 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, stellen Sie sicher, dass die Keepalives aktiviert sind.
Die Maske oder IP-Adresse der Tunnelschnittstelle ist nicht korrekt und entspricht nicht den erwarteten Werten der dedizierten Instanz.
Die Transportadresse des Quell- oder Zieltunnels ist nicht korrekt und entspricht nicht den erwarteten Werten der dedizierten Instanz.
Eine Firewall verhindert, dass GRE-Pakete im 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 aktiv ist und die Verbindung zur Remote-Tunnelschnittstelle gut ist. Führen Sie die Ping-Prüfung von der Tunnel- IP (nicht der Transport- IP) zur Remote-Tunnel- IP durch.
|
Die Krypto- Zugriffsliste für den IPSec-Tunnel, der den GRE-Tunnelverkehr überträgt, lässt nur die Überquerung von GRE-Paketen zu. Daher funktionieren Pings nicht von der Tunneltransport- IP zur Remote-Tunneltransport- IP. |
Die Ping-Überprüfung führt zu einem GRE-Paket, das von der Quell-Tunnel-Transport- IP zur Ziel-Tunnel-Transport- 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 vorherigen 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 eingebettet und dann von der IPSec-Quelladresse an gesendet wird die IPsec-Zieladresse. Zähler auf der GRE-Tunnel-Schnittstelle und die IPSec-Sitzungszähler können ebenfalls hilfreich sein. wenn die Sende- und Empfangspakete inkrementiert werden.
Zusätzlich zum Ping-Datenverkehr sollte die Erfassung auch bei inaktivem Datenverkehr Keepalive-GRE-Pakete anzeigen. Wenn BGP konfiguriert ist, sollten die BGP-Keepalive-Pakete auch als GRE-Pakete in IPsec-Paketen gebündelt über das VPN gesendet werden.
BGP-Fehlerbehebung und -Validierung
BGP-Sitzungen
BGP ist als Routing-Protokoll über den VPN -IPsec-Tunnel erforderlich. Der lokale BGP-Nachbar sollte eine eBGP-Sitzung mit dem BGP-Nachbarn der dedizierten Instanz einrichten. Die eBGP-Nachbar- IP -Adressen sind mit den lokalen und Remote-Tunnel- IP -Adressen identisch. Stellen Sie zunächst sicher, dass die BGP-Sitzung aktiv ist, und stellen Sie dann sicher, dass die richtigen Routen von der dedizierten Instanz empfangen werden und die richtige Standardroute an die dedizierte Instanz gesendet wird.
Wenn der GRE-Tunnel aktiv ist, überprüfen Sie, ob ein Ping zwischen der lokalen und der Remote-GRE-Tunnel- IP erfolgreich ist. Wenn der Ping erfolgreich ist, aber die BGP-Sitzung nicht startet, untersuchen Sie das BGP-Protokoll auf BGP-Einrichtungsfehler.
Zu den häufigeren Problemen bei der BGP-Aushandlung gehören:
Die Remote-AS-Nummer stimmt nicht mit der AS-Nummer überein, die auf der Seite der dedizierten Instanz konfiguriert ist. Überprüfen Sie die Nachbar-AS-Konfiguration erneut.
Die lokale AS-Nummer stimmt nicht mit den Erwartungen der dedizierten Instanz überein. Überprüfen Sie, ob die lokale AS-Nummer mit den erwarteten Parametern der dedizierten Instanz übereinstimmt.
Eine Firewall verhindert, dass BGP- TCP -Pakete in GRE-Paketen an den IPSec-Tunnel gesendet oder vom IPSec-Tunnel empfangen werden
Die IP des Remote-BGP-Nachbarn stimmt nicht mit der IP des Remote-GRE-Tunnels IP.
BGP-Routenaustausch
Nachdem die BGP-Sitzung für beide Tunnel verifiziert wurde, stellen Sie sicher, dass die richtigen Routen von der Seite der dedizierten Instanz gesendet und empfangen werden.
Die VPN -Lösung für dedizierte Instanzen erwartet, dass von der Kunden-/Partnerseite zwei Tunnel eingerichtet werden. Der erste Tunnel verweist auf das Rechenzentrum der dedizierten Instanz und der zweite Tunnel auf das Rechenzentrum der dedizierten Instanz. Beide Tunnel müssen aktiv sein und die Lösung erfordert eine Aktiv/Aktiv-Bereitstellung. Jedes Rechenzentrum der dedizierten Instanz kündigt seine lokale /25-Route sowie eine /24-Backup-Route an. Wenn Sie die eingehenden BGP-Routen von der dedizierten Instanz überprüfen, stellen Sie sicher, dass die BGP-Sitzung, die dem Tunnel zugeordnet ist, der auf Rechenzentrum A der dedizierten Instanz verweist, die lokale Route /25 der dedizierten Instanz sowie die Backup-Route /24 erhält. Stellen Sie außerdem sicher, dass der Tunnel, der auf Rechenzentrum B der dedizierten Instanz verweist, die lokale /25-Route der dedizierten Instanz Rechenzentrum B sowie die Backup-Route /24 erhält. Beachten Sie, dass die /24-Backuproute dieselbe Route ist, die vom Rechenzentrum der dedizierten Instanz und dem Rechenzentrum B der dedizierten Instanz angekündigt wird.
Redundanz wird für ein Rechenzentrum der dedizierten Instanz bereitgestellt, wenn die Tunnelschnittstelle zu diesem Rechenzentrum ausfällt. Wenn die Konnektivität zum Rechenzentrum A der dedizierten Instanz unterbrochen wird, wird der Datenverkehr von Rechenzentrum B der dedizierten Instanz zu Rechenzentrum A weitergeleitet. In diesem Szenario verwendet der Tunnel zu Rechenzentrum B die /25-Route von Rechenzentrum B, um Datenverkehr an Rechenzentrum B und den Tunnel . zu senden zu Rechenzentrum B verwendet die Backup-Route /24, um Datenverkehr über Rechenzentrum B an Rechenzentrum A zu senden.
Wenn beide Tunnel aktiv sind, muss der Tunnel von Rechenzentrum A nicht zum Senden von Datenverkehr an Rechenzentrum B und umgekehrt verwendet werden. Wenn in diesem Szenario Datenverkehr an Rechenzentrum A mit dem Ziel Rechenzentrum B gesendet wird, leitet Rechenzentrum A den Datenverkehr an Rechenzentrum B weiter, und Rechenzentrum B versucht dann, den Datenverkehr über den Tunnel von Rechenzentrum B zurück an die Quelle zu senden. Dies führt zu einem suboptimalen Routing und kann auch Firewalls durchbrechen. Daher ist es wichtig, dass sich beide Tunnel während des normalen Betriebs in einer Aktiv/Aktiv-Konfiguration befinden.
Die Route 0.0.0.0/0 muss von der Kundenseite für das Rechenzentrum der dedizierten Instanz bereitgestellt werden. Spezifischere Routen werden von der Seite der dedizierten Instanz nicht akzeptiert. Stellen Sie sicher, dass die Route 0.0.0.0/0 sowohl aus dem Tunnel des Rechenzentrums A der dedizierten Instanz als auch dem Tunnel des Rechenzentrums B der dedizierten Instanz heraus angekündigt wird.
MTU-Konfiguration
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, wodurch die größte MTU, die über den Tunnel zulässig ist, weiter reduziert wird.
Der GRE-Tunnel passt die MSS-Funktion an, und der GRE-Tunnelpfad in der MTU-Erkennungsfunktion wird auf der Seite der dedizierten Instanz aktiviert. Konfigurieren Sie „ip tcpadjust-mss 1350“ oder einen gleichwertigen Befehl sowie „tunnelpath\u0002mtu-discovery“ oder einen gleichwertigen Befehl auf Kundenseite, um die dynamische Anpassung der MTU des Datenverkehrs durch den VPN -Tunnel zu unterstützen.
